You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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.
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.
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
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.
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.
The text was updated successfully, but these errors were encountered:
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
Stake Holder list
Ambient Loader Progress
--import
flag nodejs/node#43942 and nodejs/node@77cb88bThe 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:
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 vscode build
As this allows to write a single build instruction that works via loader resolveId hooks in every context
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.
Closes Rollup Issues
type: module
package rollup/rollup#4301Copyed 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
Also interristing observation
Identified Fundamentals when incremental upgrading CJS to ESM
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.
The text was updated successfully, but these errors were encountered: