fix(bundler-plugins): integration with monorepo

[isaacs]

Note: the commit log in this PR is ridiculous, because it intentionally preserves the history of the sentry-javascript-bundler-plugins repo. Probably best to review locally. Attempting to do a rebase or squash merge will probably break GitHub and maybe the world 😅

Integrate the newly merged in @sentry/bundler-plugins project to the
sentry-javascript monorepo.

• Integration tests are updated to use the named submodule exports on
  the @sentry/bundler-plugins package, rather than the per-platform
  re-export shims.
• Lint and naming conventions brought in line with project standards.
• Bundler-plugins integration tests now run on CI.

The version has not been updated from its independent 5.x line, though
it may be a good idea to bump it up to align with the 10.x line that the
rest of the monorepo uses.

[timfish]

For the new package, this list needs to be considered:
https://github.com/getsentry/sentry-javascript/blob/develop/docs/new-sdk-release-checklist.md

I think the new package is missing README.md and LICENCE. We can fix here or complete this checklist in another PR?

[isaacs]

@timfish I copied over the LICENSE and README.md from the bundler-plugins-core package, since that's about the closest analogue to this refactor. Because it's semi-internal, I think some of the other "new SDK" steps don't really apply, but we can address them either before or after landing this, I don't really have a strong opinion about it.

[cursor]

pnpm override paths one level too deep

High Severity

Fixture pnpm.overrides use file:../../../… for packed plugin tarballs, but from fixtures/<bundler>/ three parent segments resolve to dev-packages/, not the integration-tests package root. setup.mjs runs pnpm install in those fixture dirs, so the paths miss the intended tarball locations and installs fail unless unrelated directories exist under dev-packages/.

Additional Locations (2)

• dev-packages/bundler-plugin-integration-tests/fixtures/rolldown/package.json#L12-L16
• dev-packages/bundler-plugin-integration-tests/fixtures/rollup3/package.json#L14-L18

 

^{Reviewed by Cursor Bugbot for commit 413068a. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2449737. Configure here.}

[cursor]

Wrong fixture tgz override paths

High Severity

Fixture pnpm.overrides still point at standalone-repo tarball paths under dev-packages (bundler-plugins, bundler-plugin-core, esbuild-plugin, etc.). After monorepo integration the packed plugin lives under packages/bundler-plugins, and separate core/esbuild-plugin directories are not present at those relative paths, so pnpm install in fixtures cannot resolve the intended local builds.

Additional Locations (2)

• dev-packages/bundler-plugin-integration-tests/fixtures/rolldown/package.json#L11-L16
• dev-packages/bundler-plugin-integration-tests/fixtures/rollup3/package.json#L13-L18

 

^{Reviewed by Cursor Bugbot for commit 2449737. Configure here.}

[isaacs]

This isn't quite right, but it does point out a pretty significant oversight. The bundler-plugin integration tests still use the older module names, which are not ported over in this merge.

Those need to be updated to use @sentry/bundler-plugins/<platform> instead of @sentry/<platform>-plugin, and built properly. I'll add another commit to this PR to do that.

[isaacs]

Hm, running the full bundler-plugins integration suite in CI is a bit more of a refactor. I think it's best for this PR to leave it in its current semi-broken state, get the code pulled in, and then fix it up to run properly and be integrated into CI. Attempting to do the full nx convention alignment right now would be pretty risky, I think, and while it's not in a great state, it's mostly harmless (doesn't break any other parts of the build, just isn't being tested fully).

@chargome @timfish What do you two think about this approach?

[sentry]

Bug: A type mismatch exists where bundlerMajorVersion is set on the normalized options at runtime but is missing from its NormalizedOptions type definition.
_{Severity: LOW}

Suggested Fix

Remove the assignment of bundlerMajorVersion from the normalizeUserOptions function in options-mapping.ts since this property is unused and is not part of the NormalizedOptions type. This will resolve the type inconsistency.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: packages/bundler-plugins/src/core/options-mapping.ts#L125

Potential issue: In `normalizeUserOptions`, the `bundlerMajorVersion` property is
assigned to `_metaOptions.telemetry`. However, the type definition for the normalized
options, `NormalizedOptions`, does not include `bundlerMajorVersion` under
`_metaOptions.telemetry`. While this creates a type mismatch where a property exists at
runtime but not in its type declaration, it has no functional impact. The property is
never read from the normalized options object. The value used for telemetry is passed as
a direct parameter to the `setTelemetryDataOnScope` function from the specific bundler
plugin, not from the options object.

Also affects:

• packages/bundler-plugins/src/core/types.ts:76~80