silverwind

This is much needed. Ineffective `shellcheck disable` statements do mask bugs. There should be a separate rule that searches for ineffective `shellcheck disable` statements, e.g. not the same rule number...

Imho there are only two sensible ways to format these: - Put them all on the same line and offload the problem to editors wrapping the line - Add a...

> I like the idea, but may it can be done by spellcheck? Most spellcheckers would probably have both variants pass. Also, many of them are a pain to set...

> I was wondering if it would make sense to add support for (conditional) exports fields in package json files to the (default) node resolver instead of introducing another dependency?...

Why not change the default resolver in a breaking change? As far as I'm aware `eslint-import-resolver-typescript` works universally for everything, including node code and js.

> eslint-import-resolver-typescript preferrs .ts/.d.ts, etc over the default node But is it an issue for a JS-only user? I think not. Also node since v22 supports executing typescript via `--experimental-strip-types`...

Yes, it's still a limitation of `--experimental-strip-types` that it does not work for files inside a `node_modules` folder. I do hope that they lift this restriction soon.

Yes indeed, file extensions always were and are still required in Node's resolver. They are optional in typescript only.

The only way to deeply lock your dependency tree is bundling. Removing semver ranges on the direct dependencies does not prevent indirect dependencies from updating. > There is no way...

FWIW, here are some numbers: - eslint bundled with tsdown: 2.2MB - eslint unbundled: 13.1MB I estimate that around half of the 75 dependencies that eslint has are used exclusively...