Avoid hardcoding GitHub tarball URLs in dependencies — breaks private registry workflows

[YashAggarwal21]

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:

• npm and yarn bypass .npmrc registry 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.0 exists there.
• Our only workaround is to use overrides or resolutions, 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 .npmrc and private registries.
• Still resolves the correct version.
• Maintains security and reproducibility (e.g., you can pin @fastify/otel@0.8.0 in 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/otel to 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!

[mydea]

Hey, thanks for raising this. We are on this and will change this to avoid the tarball in dependencies! cc @andreiborza

See: #16309

[andreiborza]

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

"overrides": {
  "@fastify/otel": "getsentry/fastify-otel#otel-v1"
}

yarn

"resolutions": {
  "@fastify/otel": "getsentry/fastify-otel#otel-v1"
}

pnpm

"pnpm": {
  "overrides": {
    "@fastify/otel": "getsentry/fastify-otel#otel-v1"
  }
}

[matmannion]

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)

[...]

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]

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.