Read on Twitter
Alright let's talk about ESM.
There are actually *multitudes* of implementations of ESM, for both Node.js and browsers, all with varying ideas of what it actually means.
This means multitudes of ideas of what "loading code" actually means, when it happens, etc.
This means multitudes of ideas of what "loading code" actually means, when it happens, etc.
Sounds great, because you've got choices, right?
The problem is instrumentation. Just about every prod instrumentation tool (for security, perf, whatever) needs to intercept code loading in order to patch everything so that it gets the visibility that (currently) isn't built in.
The problem is instrumentation. Just about every prod instrumentation tool (for security, perf, whatever) needs to intercept code loading in order to patch everything so that it gets the visibility that (currently) isn't built in.
This means, in order for an instrumentation tool to support "ESM", they need to figure out what each and every one of these implementations is doing, and ensure that it's even *possible* to intercept code loading.
In an ideal world, this wouldn't be necessary, because we'd have things like `diagnostics_channel` everywhere to avoid any manual patching, but even that won't cover every case that might be needed.
The good news is today there's built-in support for ESM in Node.js. You should be using that rather than transpiling, bundling, or shimming ESM support with additional third-party tools. The more we can standardize on that, the easier it will be to instrument your Node.js apps.
Failing that, transpiling to classic Node.js `require`s will likely give you the most compatibility with instrumentation tools today.
