Seriously though it is nice, but migrating away from your existing tooling is painful and underappreciated.
And we had huge dependency chains as well to non-standard library stuff, nowhere near as bad as an average nodejs project but still not free from the problem.
npx prettierGenius!
Arguably, code formatters should be configurable, to get a format for your code that you want. Unfortunately, prettier isn't one, and it is a form of regression in many communities at the cost of choice pruning.
It might be great for a CI pipeline for constraining how code should look (use prettier, dumbass!), but it isn't great for actually formatting code, as it just makes the code "prettier".
Even though prettier has defaults, but they can be modified to quite some extent to suit your projects needs: https://prettier.io/docs/options
That is the point of a formatter, so any formatter would do that (and there were many more active projects to allow formatting before prettier came around).
> quite some extent
Not really, and I have written prettier plugins to get around that constraint.
IMO, its not great, which is kind of how things work out when you try to do everything in one project.
No arguments here. You are free to choose the formatter you want.
> Not really, and I have written prettier plugins to get around that constraint.
Or you could simply use those better formatters you were talking about.
My fear with Biome is missing out on type-aware lints, but I know Oxlint has had some success integrating the new Go typescript compiler, so maybe that will work out for Biome as well.
Thankfully, actively-maintained CommonJS-only packages are quite rare by this point (in my experience).
> our downstream NPM consumers wouldn't be able to consume EJS
Node.js 20.17 and later supports loading ESM using `require()`: https://nodejs.org/api/modules.html#loading-ecmascript-modul...
The next version of Babel (currently in beta) is even going ESM-only.
It's been a while since I've had a trouble importing an upstream CommonJS library. Often it is easy enough in the rare cases where upstream is particularly old/gnarly you can vendorize an ESM build with rollup or esbuild.
That said, CommonJS is also now a strong maintenance signal for me and if a library doesn't have recent ESM builds I start to wonder if it is at all well maintained and not just a pile of tech debt to avoid. JSR has started becoming my first place to search for a library I need, ahead of NPM, because of JSR's focus (and scoring systems) on ESM first and good Typescript types.
ESM, --watch, and TS syntax support is the combo that makes it all good!
The slow adoption of ESM by Node, with many compatibility missteps, the thousand papercuts around TS, the way frontend-centric toolchains kinda-sorta paper over the whole thing, letting it fester, and the way people have been acting like things are ready for primetime for over a decade while diligently testing them in production, all of that came later. To the point of having me wondering how did people work with TypeScript before ~5.4 - though evidently they did, and had few if any of the same complaints!
Baffling but IIWII. Anyway, only this year I discovered a pure `tsx` + ESM workflow had become viable OOTB, to no little surprise. I perceive that as the toolchain becoming unfucked just as randomly as it became fucked when Node 16 did what it did. Not that it didn't take a couple years for TS to "invent" the right compiler flags that it took to tell it to stay out of the runtime's way, too.
So a good year overall. Hope they don't break it again because when they do it's an uphill struggle to convince them that they have.
ESM modules just work with both Node and Typescript, Node can run .ts files, and there's the a good enough test runner built in. --watch. The better built in packages - `node:fs/promises` - are nice with top-level await for easier async loops.
It took a while to convince everyone involved to just be pragmatic, but it's nice now.