fix(web): make OTEL instrumentation override effective + align Node engine - #617
fix(web): make OTEL instrumentation override effective + align Node engine#617groupthinking wants to merge 4 commits into
Conversation
…CSS)
The `build` CI job has been failing on `main` (and therefore on every open
PR), blocking the entire merge queue. Two independent, pre-existing breakages:
1. `next build` crashed at config load with
"Cannot find module '@opentelemetry/instrumentation'".
@sentry/nextjs v10 (@sentry/node-core) declares the @opentelemetry/*
packages as PEER deps. CI installs with `--legacy-peer-deps`, which skips
peers, and @opentelemetry/instrumentation had two conflicting versions in
the tree (0.214.0 / 0.219.0) so npm never hoisted it to top-level
node_modules — making it unresolvable from @sentry/node-core.
Fix: declare the Sentry v10 OTEL peers as direct deps of apps/web and add
an override to dedupe @opentelemetry/instrumentation to 0.219.0.
2. tailwindcss had been bumped to v4 (^4.3.1) without migrating the config,
so the build failed with "trying to use `tailwindcss` directly as a
PostCSS plugin". Completed the official v4 migration:
- add @tailwindcss/postcss and use it in postcss.config.js
- globals.css: `@tailwind` directives -> `@import "tailwindcss"` plus
`@config "../../tailwind.config.js"` to preserve the existing JS theme
(brand colors, animations) and avoid losing custom utilities.
Verified locally: `npm install --legacy-peer-deps && npm run build:web`
now completes successfully (full route tree generated).
Note: v4 ships different default base/preflight styles than v3; a visual
pass on the deployed preview is recommended before merge.
…ngine Address review feedback on the build-unblock change: - npm only honors `overrides` in the ROOT package.json, so the `@opentelemetry/instrumentation` override placed in apps/web/package.json was a no-op (the dedupe was actually achieved by the direct dependency hoisting 0.219.0 to top-level, while @sentry/node kept a nested 0.214.0). Move the override to the root package.json so it applies workspace-wide. The lockfile now resolves a single @opentelemetry/instrumentation@0.219.0. - The added OpenTelemetry packages require Node `^18.19.0 || >=20.6.0`; bump root `engines.node` from `>=20.0.0` to `>=20.6.0` to match the strictest dependency requirement and avoid engine warnings on Node 20.0–20.5. Re-verified: `npm run build:web` still succeeds.
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Repository UI (inherited), Organization UI (inherited) Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| "@opentelemetry/api": "^1.9.1", | ||
| "@opentelemetry/core": "^2.8.0", | ||
| "@opentelemetry/exporter-trace-otlp-http": "^0.219.0", | ||
| "@opentelemetry/instrumentation": "^0.219.0", | ||
| "@opentelemetry/sdk-trace-base": "^2.8.0", | ||
| "@opentelemetry/semantic-conventions": "^1.41.1", |
There was a problem hiding this comment.
🔍 OpenTelemetry packages added as dependencies but no source code uses them
Six @opentelemetry/* packages are added to apps/web/package.json:15-20 as production dependencies, but a search of apps/web/src/ finds zero imports of any @opentelemetry module. The existing apps/web/instrumentation.ts only wires up Sentry. If this is preparation for future instrumentation work, these should ideally be added alongside the code that uses them to avoid unnecessary bundle weight. If they're intended to be used by Sentry internally, note that Sentry already declares its own @opentelemetry/api dependency — the additional packages (core, sdk-trace-base, exporter-trace-otlp-http, instrumentation, semantic-conventions) would only be needed for custom tracing setup.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "@dataconnect/generated": "file:src/dataconnect-generated", | ||
| "@google/genai": "^2.8.0", | ||
| "@google/generative-ai": "^0.24.1", | ||
| "@opentelemetry/api": "^1.9.1", |
There was a problem hiding this comment.
🔍 OpenTelemetry API version range could break peer dependencies on future installs
The @opentelemetry/api is specified as ^1.9.1 (apps/web/package.json:15), which allows resolution to 1.10.0 or higher. However, @opentelemetry/core 2.8.0 declares a peer dependency of >=1.0.0 <1.10.0, and @opentelemetry/sdk-trace-base 2.8.0 requires >=1.3.0 <1.10.0. Currently the lockfile pins API at 1.9.1, so this works. But if the lockfile is regenerated after @opentelemetry/api 1.10.0 is published, npm could resolve to a version that violates these peer constraints, causing warnings or failures. Pinning to >=1.9.1 <1.10.0 would be safer.
Was this helpful? React with 👍 or 👎 to provide feedback.
| '@tailwindcss/postcss': {}, | ||
| autoprefixer: {}, |
There was a problem hiding this comment.
📝 Info: Autoprefixer plugin is redundant with Tailwind CSS v4
The PostCSS config at apps/web/postcss.config.js:5 still includes autoprefixer as a plugin. Tailwind CSS v4's @tailwindcss/postcss plugin includes built-in autoprefixing, making the separate autoprefixer plugin unnecessary. This won't cause breakage (running autoprefixer twice is harmless), but it adds unnecessary processing time to builds and could be removed along with the autoprefixer devDependency in apps/web/package.json:46.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Pull request overview
This PR fixes the frontend web app's dependency/build configuration. Its stated goals are to make the root @opentelemetry/instrumentation override actually take effect and to align the Node engine requirement with the OpenTelemetry 2.x/0.219.x stack. It also completes a Tailwind CSS v4 PostCSS migration that had been left in a mixed (v3-style) state.
I verified the substantive changes:
- The
@config "../../tailwind.config.js"directive inglobals.csscorrectly resolves to the existingapps/web/tailwind.config.js. - The engine bump to
>=20.6.0matches the OTEL packages'^18.19.0 || >=20.6.0requirement, and CI runs on Node 22. - The
@ai-sdk/anthropiclock changes (^3.0.85→3.0.85) simply re-sync the lock with workspace manifests that already pin3.0.85. - The resolved OTEL versions (
@opentelemetry/api@1.9.1,semantic-conventions@1.41.1, etc.) exist and are consistent; the OTEL packages are consumed transitively via@sentry/nextjs. - No leftover legacy
@tailwinddirectives ortailwindcss: {}PostCSS plugin usages remain.
Changes:
- Bump root Node engine to
>=20.6.0and add an@opentelemetry/instrumentation@^0.219.0root override, hoisting a single OTEL 0.219.0 stack (removing Sentry's nested 0.214.0 copies). - Migrate
apps/webto the Tailwind v4 PostCSS pipeline (@tailwindcss/postcssplugin,@import "tailwindcss"+@config). - Regenerate
package-lock.jsonto reflect the new OTEL/Tailwind dependency tree.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| package.json | Bumps Node engine to >=20.6.0 and adds the @opentelemetry/instrumentation override. |
| apps/web/package.json | Adds the OTEL dependency set (version pinning) and the @tailwindcss/postcss dev dependency. |
| apps/web/postcss.config.js | Switches the PostCSS plugin from tailwindcss to @tailwindcss/postcss for Tailwind v4. |
| apps/web/src/app/globals.css | Replaces @tailwind directives with @import "tailwindcss" + @config. |
| package-lock.json | Regenerated lockfile hoisting OTEL 0.219.0 and the Tailwind v4 toolchain. |
No blocking code defects were found in the diff; the changes are internally consistent. However, this is a broad, monorepo-wide lockfile change that also forces Sentry's OpenTelemetry instrumentation to a non-default version and alters the frontend CSS build pipeline — and per the repository's CI setup the apps/web build/tests are not exercised by CI, so these changes cannot be fully validated automatically.
|
@copilot resolve the merge conflicts on this branch. |
Head branch was pushed to by a user without write access
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Resolved by merging |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
There was a problem hiding this comment.
Additional Suggestion:
apps/web declared @opentelemetry/exporter-trace-otlp-http@^0.219.0, dragging in a core@2.8.0/sdk-trace-base@2.8.0 chain that conflicts with the rest of the workspace (and Sentry) on 2.9.0/0.220.0, causing TypeError: Class extends value undefined during Next.js prerender.
Dependency ReviewThe following issues were found:
|
🔍 PR Validation |
…219.0`, dragging in a `core@2.8.0`/`sdk-trace-base@2.8.0` chain that conflicts with the rest of the workspace (and Sentry) on `2.9.0`/`0.220.0`, causing `TypeError: Class extends value undefined` during Next.js prerender. This commit fixes the issue reported at apps/web/package.json:15 ## Bug After merge commit `cd84091`, most of the OpenTelemetry dependencies in `apps/web/package.json` were bumped to the new line (`@opentelemetry/core@^2.9.0`, `@opentelemetry/sdk-trace-base@^2.9.0`, `@opentelemetry/instrumentation@^0.220.0`, `@opentelemetry/resources@^2.9.0`), but **`@opentelemetry/exporter-trace-otlp-http` was left at `^0.219.0`**. The `0.219.0` exporter pins the whole OTLP chain to the old line. The committed `package-lock.json` confirmed the resulting skew: ``` node_modules/@opentelemetry/exporter-trace-otlp-http => 0.219.0 node_modules/@opentelemetry/exporter-trace-otlp-http/.../core => 2.8.0 node_modules/@opentelemetry/otlp-exporter-base => 0.219.0 node_modules/@opentelemetry/otlp-transformer => 0.219.0 node_modules/@opentelemetry/sdk-trace-base => 2.8.0 (hoisted to top level) node_modules/@opentelemetry/core => 2.9.0 (top level) node_modules/@sentry/node/.../sdk-trace-base => 2.9.0 node_modules/@sentry/node/.../instrumentation => 0.220.0 ``` So at the top level `@opentelemetry/core@2.9.0` coexists with a hoisted `@opentelemetry/sdk-trace-base@2.8.0`, while Sentry (`@sentry/node@10.66.0`) pulls the `2.9.0`/`0.220.0` line. When a base class that was moved/renamed between `2.8.x` and `2.9.x` is imported across the mismatched packages, the import resolves to `undefined`, producing `TypeError: Class extends value undefined is not a constructor or null` in the shared server chunk during static prerender of `/app` and `/_global-error`. The `npm install --legacy-peer-deps` in the build log (“added 62, removed 44, changed 60 packages”) further indicated the lockfile was out of sync and legacy-peer-deps masked the incompatible peers. ## Fix - Bumped `@opentelemetry/exporter-trace-otlp-http` from `^0.219.0` to `^0.220.0` in `apps/web/package.json`, aligning it with the rest of the workspace. - Regenerated `package-lock.json` (`npm install --package-lock-only`). After regeneration the entire OTLP chain resolves consistently: ``` @opentelemetry/exporter-trace-otlp-http => 0.220.0 @opentelemetry/otlp-exporter-base => 0.220.0 @opentelemetry/otlp-transformer => 0.220.0 @opentelemetry/sdk-trace-base => 2.9.0 @opentelemetry/core => 2.9.0 ``` A scan of the regenerated lockfile confirms **no `2.8.x` or `0.219.x` OpenTelemetry packages remain**, eliminating the cross-version class inheritance that crashed the prerender. Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com> Co-authored-by: groupthinking <garveyht@gmail.com>
There was a problem hiding this comment.
Additional Suggestion:
Next.js build fails with Module not found: Can't resolve '@opentelemetry/sdk-trace-base' because the root-hoisted @sentry/opentelemetry cannot resolve its peer dependency @opentelemetry/sdk-trace-base, which is nested only under apps/web/node_modules/.
|
Closing because the stated objective is already represented on current The current lock resolves one No branch deletion was performed. |
Pull request was closed
🔍 PR Validation |
Agent Completion Truth Gate: BLOCKEDReasons: Machine-readable verdict{
"details": {
"invalid_fields": [
"issue.number",
"policy.agent_login",
"policy.run_id"
]
},
"reasons": [
"invalid_payload"
],
"verdict": "blocked"
} |
Uh oh!
There was an error while loading. Please reload this page.