7 ms·

Did you read the article? He explains the motivation for the change pretty clearly.

WorldMaker 3y ago
The motivation seems to be "many people have transpilers configured wrong" and this seems an extreme solution to fixing people's transpiler configurations. Especially because it will still fail for modules using top-level await (anywhere in their dependency graph), so it is at best a band-aid. Beyond that it does seem to be missing real motivating use cases. What real reason in 2024 is there to use CommonJS at the top level in NPM? How hard is it to rewrite `require()` statements to `await import()` ones, especially when the fix is a transpiler configuration change away?
- pquki4 3y ago
  I don't know how much experience you have, but in the JS world there are band-aids everywhere. They "fix" a lot of real-world problems, help push things to production, and are more important than you think. Just look at the typing gymnastics in TypeScript.
  - lloydatkinson 3y ago
    The solution to band aids existing isn’t to introduce more, especially not more that are useless.
    - pquki4 3y ago
      1. I don't agree this is useless. You may very likely never need to use it, but not for others. 2. Until every single JavaScript file in the world is in the ESM format, anything that happens before that will be a band aid of some sort.
  - WorldMaker 3y ago
    > I don't know how much experience you have Try better to avoid ad hominem attacks, please. > but in the JS world there are band-aids everywhere I apologize, "band-aid" was the wrong word to use for this specific case, because that unintentionally disparages "band-aids". You are right there are "band-aids" that fix real-world problems, and help heal accidental wounds. This experiment does neither and seems to me worse than a "band-aid". It's a fragile broken and fake bridge that looks like it can get you to your destination but will collapse right under you if you try to use it (rather than switching to what already works today).
    - pquki4 3y ago
      Sorry to disappoint you, half of the things in the JS world are half baked, broken, and are fake bridges. That's why I need to mention experience -- it is hard to explain all of this within a few sentences if you don't already have the context of what I am trying to say.
- paulddraper 3y ago
  > many people have transpilers configured wrong ? It's so that CommonJS modules can use ESM modules. --- Like suppose examplelib uses otherlib, both in CommonJS. The examplelib wants to upgrade otherlib, but the new version uses ESM. Now, examplelib is stuck either on the old version, or has to undertake a rewrite (and propagate this situation downstream). Or adopt a transpiler and force downstream users to do the same. Some would say "just rewrite in ESM" and that is a nice idea, but there are lots of tools with caveats, TypeScript, Jest, anything that depends on require-in-the-middle, etc. It's hard to boil the ocean. (Just look at Python 3.)
  - WorldMaker 3y ago
    CommonJS modules (and anybody else that prefers or needs "require-in-the-middle") can already import ESM. They need to use `await import()` or `import().then()` if they prefer callback waterfalls to async/await syntax. That works everywhere in Node today. Sure, it's a pain when upstream switches to ESM that you have to use more Promises, but that the price you pay and it is certainly a lot less work than a full rewrite even for the most brownfield CommonJS library. You don't have to rewrite everything to ESM all at once. (You should want to, but don't have to.)
    - paulddraper 3y ago
      Exchanging one function coloring problem for another isn't what I would call "less work."
- wdb 3y ago
  It's quite difficult to write require() to `await import()` due to the introducing of `await`... Now everything needs to become async
  - WorldMaker 3y ago
    If your upstream has switched to ESM and expects to do async things, then yes, everywhere you depend on that upstream you need to consider those imports async. Yes, it's contagious, but your upstream already caught that contagion. Trying to keep smashing it into a synchronous box seems like a recipe for unexpected bugs. Especially in the case of this experiment where the difference between "works" and "gives the same error it already gives today" is a one keyword change anywhere in the upstream file. That sounds brittle to me and less useful than "everything needs to become async".
    - wdb 3y ago
      Just not upgrading and use patch-package to apply security fixes work so far.

The motivation seems to be "many people have transpilers configured wrong" and this seems an extreme solution to fixing people's transpiler configurations. Especially because it will still fail for modules using top-level await (anywhere in their dependency graph), so it is at best a band-aid. Beyond that it does seem to be missing real motivating use cases. What real reason in 2024 is there to use CommonJS at the top level in NPM? How hard is it to rewrite `require()` statements to `await import()` ones, especially when the fix is a transpiler configuration change away?

pquki4 3y ago
I don't know how much experience you have, but in the JS world there are band-aids everywhere. They "fix" a lot of real-world problems, help push things to production, and are more important than you think. Just look at the typing gymnastics in TypeScript.
- lloydatkinson 3y ago
  The solution to band aids existing isn’t to introduce more, especially not more that are useless.
  - pquki4 3y ago
    1. I don't agree this is useless. You may very likely never need to use it, but not for others. 2. Until every single JavaScript file in the world is in the ESM format, anything that happens before that will be a band aid of some sort.
- WorldMaker 3y ago
  > I don't know how much experience you have Try better to avoid ad hominem attacks, please. > but in the JS world there are band-aids everywhere I apologize, "band-aid" was the wrong word to use for this specific case, because that unintentionally disparages "band-aids". You are right there are "band-aids" that fix real-world problems, and help heal accidental wounds. This experiment does neither and seems to me worse than a "band-aid". It's a fragile broken and fake bridge that looks like it can get you to your destination but will collapse right under you if you try to use it (rather than switching to what already works today).
  - pquki4 3y ago
    Sorry to disappoint you, half of the things in the JS world are half baked, broken, and are fake bridges. That's why I need to mention experience -- it is hard to explain all of this within a few sentences if you don't already have the context of what I am trying to say.
paulddraper 3y ago
> many people have transpilers configured wrong ? It's so that CommonJS modules can use ESM modules. --- Like suppose examplelib uses otherlib, both in CommonJS. The examplelib wants to upgrade otherlib, but the new version uses ESM. Now, examplelib is stuck either on the old version, or has to undertake a rewrite (and propagate this situation downstream). Or adopt a transpiler and force downstream users to do the same. Some would say "just rewrite in ESM" and that is a nice idea, but there are lots of tools with caveats, TypeScript, Jest, anything that depends on require-in-the-middle, etc. It's hard to boil the ocean. (Just look at Python 3.)
- WorldMaker 3y ago
  CommonJS modules (and anybody else that prefers or needs "require-in-the-middle") can already import ESM. They need to use `await import()` or `import().then()` if they prefer callback waterfalls to async/await syntax. That works everywhere in Node today. Sure, it's a pain when upstream switches to ESM that you have to use more Promises, but that the price you pay and it is certainly a lot less work than a full rewrite even for the most brownfield CommonJS library. You don't have to rewrite everything to ESM all at once. (You should want to, but don't have to.)
  - paulddraper 3y ago
    Exchanging one function coloring problem for another isn't what I would call "less work."
wdb 3y ago
It's quite difficult to write require() to `await import()` due to the introducing of `await`... Now everything needs to become async
- WorldMaker 3y ago
  If your upstream has switched to ESM and expects to do async things, then yes, everywhere you depend on that upstream you need to consider those imports async. Yes, it's contagious, but your upstream already caught that contagion. Trying to keep smashing it into a synchronous box seems like a recipe for unexpected bugs. Especially in the case of this experiment where the difference between "works" and "gives the same error it already gives today" is a one keyword change anywhere in the upstream file. That sounds brittle to me and less useful than "everything needs to become async".
  - wdb 3y ago
    Just not upgrading and use patch-package to apply security fixes work so far.