Maintenance, Use empathic

[beeequeue]

This PR started as just replacing fd-package-json but quickly spiraled as I found issues running tests etc.

• Replaces fd-package-json with empathic
• Could not run tests on node 24 because of TS file resolution changing with type-stripping
  • Dropped node 18 from test runner, added 22, 24
• Could not build because of outdated TypeScript version and config
  • Updated TS config to allow and rewrite .ts extensions
• Lint broke because of TS-ESLint plugin not supporting TS version
  • Updated ESLint and its plugins

---

We should also make sure to update semver later to the latest version as it has released a bunch of perf improvements!

[43081j]

we shouldn't need to rewrite all the imports to .ts

we'd only need to do that if we wanted to run something with node's type stripping enabled, and we don't

you're running into that because node is mistakenly trying to run the tests natively and shouldn't. the repo is setup such that the .js tests should be run, not the .ts files directly

FYI this is a bit of a mess node caused. i dont remember the versions, but in node 20 (?) the test runner doesn't support passing a glob, but latest node does. so we can't globally pass a glob to tell it to stop matching .ts because 20 won't support that. similarly, we can't disable type stripping in latest to solve the problem, because 20 isn't aware of that option and will throw

[beeequeue]

I'm not sure I follow here, I can't find any js files in the repo?

[43081j]

from the build

eslint-plugin-depend/package.json

Line 18 in ab547a2

"test": "npm run build:js && npm run clean:test && c8 node --test",

the tests run the build first and run the .js files

node is misbehaving here, the intention was never to run the .ts files

[beeequeue]

Ah I see, is there a reason to not use native node TS support and extensions, other than running tests against the built files?

[43081j]

we were testing against node versions that didn't have type stripping, and it can be nice to test against the code we're actually going to ship

the two possible solutions here are:

• move to vitest
• rework all imports to be .ts solely for tests to work

the latter is what you have here. but it sucks to have to do that, because we're not building for a runtime that can run .ts - our files should use .js imports as thats what the published module will do. rewriting all of them to satisfy the node test runner seems a shame

i'd rather just move to vitest and accept the node test runner has been botched until we're at a point where 20.x is no longer LTS

[beeequeue]

@43081j I have refactored the tests to use vitest now