Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested node_modules causes incorrect bundling #74331

Open
Netail opened this issue Dec 27, 2024 · 0 comments
Open

Nested node_modules causes incorrect bundling #74331

Netail opened this issue Dec 27, 2024 · 0 comments
Labels
bug Issue was opened via the bug report template. Turbopack Related to Turbopack with Next.js. Upstream Related to using Next.js with a third-party dependency. (e.g., React, UI/icon libraries, etc.). Webpack Related to Webpack with Next.js.

Comments

@Netail
Copy link
Contributor

Netail commented Dec 27, 2024

Link to the code that reproduces this issue

https://github.com/Netail/repro-nested-modules

To Reproduce

  1. Install packages using yarn install
  2. Run the web app yarn dev
  3. Observe [TypeError: this.getDefaultUrl is not a function] being thrown

Current vs. Expected behavior

The error itself seems to come from the file OTLPExporterBase.js in the @opentelemetry/otlp-exporter-base package.

In the packages/client-observability package we use @grafana/faro-web-tracing, which under water uses @opentelemetry/otlp-exporter-base version v0.53.0

In the packages/server-observability package we use @opentelemetry/otlp-grpc-exporter-base, which under water uses @opentelemetry/otlp-exporter-base version v0.57.0

Since v0.54.0 the getDefaultUrl has been removed / replaced. Each have their own version installed somewhere in the node_modules, so each should target their own version.

v0.53.0 is located directly node_modules folder (node_modules/@opentelemetry/otlp-exporter-base) and v0.57.0 is located in a nested node_modules folder (node_modules/@opentelemetry/otlp-grpc-exporter-base/node_modules/@opentelemetry/otlp-exporter-base). For some reason, bundling seems to be taking v0.57.0 in both cases. Throwing the error for the packages which should use v0.53.0.

If I revert the 0.57.0 versions in the server-observability package, the dev server starts without errors

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.11.0
  npm: 10.9.0
  Yarn: 1.22.22
  pnpm: 9.6.0
Relevant Packages:
  next: 15.1.3 // Latest available version is detected (15.1.3).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.5.4
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack, Upstream, Webpack

Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local)

Additional context

This happens for both Webpack & Turbopack, could possible be upstream?

@Netail Netail added the bug Issue was opened via the bug report template. label Dec 27, 2024
@github-actions github-actions bot added Turbopack Related to Turbopack with Next.js. Upstream Related to using Next.js with a third-party dependency. (e.g., React, UI/icon libraries, etc.). Webpack Related to Webpack with Next.js. labels Dec 27, 2024
@Netail Netail changed the title Nested node_modules Nested node_modules causes incorrect bundling Dec 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue was opened via the bug report template. Turbopack Related to Turbopack with Next.js. Upstream Related to using Next.js with a third-party dependency. (e.g., React, UI/icon libraries, etc.). Webpack Related to Webpack with Next.js.
Projects
None yet
Development

No branches or pull requests

1 participant