Closed stevemarksd closed 2 years ago
wooorm
commented
2 years ago if people are not using the new esm as much, what is the point
This is exactly why it works. People can move when they’re ready.
You can move when you’re ready. I recommend moving soon.
Node.js, ts-node, and Next.js all support ESM currently.
Murderlon
commented
2 years ago I can add to that:
Unfortunately dual publishing is notoriously error-prone (I've seen some of the smartest engineers on big OSS projects accidentally mess this up) and a maintenance burden. Unified has hundreds of packages and moving them to ESM, which is the imminent future, makes more sense for the ecosystem than dual publishing and then refactoring everything again to ESM only at a later time. For the time being you will be safe and sound on a previous version until the ecosystem catches up. AFAIK we do security fixes also for previous majors.
stevemarksd
commented
2 years ago Node.js, ts-node, and Next.js all support ESM currently.
I wish that would be true. I spend more than 16 hours to make it work and was not possible.
This is exactly why it works. People can move when they’re ready.
Passed more than 6 months and most of your users are still using the old version. You are right, we will move when the tooling is there, but is not yet there as you can see from countless people struggling to use esm modules.
Unfortunately dual publishing is notoriously error-prone (I've seen some of the smartest engineers on big OSS projects accidentally mess this up) and a maintenance burden. Unified has hundreds of packages and moving them to ESM, which is the imminent future, makes more sense for the ecosystem than dual publishing and then refactoring everything again to ESM only at a later time. For the time being you will be safe and sound on a previous version until the ecosystem catches up. AFAIK we do security fixes also for previous majors.
I wish would be that easy, documentation is hard to find and I already wrote the code in an app that supported esm and now I need to do it again in an app that doesn't support. You can see my pain when the code needs a low of tweaks to downgrade. So now I'm having 2 versions of similar code. (I will get rid of the project that uses the esm version soon because is being deprecated. Is not using next.js and as you can say, it works with just ts-node).
Unfortunately dual publishing is notoriously error-prone
I rather have something that works 99.9%. I just forked a few projects and converted to cjs and works 100% so far. I just had to change the compiler to compile to cjs, no other code changes. Is not proof that the can work for every module, but I'm certain could be done for 99% of them.
Regarding the numbers, I think that's they key metric you could monitor. I think speaks a lot by itself and is a bit weird that people push so hard for esm, when the benefits are kind of marginal - for someone that already uses typescript, there is no much improvements.
I understand that your team and Sindre Sorhus agreed to don't publish cjs for certain reasons... and won't be changed any time soon, which is unfortunate and it will keep the whole node.js ecosystem fragmented.
Anyway, I shouldn't bother you anymore because it won't change. I wonder if you are ok for me to republish all your packages as non esm under another name? I know is not optimal, but we got to do what it works.
stevemarksd
commented
2 years ago Node.js, ts-node, and Next.js all support ESM currently.
I wish that would be true. I spend more than 16 hours to make it work and was not possible.
This is exactly why it works. People can move when they’re ready.
Passed more than 6 months and most of your users are still using the old version. You are right, we will move when the tooling is there, but is not yet there as you can see from countless people struggling to use esm modules.
Unfortunately dual publishing is notoriously error-prone (I've seen some of the smartest engineers on big OSS projects accidentally mess this up) and a maintenance burden. Unified has hundreds of packages and moving them to ESM, which is the imminent future, makes more sense for the ecosystem than dual publishing and then refactoring everything again to ESM only at a later time. For the time being you will be safe and sound on a previous version until the ecosystem catches up. AFAIK we do security fixes also for previous majors.
I wish would be that easy, documentation is hard to find and I already wrote the code in an app that supported esm and now I need to do it again in an app that doesn't support. You can see my pain when the code needs a low of tweaks to downgrade. So now I'm having 2 versions of similar code. (I will get rid of the project that uses the esm version soon because is being deprecated. Is not using next.js and as you can say, it works with just ts-node).
The funniest thing is that the old project without next.js works with esm only because we compile the node code with Webpack.. the irony, no? ESM is supposed to make life simpler, but makes us use Webpack. - and is a pain because it's not a smooth process to develop. Need one process for Webpack and one to auto restart the server... oh!
Unfortunately dual publishing is notoriously error-prone
I rather have something that works 99.9%. I just forked a few projects and converted to cjs and works 100% so far. I just had to change the compiler to compile to cjs, no other code changes. Is not proof that the can work for every module, but I'm certain could be done for 99% of them.
Regarding the numbers, I think that's they key metric you could monitor. I think speaks a lot by itself and is a bit weird that people push so hard for esm, when the benefits are kind of marginal - for someone that already uses typescript, there is no much improvements.
I understand that your team and Sindre Sorhus agreed to don't publish cjs for certain reasons... and won't be changed any time soon, which is unfortunate and it will keep the whole node.js ecosystem fragmented.
Anyway, I shouldn't bother you anymore because it won't change. I wonder if you are ok for me to republish all your packages as non esm under another name? I know is not optimal, but we got to do what it works.
ChristianMurphy
commented
2 years ago Node.js, ts-node, and Next.js all support ESM currently.
I wish that would be true. I spend more than 16 hours to make it work and was not possible.
I have projects with a combination of the above technologies, and they definitely do work with ESM. If you have questions on how to configure them the discussion forum of remark https://github.com/remarkjs/remark/discussions or of the tool in question can help point in the right direction.
Passed more than 6 months and most of your users are still using the old version. You are right, we will move when the tooling is there, but is not yet there as you can see from countless people struggling to use esm modules.
This is misinterpreting the statistics from npm. A majority of those downloads are from transitive dependencies, though Prettier, MDX, Gatsby, Next, etc. Those projects are adding or have already added ESM and remark latest support, there is a natural lag time for them to move over to the new version of remark (all of them are).
The hundreds of thousands of downloads on latest are precisely from folks who are directly using remark and have already migrated over.
Speaking from my own experience, I've found ESM to have an initial learning curve of making sure all the tools are configured correctly (something which has been getting better as tools default to support ESM). But the migration process itself is fairly painless.
There aren't many situations where CJS is needed anymore, and in those rare situations, a quick ESBuild process can do that conversion from ESM to CJS seamlessly.
stevemarksd
commented
2 years ago There aren't many situations where CJS is needed anymore, and in those rare situations, a quick ESBuild process can do that conversion from ESM to CJS seamlessly.
I might be wrong but one of the main selling points of ESM is to make development easier.
A majority of those downloads are from transitive dependencies, though Prettier, MDX, Gatsby, Next, etc.
Do you have any stats, Im really curious how you get that info. But also given they didn't move yet after almost 1 year, isn't an indication that the ecosystem is not yet there? Otherwise they would have moved already.
In the meantime wouldn't make sense to keep cjs for a bit longer?
Unfortunately dual publishing is notoriously error-prone (I've seen some of the smartest engineers on big OSS projects accidentally mess this up) and a maintenance burden.
Could you give some examples of real world issues? @Murderlon
wooorm
commented
2 years ago I totally understand that ESM is annoying. But reverting to CJS or switching to dual will not happen.
Otherwise they would have moved already.
What even is “there yet”. That, magically, in one year, every package on npm ever will switch to ESM? That, magically, all these open source tools will suddenly support ESM and CJS? Even the underfunded unmaintained ones like Jest? Is there some point where you get to say to maintainers: I’m ready now!
It’ll take some time for everyone to switch to ESM. It’ll get there. But for unified reverting to CJS is in no way getting ESM there. And the current state: upgrade when you’re ready, is a pretty good state to be in.
In the meantime wouldn't make sense to keep cjs for a bit longer?
It’ not viable: it took months to update 500+ projects. I’m not going to spends months reverting changes because you’re not ready. Months of my finite life. And its not a good idea: ESM is getting there. It’s bubbling up. So it makes sense that lower-level tools have upgraded first and higher-level tools will upgrade afterwards.
Do you have any stats 2
libraries.ioused to give this but apparently they don’t anymore. There are many tools to get download counts, which you can use to paint a picture in your head about how the chart would look But in short: 10 years of experience maintaining open source and talking to everyone.
Could you give some examples of real world issues? @Murderlon
This thread is off-topic and it keeps going so I’ll lock it. Feel free to ask questions about how to use ESM in Discussions.
Initial checklist
Problem
Modules provided are esm and not possible to work with isomorphic code with node.js / next.js / ts-node with custom server. I tried many options and still not working, so it's faster to just use previous version. This is a bad UX for devs and I think would not be too hard to publish cjs modules too. I read the whole thread here https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c (took me hours).
Please realise that typescript ecosystem is not working well with esm yet, please check your stats, they talk by themselves, people still using non esm version. I understand that people are trying to push esm very hard, but if people are not using the new esm as much, what is the point? (You are free to publish your code however you want, I'm just trying to explain that not everyone can use them. At this point seems impossible with my setup and I'm sure all the people getting the non esm module below are in the same boat.)
https://www.npmjs.com/package/remark
https://www.npmjs.com/package/remark-parse
Solution
Support cjs modules by building them in the npm.
Alternatives
No idea.. downgrade to previous version.
Issues: