When a downstream bundler bundles @sentry/node (Next.js server build, serverless bundling, nitro/vite) and honours sideEffects: false, part of the orchestrion runtime transformer chain is deleted and part is kept. The kept parts seem to have no connection to whether the SDK needs it or not as the remaining code wouldn't execute safely.
It seems to be decided by whether each vendored CommonJS dependency writes exports.foo = ... or module.exports = ..., and this behavior was indicated by some experiments I was doing in rolldown which prompted me to check rollup behavior there as well. So seems like the UMD footer in esquery changes the tree-shaking decision taken in either bundlers, with rolldown being worse than rollup.
The result on develop today is that the parser parts (meriyah, source-map, and astring) are deleted while the selector matcher (esquery) is kept, even though the transformer calls both in the same function, so that could would actually throw if executed but it doesn't get executed.
In develop's bundled output, _virtual/meriyah.js looks like this
then you can see this in the output bundles:
code-transformer/lib/transformer.js uses both in the same code path:
const { parse } = meriyah; // meriyah is {} -> parse is undefined
// ...
esquery.traverse(ast, esquery.parse(query), ...) // esquery is present
I took a look at the chain and it is reachable from init():
@sentry/node/index.js
-> sdk/index.js
-> @sentry/server-utils/orchestrion/register (registerDiagnosticsChannelInjection)
-> @apm-js-collab/tracing-hooks
-> @apm-js-collab/code-transformer
-> meriyah, esquery, astring, source-map
is this intended?
I initially thought this might be intended as it could be needed for runtime import hooks but then the half shaken code wouldn't work from what I could tell.
AFAIK orchestrion works in two modes, bundled or runtime, so current state feels weird for both:
- deps the bundler inlined -> transformed at build time -> the runtime transformer is dead weight for those
- deps left external -> only the runtime hook can reach them -> the transformer must be present in the app but it is half shaken out
I created this repo to test this, it could be I'm missing something fundamental but as far as I can tell we have no tests covering bundled instrumentation emitting the telemetry expected.
https://github.com/logaretm/orchestrion-treeshake-repro
When a downstream bundler bundles
@sentry/node(Next.js server build, serverless bundling, nitro/vite) and honourssideEffects: false, part of the orchestrion runtime transformer chain is deleted and part is kept. The kept parts seem to have no connection to whether the SDK needs it or not as the remaining code wouldn't execute safely.It seems to be decided by whether each vendored CommonJS dependency writes
exports.foo = ...ormodule.exports = ..., and this behavior was indicated by some experiments I was doing in rolldown which prompted me to check rollup behavior there as well. So seems like the UMD footer in esquery changes the tree-shaking decision taken in either bundlers, with rolldown being worse than rollup.The result on
developtoday is that the parser parts (meriyah, source-map, and astring) are deleted while the selector matcher (esquery) is kept, even though the transformer calls both in the same function, so that could would actually throw if executed but it doesn't get executed.In
develop's bundled output,_virtual/meriyah.jslooks like thisthen you can see this in the output bundles:
code-transformer/lib/transformer.jsuses both in the same code path:I took a look at the chain and it is reachable from
init():is this intended?
I initially thought this might be intended as it could be needed for runtime import hooks but then the half shaken code wouldn't work from what I could tell.
AFAIK orchestrion works in two modes, bundled or runtime, so current state feels weird for both:
I created this repo to test this, it could be I'm missing something fundamental but as far as I can tell we have no tests covering bundled instrumentation emitting the telemetry expected.
https://github.com/logaretm/orchestrion-treeshake-repro