Polaris CDN が セマンティックバージョニングを採用

図解 ： Polaris CDN がセマンティックバージョニングを採用 Developer Changelog / Polaris Polaris CDN が セマンティックバージョニングを採用 CDN から読み込む Polaris Web Components のバージョン体系が semver に。互換性のある改善は今まで通り自動で降ってくるが、破壊的変更（メジャー）の適用タイミングは開発者が明示的に選べるようになった。既存アプリに即時対応は不要。 このページの構成 30秒で理解 ： 何が変わったのか semver のルール（major / minor / security） 4 つの URL と使い分け リリースの流れ図解（RC → stable → pinned） URL 別の挙動を一覧で比較 影響を受ける人 ／ 受けない人 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で理解 ： 何が変わったのか Shopify CDN から配信される Polaris Web Components が、見慣れた セマンティックバージョニング に移行した。 互換性のある改善は これまで通り自動で反映 される。一方、 破壊的変更を含むメジャーは自動では降ってこない —— 新しいメジャーの採用は 常に開発者の明示的な操作 になる。 既存アプリに即時の対応は不要。 互換性のある改善 ＝ 自動 バグ修正・アクセシビリティ／パフォーマンス改善・視覚的な調整・新コンポーネントは、stable チャネルに自動で届く。 破壊的変更 ＝ 自分で選ぶ メジャーリリースは自動適用されない。URL のメジャー番号を書き換えて初めて適用される ＝ タイミングを開発側が握れる。 今すぐの作業は無し 既存アプリは immediate action 不要と明記。ただし「どの URL を踏んでいるか」の棚卸しは早めにやる価値がある。 2 semver のルール（major / minor / security） セキュリティ修正は「古いメジャー」にも入る セキュリティ修正は影響を受ける stable リリースに適用され、 古いメジャーも対象に含まれる 。つまり「メジャーを上げないとセキュリティ修正が受け取れない」構図ではない。 @shopify/polaris-types はメジャーを揃える 型パッケージは CDN リリースと 同じメジャーバージョン を使う。CDN 側のメジャーを上げるなら、型パッケージのメジャーも合わせて上げる前提で考える。 3 4 つの URL と使い分け A. 自動で互換アップデートを受け取る（既定・推奨） アプリは既定で stable リリースチャネル を使うべき。stable への更新は、リリース候補（RC）フェーズを通過してから届く。この URL は メジャー変更があっても自動では上がらない 。 < script src ="https://cdn.shopify.com/shopifycloud/polaris-1.js"></ script > B. ピン留めリリース（バージョン固定） ピン留めしたリリースは、通常の機能追加・修正・視覚的変更を 受け取らない 。 < script src ="https://cdn.shopify.com/shopifycloud/polaris-1.1.js"></ script > 本番投入の時期を制御 通常の変更がいつ本番に届くかを自分で決める テスト時の再現 検証で使ったリリースをそのまま再現できる 障害からの復旧 アプリに影響が出た更新から戻す リリース計画との同期 自社のリリースプロセスに Polaris 更新を合わせる Caution ： polaris-1.1.js は Polaris 1.1 が stable になったときにだけ公開される 。まだ stable でないバージョンをピン留め URL で先に指定することはできない。 C. 今後の変更をテストする（リリース候補） 今後のすべての変更は、stable チャネルにリリースされる前に リリース候補ビルドでテストできる 。RC バージョンは RC 期間中に改善を積み上げ、 同じ URL のまま in-place で更新 される。開発・テスト用途を想定。 < script src ="https://cdn.shopify.com/shopifycloud/polaris-1.1-rc.js"></ script > D. 既存の polaris.js URL 既存の polaris.js は polaris-1.js と 同じタイミングで更新 される。そして メジャーリリースが出ても自動では上がらない 。 < script src ="https://cdn.shopify.com/shopifycloud/polaris.js"></ script > 4 リリースの流れ図解（RC → stable → pinned） 図中の polaris-2.js は「メジャーを上げる操作＝URL のメジャー番号の書き換え」という構造を示すための表記。 Polaris 2 の予定やリリース時期は記事に記載なし。 5 URL 別の挙動を一覧で比較 URL 互換アップデート（minor / fix） メジャーの自動適用 主な用途 polaris-1.js stable ・既定 受け取る RC フェーズ通過後に届く されない 基本これ。アプリは既定で stable チャネルを使うべき polaris.js 既存 URL 受け取る polaris-1.js と同じタイミングで更新 されない 既存アプリはそのままでよい（即時対応不要） polaris-1.1.js ピン留め 受け取らない 通常の機能・修正・視覚変更なし されない 本番投入時期の制御／テスト再現／復旧／リリース同期 polaris-1.1-rc.js リリース候補 RC 期間中に in-place で更新 — 開発・テスト用。今後の変更を先に確認する ※ ピン留め URL（ polaris-1.1.js ）にセキュリティ修正が入るかどうかの明示は記事に記載なし。記載があるのは「セキュリティ修正は影響を受ける stable リリースに適用され、古いメジャーも含まれうる」という点まで。 6 影響を受ける人 ／ 受けない人 対象 ： この 2 つ ・Shopify CDN から Polaris Web Components を読み込んでいる サードパーティアプリ ・ @shopify/polaris-types を使っている開発者 対象外 ： バージョニングは変わらない ・ App Home UI extensions ・ Admin UI extensions ・ App Bridge 既存アプリは即時対応不要（Existing apps don’t need to take immediate action）。 放置しても壊れない設計になっている ＝ 今回はカレンダーに「対応期限」を切る類の変更ではない。 7 技術者が押さえるべき5つのポイント 1. minor は自動・major は手動という非対称 互換のある改善は黙って降ってくるが、破壊的変更は URL を書き換えない限り絶対に来ない。 制御点は「URL の中のメジャー番号」ひとつ 。ここを構成管理の対象にすれば十分。 2. RC URL は「中身が動く」URL RC は同一 URL のまま in-place で更新され続ける。 再現性が無いので本番では踏まない 。開発・テスト環境専用と割り切る。 3. ピン留めは「更新を止める」以上の意味を持たない 通常の機能・修正・視覚的変更を一切受け取らなくなる。 恒久運用ではなく、時期制御・再現・復旧のための一時的な措置 として使い、戻す計画とセットで運用する。 4. 型パッケージと CDN のメジャーは連動 @shopify/polaris-types は CDN リリースと同じメジャーを使う。 「script タグのメジャー」と「package.json のメジャー」がズレると型と実体が食い違う 。CI で両者の一致をチェックするのが安い保険。 5. セキュリティ修正は古いメジャーにも入る ＝ 「上げ遅れ」の一次リスクは下がる セキュリティ修正は影響を受ける stable リリースに適用され、 古いメジャーを含む 。よって「セキュリティのためにメジャーを急ぐ」必要は薄い。ただし機能・改善は新しいメジャー側に乗るため、 上げない選択は機能面のコストとして積み上がる 。なお、旧メジャーのサポート期間や EOL ポリシーは記事に 記載なし 。 8 業務に活かせる3つのユースケース USE CASE 1 受託・自社アプリの「Polaris 読み込み URL 棚卸し」 課題 複数のアプリ／複数リポジトリで Polaris をどの URL から読んでいるか把握できておらず、どれが stable でどれが RC を踏んでいるか分からない。 打ち手 cdn.shopify.com/shopifycloud/polaris を全リポジトリで横断 grep し、 polaris.js / polaris-1.js / -rc.js / ピン留めの 4 分類で台帳化。RC を本番で踏んでいるものだけ即時 stable に寄せる。 効果 「気づかないうちに開発用ビルドが本番に乗っている」事故を潰せる。以後のメジャー移行時に影響範囲が即答できる。 技術メモ 既存アプリは即時対応不要なので、棚卸しは 止血（RC 混入）だけ先行、残りは通常リリースに同梱 で十分。 USE CASE 2 staging に RC を常設して「Polaris 起因のデグレ」を先に踏む 課題 Polaris の視覚的リファインメントやコンポーネント挙動の変化が本番で初めて表面化し、リリース直後に問い合わせが来る。 打ち手 staging / preview 環境の script を polaris-1.1-rc.js に切り替え、本番は polaris-1.js のまま。RC 期間中に主要画面のビジュアル回帰テストを定期実行する。 効果 stable に降ってくる前に影響を検知できる。検知したら Shopify 側へフィードバックする時間も確保できる。 技術メモ RC URL は 同一 URL のまま中身が更新される ため、テストは「1 回流して終わり」ではなく 定期実行 にしないと意味がない。 USE CASE 3 インシデント時の「Polaris ロールバック手順」を運用に組み込む 課題 アプリ管理画面の表示崩れ・操作不能が発生した際、原因が自社デプロイなのか Polaris 更新なのか切り分けられず、復旧が長引く。 打ち手 Runbook に「① 直近の自社デプロイを疑う ② 該当なければ script を直前の stable ピン留め URL（例 polaris-1.1.js ）に差し替え ③ 復旧したら Polaris 起因と確定 → 恒久対応後に stable へ戻す」を明文化。 効果 切り分けが数分で終わり、MTTR が短縮。「Recover from an update affecting your app」という公式のユースケースにそのまま乗る。 技術メモ ピン留め URL は その版が stable になったときに初めて公開される ため、Runbook に書くのは「常に直前の stable 版番号」。 ピン留めのまま放置すると通常の修正が一切届かない ので、戻し期限もセットで定義する。 9 提案で使える1行サマリ 「Polaris CDN が semver 化。 互換性のある改善は今まで通り自動、破壊的変更は URL のメジャー番号を書き換えたときだけ適用 。 stable を既定に、RC は staging で先行検証、ピン留めは復旧・時期制御の一時措置。 既存アプリの即時対応は不要 ——今やるべきは『どの URL を踏んでいるか』の棚卸しだけ。」 source ： shopify.dev / changelog / the-polaris-cdn-is-adopting-semantic-versioning published 2026-08-31