Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
TS-ESNode
Node.JS Loader hook to transform typescript source and files as node loads them TS-ESNode. TS-Node for ESNext & ESModule Node.JS.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
That repo is for Yarn v1.
V2 (now v3 ...) lives at https://github.com/yarnpkg/berry.
No idea why they did it that way. Probably because Yarn 1 is still very actively used, and things would get confusing otherwise.
Bundler is part of Ruby since 2018: https://github.com/ruby/ruby/commit/59c8d50653480bef3f245172...
But, it's irrelevant. I'm not arguing no one should make a third-party package manager, just that there should be a standard, ideally first-party one, that is good and well supported.
Languages like Ruby, Rust, Swift have recognized it is beneficial for the core project to provide a package management solution.
Regarding the enforcement of the NPM version: ever heard of https://volta.sh?
CommonJS is a great module system if you're using JS for scripting Unix (which it excels at). Is there a good reason to use ESM though? I've been half-joking that it's the "extinguish" phase of Microsoft's EEE strategy for JS.
I know one legitimate reason is "tree shaking" (source-level LTO when bundling modules). Dumber, static import/export statements probably simplify that in some way. However ESM destroys the isomorphism between JS modules and the filesystem.
One change that ES modules introduced, I think, for no other reason than to be backwards incompatible, is changing the behavior of the default export (`export default foo` transpiles down to `module.exports.default = foo` instead of `module.exports = foo`).
Other "ohai guys this is the new normal now" kinds of changes are making the dynamic imports async-only (after not supporting them for a while) as well as changing the behavior of module resolution.
And the cherry on top is called TS-ESNode: https://github.com/K-FOSS/TS-ESNode because TypeScript modules and ESM are the same thing yet you need to somehow find this third-party shim which is required for them to work together at all. It's enabled by wrapping the interpreter, just like Yarn2's new dependency resolution.
Except that the format of the npm cache is version-specific. You would probably be better off using https://github.com/heikkipora/registry-sync instead.