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

[mgcrea]

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]

[Flarna]

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

Please retest once a new release is out.

[dyladan]

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

[pichlermarc]

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

[nlindley]

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

[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.

[nlindley]

A working version can be seen here: nlindley/opentelemetry-js-contrib@main...fastify-esm-working

[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

[mydea]

FYI I opened a PR to fix this issue: #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.

[jacobwood091]

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

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[nlindley]

This is still an issue.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stale for 14 days with no activity.