Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
Interesting, do you mean converting existing packages to use ES syntax? Might start taking a look at that. In your organization, do you convert existing projects? I'd definitely love to help out!
Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
Simple answer: Ideally yes, converting existing packages would save a LOT of time an effort
Complex answer: Converting existing packages -- in most cases -- is a lost cause
ESM is strict by default, meaning most very old libs can't be converted without significant rewrites.
Likewise, packages that ship ESM for Webpack (ie not spec ESM) or CommonJS use a lot of old/bad patterns: conditional imports, synchronous import behavior, globals, node-specific imports, etc.
A good quality ESM package...
shouldn't depend on runtime-specific behavior
should use relative imports
should use named exports
should tree-shake dead code
So far, most of the projects have been built by scratch. Of course, now that ESM is officially supported in Node 14.x more existing libs may be open to switching. I'm always open to migrating an existing project over if the project's Maintainer is on board.
If you want to help, the computer-science repo is a good place to get a feel for working w/ ESM. You can post ideas and discuss org-wide stuff in this repo github.com/vanillaes/vanillaes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
ES Module versions of everything. With ESM there is so much untapped potential for optimization.
I have done a bunch of work in the VanillaES org but that's just the start.
github.com/vanillaes
Interesting, do you mean converting existing packages to use ES syntax? Might start taking a look at that. In your organization, do you convert existing projects? I'd definitely love to help out!
Simple answer: Ideally yes, converting existing packages would save a LOT of time an effort
Complex answer: Converting existing packages -- in most cases -- is a lost cause
ESM is strict by default, meaning most very old libs can't be converted without significant rewrites.
Likewise, packages that ship ESM for Webpack (ie not spec ESM) or CommonJS use a lot of old/bad patterns: conditional imports, synchronous import behavior, globals, node-specific imports, etc.
A good quality ESM package...
So far, most of the projects have been built by scratch. Of course, now that ESM is officially supported in Node 14.x more existing libs may be open to switching. I'm always open to migrating an existing project over if the project's Maintainer is on board.
If you want to help, the
computer-sciencerepo is a good place to get a feel for working w/ ESM. You can post ideas and discuss org-wide stuff in this repo github.com/vanillaes/vanillaes.