opentelemetry-js-contrib instrumentation-fastify fails to initialise if "type" is set to "module" in package.json

What version of OpenTelemetry are you using?

Latest versions available:

    "@opentelemetry/api": "^1.4.1",
    "@opentelemetry/auto-instrumentations-node": "^0.37.0",
    "@opentelemetry/exporter-metrics-otlp-proto": "^0.39.1",
    "@opentelemetry/exporter-prometheus": "^0.39.1",
    "@opentelemetry/exporter-trace-otlp-proto": "^0.39.1",
    "@opentelemetry/instrumentation": "^0.39.1",
    "@opentelemetry/instrumentation-fastify": "^0.31.3",
    "@opentelemetry/instrumentation-http": "^0.39.1",
    "@opentelemetry/resources": "^1.13.0",
    "@opentelemetry/sdk-metrics": "^1.13.0",
    "@opentelemetry/sdk-node": "^0.39.1",
    "@opentelemetry/sdk-trace-base": "^1.13.0",
    "@opentelemetry/sdk-trace-node": "^1.13.0",
    "@opentelemetry/semantic-conventions": "^1.13.0",

What version of Node are you using?

v18.16.0

What did you do?

Tried to use @opentelemetry/instrumentation-fastify on a new project did not understand why the instrumentation did not work.

What did you expect to see?

@opentelemetry/instrumentation-fastify Applying patch for [email protected]

What did you see instead?

nothing

Additional context

instrumentation-http works in both modes:

@opentelemetry/instrumentation-http Applying patch for [email protected]
@opentelemetry/instrumentation-http Applying patch for [email protected]

May 25 '23 18:05 mgcrea

support for instrumenting ESM was recently merged (see https://github.com/open-telemetry/opentelemetry-js/pull/3698) but it's not yet in a release.

Please retest once a new release is out.

May 26 '23 06:05 Flarna

New release is out. Can you please confirm if this is fixed?

Jun 14 '23 16:06 dyladan

Closing this as it should work as of the latest release. Feel free to comment if we should re-open the issue. :slightly_smiling_face:

Jun 27 '23 06:06 pichlermarc

This appears to still be a problem. We converted the Fastify example to ESM and see the HTTP modules being patched, but not fastify. https://github.com/nlindley/opentelemetry-js-contrib/compare/main...fastify-esm

Jul 07 '23 17:07 nlindley

Downgrading @opentelemetry/instrumentation to ^0.40.0 and deduping node modules helps, but we have to be particular in how we import Fastify. If we depend on ^0.41.0, then 0.40.0 will be installed inside @opentelemetry/instrumentation-fastify’s node modules along with a different version of import-in-the-middle, and the fastify instrumentation will fail.

Jul 07 '23 19:07 nlindley

A working version can be seen here: https://github.com/nlindley/opentelemetry-js-contrib/compare/main...fastify-esm-working

Jul 07 '23 19:07 nlindley

We have some more details and some minimal reproductions for the Fastify instrumentation.

When using the default import, the instrumentation crashes the app when a new instance is created by invoking fastify(). https://github.com/nlindley/otel-esm-examples/tree/master/fastify-default

When using the named import, the instrumentation does not crash, but the library is not wrapped and no spans are created. https://github.com/nlindley/otel-esm-examples/tree/master/fastify-named

Jul 14 '23 15:07 nlindley

FYI I opened a PR to fix this issue: https://github.com/open-telemetry/opentelemetry-js-contrib/pull/1624

This may be relevant for other instrumentations as well, you cannot depend on moduleExports being a function and always need to look at named exports/default export in order to make sure wrapping works in ESM as well.

Aug 07 '23 07:08 mydea

This seems to still be an issue when using the named fastify export through ESM.

Using the latest version of the Fastify instrumentation, I see that the default export is successfully patched, but the named export does not seem to patch beyond the constructor. It appears that the library is not fully wrapped and no spans are created through the Fastify instrumentation.

Given how Fastify provides its constructor through the default export (a function with an applied fastify constructor method, resolved within CommonJS), perhaps we need to look at wrapping both default and fastify within the ECMAScript Module Namespace representation?

Here is an updated minimal reproduction demonstrating the default export successfully patching: https://github.com/nlindley/otel-esm-examples/tree/master/fastify-default

and another reproduction demonstrating that the named export does not fully patch: https://github.com/nlindley/otel-esm-examples/tree/master/fastify-named