Port to ESM

[nickrttn]

After the earlier changes made today and yesterday, this was a relatively small effort.

This PR also enables strict and noUncheckedIndexedAccess in the root tsconfig

[kvz]

would we still be able to consume this in the api2 repo then?

[nickrttn]

If you are able to consume ESM dependencies in the api2 repo (via ts-fly maybe), then yes, absolutely! If you rely on CJS dependencies, then no, there is no CJS build.

[kvz]

If you are able to consume ESM dependencies in the api2 repo (via ts-fly maybe), then yes, absolutely! If you rely on CJS dependencies, then no, there is no CJS build.

Only via await import() with ts-fly, so not exactly a dx improvement then 🤔

[nickrttn]

Only via await import() with ts-fly, so not exactly a dx improvement then 🤔

I think that's a shortcoming of the api2 repo rather than an issue of this one, no?

[nickrttn]

Whoops, wrong button

[kvz]

I think that's a shortcoming of the api2 repo rather than an issue of this one, no?

yes, but it's a pita to enforce ESM on the backend. the ecosystem isn't there yet. currently only Sindre does it and we're pinning all his modules to old versions because of it 🤷

How about? https://github.com/isaacs/tshy

[nickrttn]

Well, since tsc doesn't do any bundling, we'd probably still end up having to pin any dependencies of this repo to their latest CJS version instead of being able to use the latest, so I'm not sure a tool like that is really useful without a bundler if you have 3rd party dependencies.

[kvz]

Sorry man, as it stands the backend ecosystem isn't as far progressed with ESM adoption as the frontend and hence moving to it now without CJS exports would limit the utility of this repo's contents.

I also see this PR brings improvements that are not ESM-port related, those are non-controversial and can be merged imho.

Note that Node.js is doing work to relax around ESM, after which i expect this all to go down much smoother.

But forcing ESM upon backend repos before that is just causing extra work and headaches, that will all be solved for us if we can just not do it for another dozen of months or so.

[nickrttn]

Can you elaborate on 'the ecosystem is not ready'? As far as I understand it, it is perfectly possible to import CJS modules from ESM code since Node.js 12 (14?), and so, the ecosystem shouldn't matter as much, barring packages with badly defined entry points.

So what causes the relaxed/improved parsing of module types (eg. not dependent on file extension) to improve that situation for us? As the consumer of modules, we will need to do a migration to either .mjs files, or type: module with import/export in either case. To me, it seems more like an issue of effort rather than ecosystem readiness. The extra work and headaches caused by migrating to an ESM codebase seems unavoidable.

[kvz]

The ecosystem extends beyond just Node.js; it encompasses various other factors such as the readiness of certain tools like Sucrase, along with our usage of outdated versions of Mocha, Jest, dynamically requiring files, etc. The transitioning phase will require some time and is not as simple as setting type: "module" sadly. As for Node.js itself, it's on the brink of significant ESM modifications, slated to take place in the near future. I expect these to reverberate throughout the backend ecosystem, enhancing compatibility with many libraries that currently fall short.

Jumping the gun (imho) by porting the api repo to ESM today, would entail a considerable amount of extra work with minimal customer value to show for it. This work might become superfluous if we choose to wait for a few more months.

For instance, it's not unlikely that post our upgrade to Node 22, we'll be in a position to import ESM modules even if the api2 repo remains unported because of the aforementioned issues. In short I feel this approach may provide a more pragmatic path forward, ensuring we navigate through this transitional phase with efficacy and efficiency.

[nickrttn]

Superseded by #49