3 ms·

>NodeJS can officially drop support for require and module.exports in a future version, creating a bit more pressure to migrate. This will never, ever happen.

>NodeJS can officially drop support for require and module.exports in a future version, creating a bit more pressure to migrate. This will never, ever happen. Too much of the foundational ecosystem relies on it.

tqwhite 2y ago
An insanely bad idea.
game_the0ry 2y ago
> This will never, ever happen. I hope for the sake of the nodjs ecosystem, you are wrong. Fragmentation issues are one of the many reasons that nodejs struggle with adoption.
- bastawhiz 2y ago
  If it does happen, it'll only cause more fragmentation. Because lots of projects and libraries simply won't upgrade. Look at Python: it took them decades to get folks to upgrade to py3k because they broke the old code. Do it to Node and it'll be decades of fragmentation.
- dgb23 2y ago
  Breaking code that doesn’t need to be broken is the biggest redflag for a platform or foundational library.
- baq 2y ago
  > nodejs struggle with adoption Woah there. If nodejs is struggling for adoption I don’t know what isn’t.
  - game_the0ry 2y ago
    Let e put it differently: nodejs would have more adoption if it had less perceived instability.
jeswin 2y ago
> Too much of the foundational ecosystem relies on it. Not saying it needs to be done, but this can possibly be handled via a tranpiler layer. It might make CommonJS a bit slower to startup (but fully functional), which is an added incentive to move. Again, I don't have any opinion on whether this is a good thing. Like you said, too many modules depend on it.
- bastawhiz 2y ago
  > but this can possibly be handled via a tranpiler layer. It might make CommonJS a bit slower to startup (but fully functional), which is an added incentive to move. "The new version runs your old code slower and it's enough to notice" would be a death blow to the ecosystem. No major company is going to upgrade to that. It's already a project to drag a major codebase kicking and screaming to a new LTS release of your runtime (even if it makes code faster), do you really think folks will invest the time to work to make their code run slower unless they invest even more effort and modify ~every module in their codebase? ESM isn't implicitly good. The benefits of ESM are almost entirely theoretical for pretty much everyone who is content with CJS. I manage codebases right now that total half a million lines of typescript and js and I think I simply wouldn't notice any improvements from converting any of the code. The point being: this isn't a problem for me or people in similar situations, it's a problem for the folks working on Node and the standards. Forcing folks to upgrade or making their code worse to exert any kind of pressure does nothing to help anyone.
- mistercow 2y ago
  You don’t really even need a transpiler. Require is basically just a function which loads a file, wraps it in some boilerplate, and evals it. You could just rip that runtime code out of node and provide it as a compatibility library.

tqwhite 2y ago

An insanely bad idea.

game_the0ry 2y ago

> This will never, ever happen. I hope for the sake of the nodjs ecosystem, you are wrong. Fragmentation issues are one of the many reasons that nodejs struggle with adoption.

bastawhiz 2y ago
If it does happen, it'll only cause more fragmentation. Because lots of projects and libraries simply won't upgrade. Look at Python: it took them decades to get folks to upgrade to py3k because they broke the old code. Do it to Node and it'll be decades of fragmentation.
dgb23 2y ago
Breaking code that doesn’t need to be broken is the biggest redflag for a platform or foundational library.
baq 2y ago
> nodejs struggle with adoption Woah there. If nodejs is struggling for adoption I don’t know what isn’t.
- game_the0ry 2y ago
  Let e put it differently: nodejs would have more adoption if it had less perceived instability.

jeswin 2y ago

> Too much of the foundational ecosystem relies on it. Not saying it needs to be done, but this can possibly be handled via a tranpiler layer. It might make CommonJS a bit slower to startup (but fully functional), which is an added incentive to move. Again, I don't have any opinion on whether this is a good thing. Like you said, too many modules depend on it.

bastawhiz 2y ago
> but this can possibly be handled via a tranpiler layer. It might make CommonJS a bit slower to startup (but fully functional), which is an added incentive to move. "The new version runs your old code slower and it's enough to notice" would be a death blow to the ecosystem. No major company is going to upgrade to that. It's already a project to drag a major codebase kicking and screaming to a new LTS release of your runtime (even if it makes code faster), do you really think folks will invest the time to work to make their code run slower unless they invest even more effort and modify ~every module in their codebase? ESM isn't implicitly good. The benefits of ESM are almost entirely theoretical for pretty much everyone who is content with CJS. I manage codebases right now that total half a million lines of typescript and js and I think I simply wouldn't notice any improvements from converting any of the code. The point being: this isn't a problem for me or people in similar situations, it's a problem for the folks working on Node and the standards. Forcing folks to upgrade or making their code worse to exert any kind of pressure does nothing to help anyone.
mistercow 2y ago
You don’t really even need a transpiler. Require is basically just a function which loads a file, wraps it in some boilerplate, and evals it. You could just rip that runtime code out of node and provide it as a compatibility library.