Plan SDK-owned migrations for all Sentry SDK upgrades
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- github, javascript, node.js, typescript
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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 thatsentry inituses (lib/init/wizard-runner.ts,sentry-wizardworkflow), 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
- 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. - 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/--skipselect tasks by id. - Output includes a report of what's left with
file:lineper item, which can be handed to an agent.
- 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.
- Harness behavior in the CLI. Carry over the safety rules from cli#1499:
- Require git and a clean tree (
--allow-dirtyto override). - Support
--dry-run. - Rewrite manifests (for example
package.json) without installing anything. - Make re-runs safe.
- Require git and a clean tree (
- 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.
- Command surface. Combine with #1483 into one entry point (for example
sentry sdk upgrade [--to <version>] [--dry-run]) instead of a separatemigratecommand.
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-javascriptas 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.
--
- 主要言語
- TypeScript
- スター
- 938
- フォーク
- 166
- 平均マージ
- 1日 5時間
- マージ済み PR（30日）
- 171
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
getsentry/toolkit のほかの issue
-
bug MCP
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
getsentry/toolkit#1621 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug MCP
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
getsentry/toolkit#1618 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Docs MCP tool failures omit isError対応中かも @thomasjiangcy が 1 日前に担当しました。 オープンbug MCP
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
getsentry/toolkit#1600 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
getsentry/toolkit#1471 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
getsentry/toolkit#1632 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
getsentry/toolkit の issue をすべて見る
似ている issue
-
freshness freshness:observed-only
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
thoroc/context-radar#282 ·
-
bug P2 rust
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
area: web
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
gabe-santana/arkdraw#25 ·
-
bug require-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
expressjs/expressjs.com#2549 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug good first issue hacktoberfest
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
codercops/discord-bot#101 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信