Repository navigation
@sentry/node 11 hard-depends on @sentry/bundler-plugins, shipping bundler tooling into server runtimes #24849
Description
Activity
The
sentrypackage is under FSL-1.1-Apache-2.0 license, so while @sentry/node is MIT it can't satisfy it's dependencies in an environment that requires OSI licenses.I won't tell you how to license your code but this doesn't feel like it follows the stated policy:
The official Sentry SDK for monitoring Node.js applications.
Here are the 3 licenses we use:
Apache License, Version 2.0 (Apache-2.0)
Sentry’s default license of choice is the permissive but protective Apache-2.0 license. This license is OSI-approved, widely adopted, and still has some safe-guards like attribution requirement or patents protection. Any new projects are licensed under Apache-2.0 unless there’s a concern around GPL-2.0 compatibility for adoption.
The MIT License (MIT)
We use the MIT license as a fallback for the Apache-2.0 license where we need to reach to a wider audience, due to the GPL-2.0 incompatibility. This is the license we use for all our SDKs.
Functional Source License, Version 1.1, Apache 2.0 Change License (FSL-1.1-Apache-2.0)
All components powering the main Sentry and Codecov web apps use FSL, which limits their usage in a commercial Sentry-like offering.Given that these bundler plugins are extra imports, bring additional dependencies, bring additional licenses, and look effectively like re-exports, why isn't it left as a stand-alone dependency?
https://github.com/getsentry/sentry-javascript/tree/develop/packages/node/src/bundler-pluginHey, thanks for raising. We are discussing these internally and will get back to you.
- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Oct 1, 2026 Short update regarding the license. We had to update our license to also mention the FSL license in there, as the bundler plugins were moved into this repo. The website will be updated as well soon
We're still discussing the original issue on how to move forward with this
I just upgraded my Electron app and this broke my dual-arch Mac builds because of the wrongful inclusion of
oxc-parseras a nondevDependencies.Seems like some or all of these deps should be in
devDependencies. In the meantime I'll have to manually identify and scrape all these files out.- added 2 commits that reference this issue
on Oct 9, 2026 I don't think that we could move
@sentry/bundler-pluginsto be adevDependency(which includesoxc-parser) in v11, as this would be a breaking change for users who rely on e.g.@sentry/node/vite.A possible solution would be to use @vercel/nft to get rid of dependencies which wouldn't be needed in the final build. We had this already in v10 for all meta frameworks like Next.js or Sveltekit, where the bundler plugins were added as a dependency. Ofc, the
@vercel/nftsolution wouldn't solve the installation problem, that could IMO only be solved in another major release when we would make@sentry/bundler-pluginsas an optional peer dep.- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Oct 9, 2026
@sentry/node@11.1.0lists@sentry/bundler-pluginsindependencies, although only the optional@sentry/node/{vite,rollup,webpack,esbuild}entry points use it; the main entry never loads it. For apps that only use the main entry, every production install therefore gets bundler-plugins and its dependencies: thesentryCLI, a nativeoxc-parserbinary,magic-string,dotenv. pnpm also links the optionalrolluppeer to whatever rollup the workspace has, which producesunmet peer rollup@">=3.2.0"warnings. Removing the package with an override has no effect on the SDK. Could it be an optional peer dependency, or live in a separate package?