5 ms·

This problem is very old at this point. I'm doubtful that Bun has "solved it" any more than other tools. They've just selected a different set of trade-offs tha

by Touche 3y ago

This problem is very old at this point. I'm doubtful that Bun has "solved it" any more than other tools. They've just selected a different set of trade-offs that will result in a different set of packages not working. Is there a reason to think they've cracked some code that other tools were unable to?

mmcnl 3y ago
In a sense, an opinionated collection of tools _is_ a solution.
kwhitley 3y ago
Yeah, definitely recommend you try it before discounting... I too have been super jaded with the current Node import ecosystem (esp. as an author), but Bun has basically become something of a silver bullet, with some small exceptions. If I want, I can literally run a TS file directly with mixed import/require (not that you would ever) directly, without a package.json, tsconfig, dependencies, etc. In my experience, it's basically Node, minus all the setup/config/build headaches.
eyelidlessness 3y ago
The compiler is the bundler is the runtime. The reason it’s such a problem on Node is because the tools are separate and often conceptually at odds.
- Touche 3y ago
  No, it's a problem because the formats are fundamentally incompatible and it's impossible to infer the author's intent. A package with no imports/exports or requires could be either ESM or CJS and no heuristic can solve for that reality.
  - jwalton 3y ago
    Assuming it has no imports or requires, and no references to meta, it’s a bare JavaScript file, and whether you treat it as esm or cjs shouldn’t matter, no?
    - lhorie 3y ago
      JS has two top level grammars, one defaults to loose mode and the other defaults to strict mode, among other nuances. Possibly the most devious nuance is whether the spec's appendix B applies, which affects whether html comment syntax is valid (yes, this is a thing). The html comment token can therefore be parsed either as a comment or as a series of operators depending on the grammar being used. Effectively, this means it's possible to craft a program that does different things in CJS vs ESM mode.
  - AaronFriel 3y ago
    How common are packages with no imports, exports, requires, or "module.exports="? I imagine that's quite rare, because such a package would only be imported or required for its side effects; and because that package cannot import or require any others, could you safely just assume that if it was `require()`ed use CJS, and if it was `import`ed, use ESM?
    - Touche 3y ago
      Rare things still happen a lot at the scale of npm. And due to transitive dependencies it winds up affecting a lot of actual users. And this is just one example of an incompatibility, there are many more. Bun didn't discover a silver bullet here that dozens of other tools in the past missed on.
      - fkyoureadthedoc 3y ago
        > And this is just one example of an incompatibility, there are many more Such as? If you could provide 5-10 of your many examples and why you think that Bun's approach doesn't solve them it would be very helpful.
        throw10920 3y ago
        Yeah, I don't believe GP. Their assertions that Bun hasn't solved this (or that the heuristic used is inadequate) are basically based on speculation without any evidence.
        3np 3y ago
        Jarred even came here and agree with them. It's nothing controversial. Just nuance. No need to flame. DYOR.
      - AaronFriel 3y ago
        Do you have an empirical basis for that? I'm curious because on one hand, Bun is advertising they are solving a major challenge for library authors, really betting quite heavily on that being persuasive for adoption. The risk for Bun's adoption is that they're wrong, of course. The risk for Node's usage is that they're right, and library authors begin urging users to use Bun because it's 100x easier than making a useful library with Node. (This will happen very slowly, but things that happen very slowly can start happening all at once very quickly.)
lhnz 3y ago
Maybe the trade-offs are better? https://twitter.com/threepointone/status/1698271991927648643 https://twitter.com/threepointone/status/1698271991927648643
Jarred 3y ago
In Bun, you can use import and require in the same file. There's three steps for what makes this work: 1) We patched JavaScriptCore to load ES Modules synchronously when they don't use top-level await. The main tradeoff here is that requiring an ES Module which uses top-level await is unsupported (Bun throws an exception when you try to do this) 2) To support require() inside ES Modules, we add `import.meta.require` and have a transpiler integration to convert calls to module.require() or require() into import.meta.require(). This either loads the file as an ES Module or as a CommonJS module, depending on what the transpiler says it is 3) We rely on certain heuristics to decide whether a script is an ES Module or a CommonJS module. If they use certain sloppy mode or CommonJS-only features, it becomes CommonJS. If they use ESM features or it's somewhat ambiguous, it becomes an ES Module.
- jwalton 3y ago
  I’ve often wondered why node doesn’t do 1 in this list. It would solve 95% of the problems, I’m sure.
- jcheng 3y ago
  For 1), what about requiring an ES module that doesn’t itself use top-level await, but imports another ES module that uses top-level await?
  - Jarred 3y ago
    That throws since we cannot make it synchronous. It works by reading the internal state of the Promise and getting the value out of it if the Promise is fulfilled.
- TimTheTinker 3y ago
  While I appreciate the convenience that will result from this excellent engineering, I'm concerned that this could result in a lot of mixed module files that now can only work with Bun. Is there an option to require each file to use either CJS or ESM features, but not both? If not, may I suggest adding that option?

by Touche 3y ago

mmcnl 3y ago

In a sense, an opinionated collection of tools _is_ a solution.

kwhitley 3y ago

Yeah, definitely recommend you try it before discounting... I too have been super jaded with the current Node import ecosystem (esp. as an author), but Bun has basically become something of a silver bullet, with some small exceptions. If I want, I can literally run a TS file directly with mixed import/require (not that you would ever) directly, without a package.json, tsconfig, dependencies, etc. In my experience, it's basically Node, minus all the setup/config/build headaches.

eyelidlessness 3y ago

The compiler is the bundler is the runtime. The reason it’s such a problem on Node is because the tools are separate and often conceptually at odds.

Touche 3y ago
No, it's a problem because the formats are fundamentally incompatible and it's impossible to infer the author's intent. A package with no imports/exports or requires could be either ESM or CJS and no heuristic can solve for that reality.
- jwalton 3y ago
  Assuming it has no imports or requires, and no references to meta, it’s a bare JavaScript file, and whether you treat it as esm or cjs shouldn’t matter, no?
  - lhorie 3y ago
    JS has two top level grammars, one defaults to loose mode and the other defaults to strict mode, among other nuances. Possibly the most devious nuance is whether the spec's appendix B applies, which affects whether html comment syntax is valid (yes, this is a thing). The html comment token can therefore be parsed either as a comment or as a series of operators depending on the grammar being used. Effectively, this means it's possible to craft a program that does different things in CJS vs ESM mode.
- AaronFriel 3y ago
  How common are packages with no imports, exports, requires, or "module.exports="? I imagine that's quite rare, because such a package would only be imported or required for its side effects; and because that package cannot import or require any others, could you safely just assume that if it was `require()`ed use CJS, and if it was `import`ed, use ESM?
  - Touche 3y ago
    Rare things still happen a lot at the scale of npm. And due to transitive dependencies it winds up affecting a lot of actual users. And this is just one example of an incompatibility, there are many more. Bun didn't discover a silver bullet here that dozens of other tools in the past missed on.
    - fkyoureadthedoc 3y ago
      > And this is just one example of an incompatibility, there are many more Such as? If you could provide 5-10 of your many examples and why you think that Bun's approach doesn't solve them it would be very helpful.
      - throw10920 3y ago
        Yeah, I don't believe GP. Their assertions that Bun hasn't solved this (or that the heuristic used is inadequate) are basically based on speculation without any evidence.
        3np 3y ago
        Jarred even came here and agree with them. It's nothing controversial. Just nuance. No need to flame. DYOR.
    - AaronFriel 3y ago
      Do you have an empirical basis for that? I'm curious because on one hand, Bun is advertising they are solving a major challenge for library authors, really betting quite heavily on that being persuasive for adoption. The risk for Bun's adoption is that they're wrong, of course. The risk for Node's usage is that they're right, and library authors begin urging users to use Bun because it's 100x easier than making a useful library with Node. (This will happen very slowly, but things that happen very slowly can start happening all at once very quickly.)

lhnz 3y ago

Maybe the trade-offs are better? https://twitter.com/threepointone/status/1698271991927648643 https://twitter.com/threepointone/status/1698271991927648643

Jarred 3y ago

In Bun, you can use import and require in the same file. There's three steps for what makes this work: 1) We patched JavaScriptCore to load ES Modules synchronously when they don't use top-level await. The main tradeoff here is that requiring an ES Module which uses top-level await is unsupported (Bun throws an exception when you try to do this) 2) To support require() inside ES Modules, we add `import.meta.require` and have a transpiler integration to convert calls to module.require() or require() into import.meta.require(). This either loads the file as an ES Module or as a CommonJS module, depending on what the transpiler says it is 3) We rely on certain heuristics to decide whether a script is an ES Module or a CommonJS module. If they use certain sloppy mode or CommonJS-only features, it becomes CommonJS. If they use ESM features or it's somewhat ambiguous, it becomes an ES Module.

jwalton 3y ago
I’ve often wondered why node doesn’t do 1 in this list. It would solve 95% of the problems, I’m sure.
jcheng 3y ago
For 1), what about requiring an ES module that doesn’t itself use top-level await, but imports another ES module that uses top-level await?
- Jarred 3y ago
  That throws since we cannot make it synchronous. It works by reading the internal state of the Promise and getting the value out of it if the Promise is fulfilled.
TimTheTinker 3y ago
While I appreciate the convenience that will result from this excellent engineering, I'm concerned that this could result in a lot of mixed module files that now can only work with Bun. Is there an option to require each file to use either CJS or ESM features, but not both? If not, may I suggest adding that option?