feat(node): experimental loader

[idoros]

This PR adds a NodeJS loader to be used with --experimental-loader.

The new loader doesn't support node 14 since the loader API changed (tests are skipped for v14).

Tasks

• [x] implement default loading
• [x] use stylable.config

Open issues (don't have to be solved in this PR)

• How do we differ between dev/production mode (2 loaders?, env flag?)
• How do we provide optimized namespaces mappings from a seperate process like webpack? (same issue with attachHook, but a bit more difficult since loaders don't get args )
• Currently the loader generates an esm module, but imports the cjs runtime (@stylable/runtime/dist/pure.js). This is done because our esm runtime is built into .js and the runtime package.json is not type:module, which means that the esm version cannot be imported by node and is currencly only used by bundlers that are more lenient.

[Scott-MacD]

Hi @idoros, as mentioned in Discord, I think we are going down the route of using Webpack for the server as well, but happy to provide some feedback if you're looking for input.

• I would lean on using the dev/production environment variable to differentiate between modes, as that is already a really common convention with Node server apps, however I do not think it matters too much as long as it is properly documented.
• If the loader, cli, and everything else all use the same deterministic conventions for generating names, then would this not work as long as both compilation methods are using the same files? If a developer has a need for serving the files through different paths, could they not specify their own namespace mapping in stylable.config.js using ResolveNamespace?
• Don't have any immediate thoughts on the esm vs cjs incompatibilities.

[idoros]

all use the same deterministic conventions for generating names, then would this not work as long as both compilation methods are using the same files?...could they not specify their own namespace mapping in stylable.config.js

Partly yes, but this will not always work with 2 cases:

• with optimizations enabled, the namespace has no effect and the order of optimized files might not be deterministic
• with the new createNamespaceStrategy you can choose to have more readable names with minimal hash (hashFragment: 'minimal'), with this config the resulting names would attempt to remove the hash and only add a minimal part of it when a collision is detected. And again the order of processed files might not be deterministic.

The solution for all of this in my opinion is to produce some lock file that can be used to control the final name deterministically across integrations.