@@ -9,22 +9,17 @@ import { resolveOrchestrionRuntimeRequest } from '@sentry/server-utils/orchestri
99export const BUNDLE_SAFE_INSTRUMENTED_PACKAGES = [ 'ioredis' ] ;
1010
1111/**
12- * The orchestrion runtime machinery must stay external — its parser breaks when bundled, which
13- * silently disables the runtime module hook.
12+ * `@sentry/server-utils` (where `register.ts` and the bundled orchestrion runtime ship) must stay
13+ * external: `register.ts` passes its own `__filename`/`import.meta.url` as the `parentURL` for
14+ * `Module.register('@sentry/server-utils/orchestrion/hook.mjs', …)`, so that self-reference only
15+ * resolves while the code still lives at its real `node_modules` location. Bundled into an app
16+ * server chunk instead, the specifier would have to resolve from the chunk's output location,
17+ * which fails under isolated installs (pnpm) where the package is a transitive dependency.
1418 *
15- * `@sentry/server-utils` (the package `register.ts` — the code that actually calls into
16- * `@apm-js-collab/tracing-hooks` — ships in) is included too: if it stays external, its own
17- * `__filename`/`import.meta.url` keep pointing at their real `node_modules` location, so its
18- * bare-specifier `require`/`import` of the (also-external) tracing-hooks packages resolve
19- * correctly. If `@sentry/server-utils` were bundled into an app server chunk instead, its code
20- * would be relocated away from `node_modules`, and those same specifiers would fail to resolve
21- * under isolated installs (pnpm).
19+ * (The `@apm-js-collab/*` packages no longer appear here: they are bundled into
20+ * `@sentry/server-utils`' build, so no import of them exists at runtime.)
2221 */
23- export const ORCHESTRION_RUNTIME_EXTERNAL_PACKAGES = [
24- '@apm-js-collab/tracing-hooks' ,
25- '@apm-js-collab/code-transformer' ,
26- '@sentry/server-utils' ,
27- ] ;
22+ export const ORCHESTRION_RUNTIME_EXTERNAL_PACKAGES = [ '@sentry/server-utils' ] ;
2823
2924/** Remove the given packages from a `serverExternalPackages` list. */
3025export function filterInstrumentedExternals ( externals : string [ ] , packagesToBundle : string [ ] ) : string [ ] {
@@ -41,12 +36,12 @@ export function filterInstrumentedExternals(externals: string[], packagesToBundl
4136 * package when its bare specifier also resolves from the project root (`resolveExternal`'s
4237 * base-resolve check in `next/dist/build/handle-externals.js`) — otherwise the
4338 * `require('<bare specifier>')` it emits into the chunk would dangle at runtime, so Next silently
44- * bundles the package instead. Under isolated installs (pnpm) these packages are transitive
45- * dependencies that never resolve from the project root, so the whole orchestrion runtime ended up
46- * compiled into the server chunk, which breaks it twice over: the code-transformer parser doesn't
47- * survive bundling, and the runtime hook's own bare specifiers can't resolve from the chunk's
48- * output location. Absolute paths sidestep all of this — webpack emits `require('/abs/path/…')`,
49- * which loads the real files from `node_modules` no matter where the chunk lives.
39+ * bundles the package instead. Under isolated installs (pnpm) the package is a transitive
40+ * dependency that never resolves from the project root, so the orchestrion runtime ended up
41+ * compiled into the server chunk — breaking the `Module.register` self-reference described on
42+ * { @link ORCHESTRION_RUNTIME_EXTERNAL_PACKAGES}. Absolute paths sidestep all of this — webpack
43+ * emits `require('/abs/path/…')`, which loads the real files from `node_modules` no matter where
44+ * the chunk lives.
5045 *
5146 * Must be placed *before* Next's own externals handler in the `externals` array: webpack calls
5247 * array entries in order and stops at the first one that returns a result.
0 commit comments