Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Plan SDK-owned migrations for all Sentry SDK upgrades

Đang mở
  • Có gì không ổn?
#1,630 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
github, javascript, node.js, typescript
Lĩnh vực
backend-api-design, cli, devtools

Hướng nghiên cứu

Start by reading lib/init/wizard-runner.ts and the sentry-wizard workflow, then review the migration engine described in getsentry/cli#1499 and the related upgrade idea in #1483. The issue is a broad plan with open questions about the migration contract, artifact index, and execution across languages; it does not identify a bounded implementation task or a completion test.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Upgrading across an SDK major still means reading the migration guide and fixing renamed options, moved imports, and removed exports by hand. getsentry/cli#1499 (by @msonnb) prototyped sentry migrate with a JS v10 → v11 codemod. That PR is closing with the getsentry/cli archive, and its review set a different direction. This issue records that direction as the plan for SDK upgrades in general. #1483 tracks the user-facing sentry sdk upgrade idea.

Design direction (from BYK's review of cli#1499)

  • The CLI is the harness, not the place where migrations live. It provides the runtime: detection, dry-run, safety checks, task execution, and reporting. Migration logic for each SDK lives in that SDK's repo, so the SDK team owns it.
  • Migrations load at runtime, not inside the binary. The CLI can't ship every migration for every SDK all the time, so it fetches or imports the migration for the detected SDK and version when it needs it.
  • Use the same backend as sentry init. Upgrades should run through the server-driven workflow that sentry init uses (lib/init/wizard-runner.ts, sentry-wizard workflow), with local tools doing the file work. @betegon owns this direction.
  • Fall back to a generic path (suggested by @HazAT). When no dedicated migration exists, detect the SDK and version range, read the changelog or migration guide for that range, and list the breaking changes for an agent to act on.

Plan

  1. Detection. Find the installed SDK(s) and version(s) in the project, reusing sentry init's platform and project detection. Get the target version from the release registry.
  2. Migration contract. Define what an SDK-published migration looks like, based on the engine in cli#1499:
    • A list of small tasks with stable ids. Each task checks whether it applies and makes no change when it doesn't.
    • Deterministic edits are applied directly. Call sites that need a human decision get a TODO.
    • A failing task doesn't stop the run. --only / --skip select tasks by id.
    • Output includes a report of what's left with file:line per item, which can be handed to an agent.
  3. Distribution. SDK repos publish migrations as versioned artifacts, listed in the release registry or a similar central index. The CLI downloads and caches them on demand. Nothing is embedded at build time.
  4. Harness behavior in the CLI. Carry over the safety rules from cli#1499:
    • Require git and a clean tree (--allow-dirty to override).
    • Support --dry-run.
    • Rewrite manifests (for example package.json) without installing anything.
    • Make re-runs safe.
  5. Agent handoff. Leftover items from a migration and the output of the generic fallback go to the init backend or an agent through the same channel, so both paths produce one result format.
  6. Command surface. Combine with #1483 into one entry point (for example sentry sdk upgrade [--to <version>] [--dry-run]) instead of a separate migrate command.

Rollout

  • Phase 0: Agree on the migration contract, the distribution and index format, and how it connects to the init backend. Owners: SDK teams, @betegon.
  • Phase 1: Build the harness and the generic changelog/migration-guide fallback. This covers every SDK without a dedicated migration.
  • Phase 2: Move the JS v10 → v11 migration from cli#1499 into getsentry/sentry-javascript as the first SDK-owned migration, and run it through the harness.
  • Phase 3: Write a guide for SDK teams on adding migrations for their next majors.

Open questions

  • Where does the migration index live: the release registry, or a new endpoint?
  • How do migrations run outside JS? For example, a sandboxed JS runtime in the CLI that runs codemods for any language, or server-side execution through the init backend.
  • How should ambiguous edits that can't be made deterministically be split between local codemods and agent-assisted steps?

Related: #1483, #1468, getsentry/cli#1499

via BYK.

--

View Junior Session in Sentry

Ngôn ngữ chính
TypeScript
Star
938
Fork
166
Merge trung bình
1 ngày 5 giờ
Pull request đã merge (30 ngày)
171

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của getsentry/toolkit

Tất cả issue của getsentry/toolkit

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.