Comment by zoogeny | Hacker News Reader

Comment by zoogeny | Hacker News Reader

Just tangentially related, but a few days ago I did a quick analysis on lint/format options for a TypeScript project and I ended up picking eslint and prettier over BiomeJS. The main reason was eslint/prettier are a bit more battle tested and according to Gemini Pro, Biome is still adding new features to catch up to eslint/prettier which makes me feel it will be a bit less stable for now.

But what I wanted to comment on actually was eslint and how it nudged me down the path of ESM support. I had to fight and fight to get it to work with my Typescript project. The resolution proposed by the tool was strongly biased towards re-structuring my project away from commonjs modules towards the newer ESM. But when I started down that rabbit hole I found it frustratingly hostile to TypeScript based projects. I was playing whack-a-mole between my package.json, tsconfig, my vite config, my eslint config. Most of it had to do with ts-node and the esm module loader (or something). Eventually it wanted me to rename all of my imports with .js extensions?

In the end I just gave up and went back to commonjs and added strategic "ignores". The modern JS ecosystem has mostly been turn-key, but this was a remembrance of the old days where it felt necessary to wave dead chickens over things to get them to work. I would seriously consider BiomeJS in the (near) future if it's Typescript story was better than what I've experienced with eslint.

And as for ESM, right now it is leaving a really bad taste in my mouth. I will have to dedicate some time soon to figure out how to setup a very basic TypeScript project using ESM and incorporating the basic tools that I require.

I went through exactly what you went through and by god it was frustrating.

Eventually I did get stuff to work, but in the process I became an expert in a bunch of tools that I never wanted to be an expert in. I just wanted to write my business logic :') It makes me long for Java tooling.

To top it all off, I don't think could've done a better job than the people responsible for this complexity.

> What did we learn from all this?

> I don't know.

> Well I don't know either.

> I guess to not do it again...fuck if I know what we did in the first place

I guess eventually all tools will converge to a de-facto mixed module/commonjs module resolution standard which roughly matches what tsx (the ts-node replacement, not the file extension) does.

ESM is actually quite simple. The problem is just that people don't know the basics and tools are encumbered by years of cruft and varying behavior. Check out how many "module" and "moduleResolution" behaviors TypeScript alone has.

The trick is to start fresh and to know the basics:

- use type=module

- import with extensions

- use a sensible shared tsconfig (this is the hard part)

- don't use junk tools like webpack and jest

What is s sensible tsconfig according to you?

I use @sindresorhus/tsconfig, but there are a handful of possible improvements over it (see open issues)

> - don't use junk tools like webpack

I used to have that opinion, but now, going through a months long project modernizing our codebase's build tooling, I'm not so sure. Vite isn't so amazing either if you stray away from the happy path (html entry points). I guess no build tool is amazing. At the end of the day, the only thing I can say is all build tools suck. Write less build code if you can get away with it.

Eventually I had to settle on rspack (the spiritual successor to webpack) because vite wouldn't do what I wanted it to do. You could say it was the wrong tool for the job, but it took me a while to figure that out, given how scary it is to not use the frontend build tool. I still wish we could've used it because then we'd be using an industry standard tool.

Getting back to criticizing Vite (sorry have to vent haha) in my experience, vite's API is also built on weird foundations. It exposes rollup and postcss options in it's config, which sometimes do similar things as it's own config options. It generates tons of small chunks with no obvious way to control it without giving up on nice things.

Also, should be noted that vitest does not require you to be using vite for bundling and is much much faster / easier to configure than jest these days. (It also has a jest-compatible API)

Reply on news.ycombinator.com