Repository navigation
Avoid hardcoding GitHub tarball URLs in dependencies — breaks private registry workflows #16311
Description
Problem Statement
Hi Sentry team 👋,
We’re running into issues due to a dependency introduced in @sentry/node@9.19.0 which references a GitHub tarball directly:
Reference PR - #16287
"@fastify/otel": "https://codeload.github.com/getsentry/fastify-otel/tar.gz/ae3088d65e286bdc94ac5d722573537d6a6671bb"This causes real problems in environments like ours, where only private registries (e.g., AWS CodeArtifact) are allowed for security and compliance reasons.
Problem
Since this dependency is declared as a tarball URL:
npmandyarnbypass.npmrcregistry settings.- The URL appears in
package-lock.json, triggering CI validation errors like:
wrong registries appear in package-lock.json file:
https://codeload.github.com/getsentry/fastify-otel/tar.gz/...
- The package cannot be fetched from our private registry, even though version
@fastify/otel@0.8.0exists there. - Our only workaround is to use
overridesorresolutions, which we’d prefer to avoid.
Solution Brainstorm
Expected Behavior
We’d like to see Sentry declare the dependency as a semver range like:
"@fastify/otel": "^0.8.0"This:
- Respects
.npmrcand private registries. - Still resolves the correct version.
- Maintains security and reproducibility (e.g., you can pin
@fastify/otel@0.8.0in your lockfile).
Why This Matters
Many regulated environments prohibit installing packages from arbitrary URLs. Package managers like npm and yarn are designed to route semver-based dependencies through controlled registries, which allows:
- Auditing
- Mirror caching
- Dependency tracking
- Strict CI enforcement
Hardcoded tarball URLs break that model.
Ask
Would you consider:
- Removing the tarball URL reference to
@fastify/otel - Replacing it with a proper version (e.g.,
^0.8.0) - Or publishing
@fastify/otelto npm under the Sentry organization and referencing that
This small change would make Sentry easier to adopt in enterprise environments.
Thank you for the great work on the SDK!
Activity
mydea commentedon May 15, 2025
Hey, thanks for raising this. We are on this and will change this to avoid the tarball in dependencies! cc @andreiborza
See: #16309
andreiborza commentedon May 15, 2025
Hi @YashAggarwal21, thank you for taking the time to write such detailed and well written issue!
This change has caused a bunch of problems, sorry for that :(. We're working on vendoring the package in which will hopefully resolve that issue.
I'm wondering if you can get around this issue for now by adding a resolutions entry to your
package.json(depending on your package manager it's slightly different)npm
yarn
pnpm
matmannion commentedon May 15, 2025
We're affected by this issue but unfortunately that wouldn't fix it for us either as it'd have a dependency on cloning the fork from Github, and we don't allow access to that (just a proxy to the npm registry).
Vendoring seems like the best solution here so we are left with pinning to old versions until this is implemented.
andreiborza commentedon May 19, 2025
Thanks for following up on the suggestion and sorry for all the trouble this is causing. We'll proceed with vendoring our fork in, for now, please pin to
9.17.0.YashAggarwal21 commentedon May 19, 2025
@andreiborza, thanks for the response and taking a look at this on priority. I will move ahead with your suggestion. You guys are doing a great job
andreiborza commentedon May 20, 2025
@YashAggarwal21 we just released
9.21.0with a vendored version of@fastify/otel. This should be resolved now, if you still have issues please let us know.YashAggarwal21 commentedon May 21, 2025
@andreiborza, thanks it works fine for us now