8 ms·
> The transition from CommonJS to ES modules has been slow and full of terrors. > Bun supports both module systems, all the time. No need to worry about file
by lhnz 3y ago
> The transition from CommonJS to ES modules has been slow and full of terrors.
> Bun supports both module systems, all the time. No need to worry about file
> extensions, .js vs .cjs vs .mjs, or including "type": "module" in your
> package.json.
>
> You can even use import and require(), in the same file. It just works.
This is the highlight for me. The Node.js ecosystem is more-or-less completely broken otherwise. This might save it.
(I think that the most impressive thing about Bun isn't its performance but the pragmatic, developer-friendly choices that have been consistently made by Jarred.)
- Rapzid 3y agoI've been creating module projects as default for nearly a year now. It's been largely fine for the past 6 months since Typescript 5.0 released with the "bundler" resolution strategy. Very rarely run into issues but have gotten around with pnpm patch and meta modifications in the past until projects have fixed issues.. My take is 2023 is the year of the module. The water is fine.
- Rapzid 3y agoI don't usually comment on downvotes and I have just under 5k karma so it's uhh, just no thing to me typically.. It's also against the guidelines, but again 5k karma... That said, kinda curious now downvoted into negative for sharing my, extensive, experience creating module type projects.. Hrrmmm.
- c-hendricks 3y agoSo almost 10 years after modules were added to the spec, a few years after they've been available in most browsers, the past 6 months have been largely fine to use them for _new_ projects. That doesn't paint a great picture.
- Rapzid 3y agoWhen I say fine I mean I've had no complaints with any aspect of my workflow since TypeScript released the bundler resolution strategy, which mostly just means you no longer need to specify extensions when importing.. I don't know about the past 10 years as I haven't tried to use modules for the past 10 years. I've been using them for the past year on new AND existing projects with Vite+React, Vite+Storybook, SWC+Fastify, Rollup and library projects, and etc. Unless somebody has to work in the past I'm sure what relevance that has on using modules in 2023.
- lemper 3y agoyes, definitely and completely broken. require and import differentiation the most retarded changes, broke my build. spent sometime to understand the substantial difference, turned out it's nothing too substantial.
- pier25 3y agoIt's anecdotal but I switched to ESM in Node a couple of years ago. Never experienced any problem. My stack is usually Fastify with official plugins and a PG client.
- jakubmazanec 3y agoFrom my experience, the feeling that "Node.js ecosystem is more-or-less completely broken" comes only when you're trying to create package supporting both CommonJS and ESM (see https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c?permalink_comment_id=3850849#gistcomment-3850849 https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3...). Just rip the ban-aid and convert all your code to ESM and you'll be much happier (otherwise you experience something like https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/ https://blog.isquaredsoftware.com/2023/08/esm-modernization-...).
- The_Colonel 3y ago"just convert all your code to..." I remember hearing that once from the Python devs...
- jakubmazanec 3y agoI don't use Python, but AFAIK the differences between Python 2 and 3 and the effort needed to upgrade are higher then ESM vs CommonJS. But that's not relevant anyway; I'm not saying the upgrading to ESM-only is easy, I'm saying in the end, it's easier than trying to support both module formats.
- Touche 3y agoThis 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 agoIn a sense, an opinionated collection of tools _is_ a solution.
- kwhitley 3y agoYeah, 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 agoThe 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 agoNo, 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 agoAssuming 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?
- vorpalhex 3y agoThis is what I pushed Node to support when they proposed their split syntax and I'm very happy to see Bun adopt this. It is the "correct" way as far as I'm concerned. Node's split ecosystem has really hurt the entire language and runtime.
- defen 3y agoIs there a quick summary of the problem somewhere? I haven't worked on frontend stuff in nearly a decade.
- acemarke 3y agoFrom a package maintainer standpoint, trying to support both ESM and CJS in the same published package is a _nightmare_. I wrote an extensive post a few weeks ago detailing all the pain that I've dealt with and problems I've run into this year trying to modernize the Redux packages to fully support ESM and CJS: - https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/ https://blog.isquaredsoftware.com/2023/08/esm-modernization-... I've gotten a lot of feedback from other maintainers saying they've run into similar issues. Also had a couple podcast discussions following up on that topic: - https://syntax.fm/show/661/supper-club-shipping-esm-with-mark-erikson https://syntax.fm/show/661/supper-club-shipping-esm-with-mar... - https://changelog.com/jsparty/290 https://changelog.com/jsparty/290
- yoz 3y agoOh my god, thank you for this. I expected a bad situation, but I underestimated the badness by several orders of magnitude. Makes me want to never touch JS again.
- wdb 3y agoStill not clear to me what ESM exactly fixes. CJS works pretty well for me. The amount of pain ESM gives in unit tests is enough to ignore ESM. Maybe Bun will make a difference here.
- 3y ago
- colordrops 3y agoSeems like a bad idea to support both. Encourages bad behavior and half-ass code. I've had no problem moving codebases to es6 without a ton of effort. Maybe at most, hide the capability behind an execution flag.
- sintaxi 3y agoYou may not be aware that node created a situation where ESM maximizes compatibility when consuming libraries and CJS maximizes compatibility when producing libraries. Its a circular incentive paradigm. I suspect you are consuming libraries using "import" and everything "just works". Well, under the hood you are likely importing many libraries that use CJS "module.exports" because that is what libraries use to ensure their library can be used with both import/ESM AND require/CJS. The only solution to this problem is to upgrade require work for importing ESM. Once that is implemented ESM will become the natural choice for those publishing libraries. Until that happens library authors are going to continue to use CJS so their libraries are available to everyone.
- WorldMaker 3y agoThe last version of Node that only supported CJS libraries has already long faded out of LTS. In my opinion, more libraries should just rip the band-aid off and entirely stop publishing CJS. Sure that will upset some downstream dependencies, but semver major tag it, and many of the downstream dependencies need the kick in the pants to move to ESM anyway.
- swyx 3y agoagree. i ought to be a javascript expert by now but nothing makes me feel dumber than navigating all the type:module and .js/cjs/mjs/ts stuff. for a production app of course you should be clear about what you are writing. but for prototyping Bun's permissiveness lets me write code first and worry about the rest later.
- pests 3y agoI've been writing JavaScript for a long... long... time and I've kinda zoned out the last few years with regards to ESM vs CSJ I only know that I perfer writing import over require as those semantics and syntax make more sense to me.
- afgrant 3y agoFor the benefit of the future reader, I’m guessing you meant “CJS”, short for CommonJS.
- arjvik 3y ago> for a production app of course you should be clear about what you are writing Agree in sentiment, but I don't think this even applies to the module/import mess. My experience has been that the difficulty is in using different packages that made different choices, and making them interop with your own code. I have still yet to make top-level await work in a Typescript codebase where I need to import nontrivial packages. I don't think you should ever need to worry about the specific way your modules are imported, not in prototyping or in production.
- rubyn00bie 3y agoEvery few years I end up having to write a bunch of JavaScript-- and recently it was time again for me to dig in. The `import` vs `require` thing caused me HOURS of pain. The modern JS ecosystem is truly painful if you're not using a react app or some off-the-shelf solution-- and I am not, I'm writing a small library. I honestly can't even fathom how difficult and maddening it has to be for folks just getting started. The fact Bun solves that problem is more than enough of a reason for me to give it a try, I'm honestly fucking stoked to try it out, and I never thought I'd have those feelings for yet another JS runtime or build tool. Big thanks to the Bun folks, I'm looking forward to gaining some sanity in my day.