feat: full ESM config support using Jiti

[henrist]

I hereby confirm that I followed the code guidelines found at engineering guidelines <-- I don't have access to this

Affected Components

• CLI
• Create CLI
• Test
• Docs
• Examples
• Other

Notes for the Reviewer

Resolves #1015

The current use of ts-node is problematic:

• Only CommonJS is supported, so loading ESM doesn't work as expected
• ts-node is currently not maintained and haven't received updates for 1+ year. It lacks newer TypeScript features. For instance it does not support multiple extends in tsconfig.json that came with TypeScript 5.

This has been a large pain as most of the code I work with is in ESM. It has required non-trivial tsconfig files to workaround this.

This PR introduces Jiti as an alternative to ts-node. I could have picked tsx as well, but I don't find the API of tsx as intuitive/simple as Jiti. This is very similar as the implementation of eslint that uses Jiti for its TypeScript support.

Additional file extensions are also supported: .mts, .cts, .cjs

To avoid a breaking change it supports both ts-node and jiti. Existing users with only ts-node should not be affected, while new users will be recommended to add jiti. Jiti does not depend on a tsconfig.json file (and does not do type checking), so typescript is not requested as a dependency. Existing users can add jiti to get better (and ESM) support, and we also recommend this on compile issues. If you're open for a breaking change we could remove ts-node support and avoid dealing with both.

[sorccu]

Hi @henrist,

I really like the change, but I will need some time to consider any possible backwards compatibility implications caused it. I may not be able to properly review this until next week (it's the end of tax season over here which limits my extra time), but based on a quick scroll through I think it looks great overall. Backwards compatibility and potential breakage is my main concern and I'm grateful that you seem to have kept that in mind. For now, we are not ready to fully remove ts-node but that may be a possibility in a future major version.

Do note that while this PR may add full ESM support on the CLI side, our runtimes do not yet support ESM due to complexities of the current architecture, so unfortunately this PR does not fully enable ESM on the entire Checkly platform. However, we have a project in progress to allow ESM to work on our runners, so ESM everywhere may soon be a possibility too. For now though it's a limitation that you have to keep in mind.

Thanks a lot!

[henrist]

@sorccu Thanks for your quick feedback! Looking forward to your review. I have put some effort into avoiding this to become a breaking change. I've tested it an original template project, new template project and on a couple of our repos. But useful to have someone else double check.

Great to hear that you're working on ESM support on the runner side as well, although due to the limitation of dependencies and the fact that it parses module syntax just fine, this haven't been a real problem for us. I did use the term "config" in the PR title in an attempt to make it clear that this is for config of checks, not the check scripts/specs themself.

Would it be possible to trigger the canary/experimental release for this PR?

[sorccu]

I would be happy to trigger a build, but unfortunately that will also have to wait till next week as our workflows do not currently give access to secrets for PRs from forks, which means that both integration tests and the build would fail. I will massage the workflows a little next week to make that work.

[sorccu]

Unfortunately I was extra busy last week and did not have bandwidth to test your PR, but I will handle this within the next 2 days. Super excited about this feature.