This PR does the following:

• in tsconfig, bumps lib and target to esnext
• in tsconfig, bumps module and moduleResolution to nodenext
• adds type: module in package.json, as well as exports and engines fields for clarity
• adds .js file endings to all imports for ESM compliance
• makes significant changes to the Jest config in order to play nicely with ESM
• similarly adapts the test scripts (e.g. pnpm test) to use ESM (with --experimental-vm-modules flag)
• replaces ts-node-dev (which is incompatible with ESM) with tsx
• replaces any instances of require(...) with top-line import * as x from ... statements

The motivation here is to enable top-level await statements, which is required for the Microsoft SSO work (see #3453).

Will be best reviewed commit-by-commit. 17125bf is small, handling the initial tsconfig.json changes to force adoption of ESM throughout, while 89c2ee6 is huge but fairly straightforward.

5cae484 is perhaps the meatiest, and also required the changes in planx-core#465 to get tests running. Note that planx-core#464 was also prompted by this work, enabling the fixes to imports in b29fab9.

Resources

• https://jestjs.io/docs/ecmascript-modules
• https://kulshekhar.github.io/ts-jest/docs/guides/esm-support/
• https://dev.to/mangadev/set-up-a-backend-nodejs-typescript-jest-using-es-modules-1530
• TS imports with .js extension break Jest-resolve kulshekhar/ts-jest#1057 (comment)
• https://tsx.is/typescript
• https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

Still to investigate (possibly after this PR is merged)

• Check the codebase can now handle a top-level await, as I intend to use in api-add-microsoft-sso-strategy-2?
• If so, is there a good reason why I can't directly replace require(...) statements with await import(...) where they occur (what I did in 3f221a6, but had to further adapt in 6aa01c8)? And if not is ts-jest still just configured incorrectly/being buggy, are the files being interpreted as cjs still, or is it something else?
• Should I be able to import files as .ts, rather than .js? As I understand, this would only be possible if we weren't usins TS to 'emit' JS. One option to explore could be to use moduleResolution: "bundler" instead of "nodenext".

Note that although some changes may survive type checking, and even build, this doesn't necessarily imply that the tests will check out. The code needs to be solid from various angles:

• Type checking, as well as building the actual application, rely directly on tsc (which reads tsconfig)
• Tests (Jest) relies on ts-jest to transform files for execution (which reads tsconfig.test, an extension of tsconfig)
• The dev environment (pnpm dev) relies on tsx (which also reads the tsconfig)