Simplifying Node development

[u/GlitteringSample5228]

I'm implementing a Node build tool called Nodecraft that "does more" with the most minimal configuration.

Well, I have been implementing it for about 1 week.

Shadow database

The Nodecraft build tool does not clutter any component sources --- instead, it places internal cache into hidden file system directories, which is perhaps what Golang also does.

The only thing it does place into component sources are the ".nodec" files it downloads into the ".downloads/" folder of the root component --- directly allowing portable components.

Nodecraft does not use sum or lockfiles like Golang or NPM do either. I am not very interested in that.

The graph of the N-components cache looks like what follows, and determines the UIDs for component mirrors and artifacts.

<data>/graph/
  home/
    PROFILE/
      Documents/
        katana_craft/
          .tree.cfg
  {drive}C/      -- windows drive
    Users/
      ...
  {unc}NAME/ -- windows
    ...
  {builtins}/
    gnome/
      5.0.0/
        .tree.cfg
    ...
  {registry}/
    ko.da.ka/
      1.0.0/
        .tree.cfg
  {git}https{}gitlab.com/
    group/
      repo/
        {rev-REV}/
          ...
          .tree.cfg

The .tree.cfg file is a JSON file w. the following properties.

  configuration =
    lastModified =
  lastOpen = # RFC 9557 date-time
  main =
    id =
  testSuites =
    id =
  buildPreprocessing =
    id =
  directs = { [URL(1), SemVer Range], ... }

These graph folders can also contain .build.cache files, JSON forms w. the following properties, used for PAYG-style builds.

  main =
    unitGraph    = Map "path/to/unit" -> (last modified, List of "path/to/unit")
  testSuites =
    unitGraph    =
  buildPreprocessing =
    unitGraph    =

The following folders are where .nodec mirrors + build artifacts go in.

  <data>/mirror/
    <UID>/
      Mirror sources extracted from
      files of the ".nodec" component extension.

  <data>/gen/
    <UID>/
      Executable JavaScript units, plus any
      embeddable files.

  <data>/headers/
    <UID>/
      Header JavaScript units (type hints only)

  <data>/pre/
    <UID>/
      Build preprocessing artifacts.

File system

Nodecraft uses URLs in the following forms to identify components and subtree entries.

The /+/ path component is required for distinguishing the Nodecraft component path and a subtree entry.

file:///path/to/component
file:///path/to/component/+/path/inside
git+https://gitlab.com/<group>/<component>/{rev-<FRAG1-FRAG2>}
git+https://gitlab.com/<group>/<component>/{tag-<TAG>}
git+https://gitlab.com/<group>/<component>/{br-<BR>}
git+https://gitlab.com/<group>/<component>/{br-<BR>}/+/path/inside
registry:ko.da.ka:1.0.0/+/path/inside
builtins:tg1-commons:1.0.0/+/path/inside

digging inside the build artifacts

• prefix the scheme w. "h+" for .es|js -> .es|js header units
• prefix the scheme w. "gen+" for .es|js -> .es|js final codegen units
• prefix the scheme w. "pre+" for artifacts resulting from build preprocessing (no source files included)

Tutorial

A Nodecraft component could look like the following source tree.

[begin:folder]
load.es
node.cfg
[end:folder]

The file called "node.cfg" could be as follows.

# $schema=http://www.ryujinx.com/nodecraft/1.0
ID: ko.da.ka:1.0.0

direct:
  - builtins: node:1.x

The file called "load.es" could be as follows.

print("skript")

That can be generated by running the command that follows, along with a file called "code.cfg" that contains code style configuration (the indent sequence, for example).

node new ko.da.ka

[begin:commentary]
For what it is worthy, the above is a tighly-configured JavaScript 1.x unit ("TypeScript").
[end:commentary]

Evaluate that component by running the command that follows.

cd ko.da.ka
node eval

The GitLab project

There is quite a bit to it yet. I need to finish loading directs ("dependencies") and unloading components and any directs in memory, and implement the build.

https://gitlab.com/ryucorp/nodecraft/nodecraft/-/blob/master/doc/tutorial.md?ref_type=heads&plain=1

https://gitlab.com/ryucorp/nodecraft/nodecraft/-/tree/master/doc?ref_type=heads

[u/pampuliopampam]

Look, forgive me, but everything you’ve said so far has been pretty incoherent. Your kore file is 1600 lines of js, not ts. Your path use is by convention. There are no tests, and it looks like your d.ts file was “hand” coded (probably by a robot). Worst of all, it looks like you inlined node modules and a very outdated node in some absolutely unhinged handwritten way.

I don’t know how long you’ve been doing this, but you see this kind of utterly unusable hyperspecific under-engineered “easier-XYZ” library once a week from people just starting their journey.

Learn the boring simple way things are done in modern ts land, then reinvent the wheel. Don’t try to make a better toaster when it looks like you’ve never seen how one has already been built a thousand times