Verify NJS 19,1 import require flags

[lemanschik]

Stake Holder list

• microsoft/typescript
• microsoft/vscode
• microsoft/playwright
• microsoft/vscode-loader
• ts-node
• mocha
• jest
• pnpm
• yarn
• rollup
• opentelemetry-js
• puppeteer
• nodejs/main
• electron/main
• nwjs/main

Ambient Loader Progress

• esm: add --import flag nodejs/node#43942 and nodejs/node@77cb88b
• PoC Atomic workers - https://github.com/JakobJingleheimer/worker-atomics
• PR: cli api  just-js/just#56
• WiP: PR as also Discussion new loader API rollup/rollup#4730
• feat(esm): leverage loaders when resolving subsequent loaders nodejs/node#43772
• Node.js Technical Steering Committee (TSC) Meeting 2022-11-02 nodejs/TSC#1302
• [feat]: shared cross context module resolution worker also can be used as serviceWorker and IPC between both puppeteer/puppeteer#9332
• 2022-11-08 meeting notes nodejs/loaders#118 (comment)
• esm, loader: move to own thread nodejs/node#43658
• ESM support: soliciting feedback TypeStrong/ts-node#1007
• ESM considerations for ts-node and other require.extensions hooks mochajs/mocha#4274
• WiP PR: Preparing to land multiContext Unified customResolver Support modules nwjs/nw.js#8006
• WiP: PR as also Discussion new loader API rollup/rollup#4730
• Confusing documentation mixes different packages and entrypoints open-telemetry/opentelemetry-js#3230
• Todo: Init the Process in GraalJS and Eclipse Vertx to algin api's and the vm api's
• Todo: Init the Process in Deno to algin api's and the vm api's
• Evaluation vfs implementations assign code ninjas

The behavior of experimental loader hooks is not solved if all is solved we can implement rollup resolver finally as a plugin system to resolve hooks to enable:

• esm, loader: move to own thread nodejs/node#43658
• Loader Hooks nodejs/modules#351
• Loader Hooks are essential to make packaging more simple as the developer can author more easy injections without using package.json and be bound to cjs only without it and forced into .mjs it solves many subtle quirks also for the REPL
  • Create doc on how to support ESM and CommonJS when publishing modules nodejs/package-maintenance#542 (comment)
    as rollup is the best plugin loader hook system at present that we got with the largest ecosystem and most quirks handled also support cascading versioning with consistent hashing which is essential for module cache handling and dynamic updates

TypeScript Closes

This closes all typescript resolve issues as typescript runs in nodejs and it respect nodejs flags you can finally apply loader Plugins to Typescript while typescript will work with frozzen intrinsics.

• Closes: A Proposal For Module Resolution microsoft/TypeScript#50152
  • on the long run gets closed via switching drop module resolution overall only keep classic

Closes vscode build

As this allows to write a single build instruction that works via loader resolveId hooks in every context

• PR: Incremental refactoring to web-modules microsoft/vscode#167505

Closes Electron Issues

This closes the ESM Resolution Issues cross context which are the real problems that the users face when developing cross context cross module system boundary.

• Support Node's ES Modules electron/electron#21457

Closes Rollup Issues

• Rollup should fail on extensionless imports in a type: module package rollup/rollup#4301

Copyed from package maintainance discussion as aggreed on that this is future not current

This could be better adddressed when the Plugin Hook Loader API Exists and would get used without Package.json resolve or at last a none magical package.json resolve that is explicitly written in a reuseable loader.. As that exists in all other Engines also

• https://github.com/microsoft/playwright-java <= ships whole NodeJS to get Playwright running which has less then 5mb raw code in ESM none minified all comments included. so shipping graal-node (A NodeJS Fork to run nodejs ECMAscript on GraalVM) GraalVM Comiplier including all needed tools to run and build that takes ~2GB only Runtime not debug dev.
• - The whole graal-node wrapper exists only because of package.json and the nodejs cjs ecosystem. not because GraalVM has leaking functonality or that they need to support the well defined Node ABI in fact they have directly LLVM bindings no need for wrapper code and they can even execute ECMAscript more performant on most long time workloads in GraalJS without graal-node which is nodejs with a v8 replacement that uses graaljs
• https://www.bloomberg.com/company/stories/10-insights-adopting-typescript-at-scale/ shows a lot of problems with typescript that now get multiplyed into issues like
  • A Proposal For Module Resolution microsoft/TypeScript#50152
    • Which opens up node12 node14 nodeNext node16 module like resolutions. not because ESM is not working.
• The whole deno nodejs compat stack exists not because of the great nodejs abi also rust in fact again has LLVM directly it exists because of package.json and CJS nodejs compat.
  • npm specifiers roadmap denoland/deno#15960
• https://github.com/nodejs-mobile/nodejs-mobile a mobile fork of nodejs using the ios or android ECMAScript engine only to offer resolve package json support again its not the problem that Android or IOS got no api's to link too
• @ljharb one of the most active spec people i meet him all over the ecosystem pointed out
  • transpil everything to CJS to get it at last running
    • leaves us to solutions like we use them with the Monaco Editor we create a HTML Component Module as Iframe to isolate the CJS Context for security implementations and isolations. which would be again provided out of the box by ECMAScript
  • he also sayed creating CJS from ESM and that is also a valid conclusion that i also got everything else is doomed.
  • he pointed out that AirBnb forces anti patterns to please the bundler they do module.exports = function to re combine into a module later with a bundler see the ECMAScript spec for modules they consist only out of string propertys thats what they are a Module as he also pointed out everything should be something and in case of ECMAScript Modules it should always be a Module if it gets imported and not used via Require directly Require is more like the nativ import of a ECMAScript engine in case of NodeJS it applys around 5 or even more diffrent module types. Ranging from package.json modules to json modules to nativ code dlopen to CJS import JS.

Also interristing observation

• all none nodejs ECMAScript engines that depend on ECMAScript do not have any module reuse exchange problems.
• all none nodejs ECMAScript engine ship NodeJS or a NodeJS fork to load ECMAScript Modules written for NodeJS as a language.
  • It is importent to keep in mind ECMAScript is a UTF8 Char based language it should run without nativ code anywhere.
  • console.log('') should not require a 4gb stack of binary instructions. to build in a away that it is useable in many places out of the box.

Identified Fundamentals when incremental upgrading CJS to ESM

• noSideEffects everything with a sideEffect is not a Module its a Script.
• try to run the code isolated with "use strict" on top if it works it is a indicator that you can do a ESM Wrapper where you use import and correct the namedExports and then bundle that to get relativ clean ESM if the CJS code has no additional dependencies left over so is already like a bundle.
• make sure that there is no usag of this. outside Classes. functions that use this are highly danger later for code hardening and security analyzes Many people like the author of "clean code" a book that maybe all know here pointed that out. This security reasons are by the way a blocker for commercial adoption of ECMAScript in general.
  • see: above mentioned educational fundamental problems. As rule of thumb you need to be execution Context aware.
• You should treat JS/ECMAScript like lua with dynamic JIT Build abilitys. in Fact a lua and ECMAScript have many common and the amount of ECMAScript engines is exploding so it gets more and more a lua replacement.
• You should be aware of the fact that there will be no original Python 4 and the reasons for that.

Short Conclusion

package.json when used for anything else then referencing a main + dependencies is a bad thing. For Example the new import maps features overlap with ECMAScript import as soon as used you need to recode them the reuse the code. This could be directly done as additional js file that only injects the dependencie specifiers.

also the whole scripts section can be replaced by simply putting the same scripts into the folder and run node script.js and not npm run-script build which calles node build.js the list is endless. Then on Top the Require CJS breaks everything as it simply supports to much diffrent resolutions and module types.

[lemanschik]

Closing in Favor of No CLI Solution We Simply keep user land snapshot api and directly load the mksnapshots and call it a day. Only the vscode ESM code migration needs attention typescript and nodejs can simply process indipendent and will get superseeded by the browser with the nativ filesystem access api