CJS - End of life

[mikearnaldi]

At some point we will need to take the steps to drop cjs support, at the moment the build pipeline is verbose and in fact it opens for potential errors, we don't really support a mixed env we only support using either one of the targets but if any app for whatever reason uses both it will lead to errors because state will be duplicated.

With fast transpilers such as esbuild and node natively supporting esm it becomes less and less relevant to support cjs, in fact I am already defaulting to esm modules in pretty much everything I do.

While I understand that the ecosystem is not ready some push towards a unifying future is needed.

This issue is to vote on an end of life date from which we will no longer provide cjs builds.

Following the options:

• 31/12/2022
• 30/06/2023
• 31/12/2023

While you may be tempted to just vote for the last option please take a moment to think about it and vote what you think it's best for the broader ecosystem.

To vote add a 'like' to one of the options below

[IMax153]

31/12/2022

[mikearnaldi]

30/06/2023

[mikearnaldi]

31/12/2023

[jasonkuhrt]

OTEL auto instrumentation doesn't support ESM yet, should that be waited for?

https://github.com/open-telemetry/opentelemetry-js/issues/1946

https://github.com/open-telemetry/opentelemetry-js/issues/1946#issuecomment-1295493673

Note that, manual instrumentation works fine.

[mikearnaldi]

OTEL auto instrumentation doesn't support ESM yet, should that be waited for?

open-telemetry/opentelemetry-js#1946

open-telemetry/opentelemetry-js#1946 (comment)

Note that, manual instrumentation works fine.

When chatting with @gcanti more recently we though it may be a good idea to also poll some companies that are currently using either fp-ts or effect and get the feel, we don't really want to do a launch without a parachute so by all means this issue isn't settled just yet.

Specifically in regards of open-telemetry I doubt anyone would want to use auto instrumentation when using effect primarily because spans are tracked by effect itself so to get the parent-child relation right you need to instrument the wrappers around foreign calls (also otel-like tracing is becoming native in effect so that libraries can provide tracing facilities without depending on opentelemetry directly)

[dyladan]

Seems like you have a pretty reasonable understanding already but as the OTel JS maintainer I'm happy to answer questions regarding that. The comment linked by Jason sums it up well, particularly the point that the maintainers would welcome support but it is tricky and there are other priorities and limited resources. I would point out that there is a fairly up-to-date PR using import-in-the-middle https://github.com/open-telemetry/opentelemetry-js/pull/2846. There are limitations (currently only one loader hook per process is possible) but it is better than nothing as they say.

I am also very interested in the idea of using diagnostic channels to fill this gap, but it will be a long time before we can rely on that as a widely adopted and used feature.