feat(bundlers): Add orchestrion bundler plugins #22124
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,42 @@ | ||
| import codeTransformer from '@apm-js-collab/code-transformer-bundler-plugins/esbuild'; | ||
| import { instrumentedModuleNames, withoutInstrumentedExternals } from '../config'; | ||
| import type { PluginOptions } from './options'; | ||
| import { orchestrionTransformOptions } from './options'; | ||
|
|
||
| /** | ||
| * esbuild plugin that runs the orchestrion code transform on the bundled output. | ||
| * | ||
| * Use when bundling a Node app with esbuild. For unbundled Node processes use the | ||
| * runtime hook instead (`node --import @sentry/node/orchestrion app.js`). | ||
| * | ||
| * esbuild does not flatten nested `plugins` arrays, so this returns a single | ||
| * plugin that strips instrumented packages from an `external` denylist before | ||
| * delegating to the upstream transform. | ||
| * | ||
| * @example | ||
| * ```ts | ||
| * // build.mjs | ||
| * import { sentryOrchestrionPlugin } from '@sentry/server-utils/orchestrion/esbuild'; | ||
| * await esbuild.build({ plugins: [sentryOrchestrionPlugin()] }); | ||
| * ``` | ||
| */ | ||
| export function sentryOrchestrionPlugin(options: PluginOptions = {}): ReturnType<typeof codeTransformer> { | ||
| const transformer = codeTransformer(orchestrionTransformOptions(options)); | ||
|
|
||
| return { | ||
| name: 'sentry-orchestrion', | ||
| async setup(build): Promise<void> { | ||
| // Strip instrumented packages from an `external` denylist so esbuild | ||
| // bundles them and the transform's `onLoad` actually sees their source; | ||
| // an externalized dependency is resolved from `node_modules` at runtime | ||
| // and never gets the diagnostics_channel calls injected. Mutating | ||
| // `initialOptions` inside `setup` is respected by esbuild — the upstream | ||
| // plugin sets `initialOptions.metafile` the same way. | ||
| build.initialOptions.external = withoutInstrumentedExternals( | ||
| build.initialOptions.external, | ||
| instrumentedModuleNames(options.instrumentations), | ||
| ); | ||
| await transformer.setup(build); | ||
| }, | ||
| }; | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| import type { InstrumentationConfig } from '@apm-js-collab/code-transformer'; | ||
| import { SENTRY_INSTRUMENTATIONS } from '../config'; | ||
| import type codeTransformer from '@apm-js-collab/code-transformer-bundler-plugins/rollup'; | ||
|
|
||
| export type PluginOptions = { | ||
| /** | ||
| * Additional instrumentations to include with the default instrumentation. | ||
| */ | ||
| instrumentations?: InstrumentationConfig[]; | ||
| }; | ||
|
|
||
| /** | ||
| * The `@apm-js-collab/code-transformer-bundler-plugins` options shared by every | ||
| * orchestrion bundler plugin. | ||
| * | ||
| * `injectDiagnostics` sets `globalThis.__SENTRY_ORCHESTRION__.bundler = true` at | ||
| * app boot so the `_experimentalSetupOrchestrion()` detector can confirm the | ||
| * bundler path ran (rather than relying on a build-time flag that wouldn't be | ||
| * visible to the runtime). | ||
| */ | ||
| export function orchestrionTransformOptions(options: PluginOptions): Parameters<typeof codeTransformer>[0] { | ||
| return { | ||
| instrumentations: [...SENTRY_INSTRUMENTATIONS, ...(options.instrumentations || [])], | ||
| injectDiagnostics: () => { | ||
| return '(globalThis.__SENTRY_ORCHESTRION__=globalThis.__SENTRY_ORCHESTRION__||{}).bundler=true;'; | ||
|
Member
There was a problem hiding this comment. If this is now done unconditionally, couldn't that sometimes run into problems with the check in // Already injected (runtime --import hook or bundler plugin) — nothing to do.
if (g.runtime || g.bundler) {
return;
}If we're using a bundler like vite, where we an very reliably de-externalize anything orchestrion wants to instrument, but a case like rollup or esbuild with The approach I ended up taking in the Bun plugin, after some back and forth trying to find a way around it (and failing) was to just detect these blanket-external cases and warn about it at bundle time.
Member
There was a problem hiding this comment. This makes me wonder if we need a more comprehensive tracking of what actually gets instrumented by the bundler along the way, which can be injected into some kind of global registry, and then the runtime instrumentation can filter those out. Would be more complicated, but might close the gap without having to predict the future based on bundler type and precise configs 🤔
Collaborator
Author
There was a problem hiding this comment. Because something has been injected at bundler time, why should this disable runtime injection? There is no risk of "double-wrapping" so I don't understand why we impose this limitation?
Member
There was a problem hiding this comment. (summarizing discussion from slack) Yes, you're right, double-wrapping is not a concern, unless we bundle directly over the source file in the same location in node_modules, which would be... confusing. I think for the time being, if you agree, this seems most prudent:
|
||
| }, | ||
| }; | ||
| } | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| import codeTransformer from '@apm-js-collab/code-transformer-bundler-plugins/rollup'; | ||
| import { instrumentedModuleNames, withoutInstrumentedExternals } from '../config'; | ||
| import type { PluginOptions } from './options'; | ||
| import { orchestrionTransformOptions } from './options'; | ||
|
|
||
| /** | ||
| * Rollup plugin that runs the orchestrion code transform on the bundled output. | ||
| * | ||
| * Use when bundling a Node app with Rollup. For unbundled Node processes use the | ||
| * runtime hook instead (`node --import @sentry/node/orchestrion app.js`). | ||
| * | ||
| * @example | ||
| * ```ts | ||
| * // rollup.config.js | ||
| * import { sentryOrchestrionPlugin } from '@sentry/server-utils/orchestrion/rollup'; | ||
| * export default { plugins: [sentryOrchestrionPlugin()] }; | ||
| * ``` | ||
| */ | ||
| export function sentryOrchestrionPlugin(options: PluginOptions = {}): ReturnType<typeof codeTransformer> { | ||
| return { | ||
| ...codeTransformer(orchestrionTransformOptions(options)), | ||
| // The `options` hook runs before the build starts and can rewrite the | ||
| // resolved input options. Rollup's `external` may be a string, RegExp, | ||
| // function, or array of `string | RegExp`; `withoutInstrumentedExternals` | ||
| // only understands a string denylist, so we touch only that form and leave | ||
| // every other shape untouched. | ||
| options(inputOptions) { | ||
| const { external } = inputOptions; | ||
| if (Array.isArray(external) && external.every(entry => typeof entry === 'string')) { | ||
| const moduleNames = instrumentedModuleNames(options.instrumentations); | ||
| return { ...inputOptions, external: withoutInstrumentedExternals(external, moduleNames) }; | ||
| } | ||
| return null; | ||
| }, | ||
| }; | ||
| } | ||
|
timfish marked this conversation as resolved.
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Demoting this to a devDep would break the published types, because we re-export the
InstrumentationConfigfrom it. (Would still work in Yarn and npm via the transitive dep, but not pnpm.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahhhh. Part of me feel like these should be re-exported from both of the other packages!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would indeed be handy!