jdx

It's so cool that adopting new, secure standards like @jdxcode's Packslip is just a matter of saying "hey claude, let's also support this." jdx/packslip

project.pbxprojのコンフリクトをTuist導入で構造的になくす 私の所属している株式会社DIGITALIOでは、ポイントメディアサイトECナビを運営しており、 ECナビアンケートアプリ というモバイルアプリも展開しています。 本記事では、iOSアプリの並行開発で問題になっていた project.pbxproj のコンフリクトを、Tuist導入によって構造的になくした話をお伝えします。 tuist/tuist TL;DR 想定読者: iOSアプリの開発で project.pbxproj をGit管理している方 Tuist: Swiftで書いた定義ファイルからXcodeプロジェクトを生成するCLIツール 定義ファイルから project.pbxproj を毎回生成できるので、生成物をGit管理から除外できた project.pbxprojをGit管理することの難しさ 本アプリは、複数人で並行開発を行っています。Xcodeプロジェクトの実体は ECNaviEnqueteApp.xcodeproj/project.pbxproj という単一のテキストファイルです。ファイルの追加や設定変更のたびに、Xcode経由でこれを書き換える必要がありました。 私たちのチームは project.pbxproj をGit管理していたため、複数のブランチで同時にファイル追加や設定変更が発生すると、このファイルはコンフリクトしました。特に並行開発が増えた時期には、複数の行にまたがるコンフリクトの解消に手間がかかっていました。 PR1「project.pbxprojにファイルを追加してmasterにマージした！」 PR2「project.pbxprojにファイルを追加してmasterにマージするぞ！」 │ ▼ ＿人人人人人人人人人＿ ＞　　コンフリクト！！　＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^￣ <<<<<<< HEAD （PR1がpbxprojに追加した内容） ======= （PR2がpbxprojに追加した内容） >>>>>>> PR2 (；´Д`) 手作業でdiffを解読するしかない… また、実装ファイルだけをXcodeプロジェクトに追加し、テストファイルの追加を忘れることもありました。ビルドターゲットに含まれないテストは実行されず、CIも通るため、マージ後に追加漏れが発覚します。 これらの問題に加えて、Xcode上のGUI操作でプロジェクトを管理する方式には、次の2つの課題もありました。 設定変更がXcode上のGUI操作に依存するため、手順が煩雑になる project.pbxproj は人間にもAIエージェントにも読み解きにくく、変更の意図を追いにくい これらの課題を根本からなくすため、定義ファイルから project.pbxproj をCLIで自動生成する運用への切り替えを検討しました。生成物をGit管理から除外できるため、 project.pbxproj に起因するPR間のコンフリクトをなくせます。 XcodeGen・Tuist・Bazelの比較 プロジェクト生成ツールとして候補に挙がったのはXcodeGen・Tuist・Bazelの3つです。選ぶ条件は次の3つでした。 定義ファイルの誤りを、型とコンパイラで防げる 既存のCocoaPods運用を維持したまま導入できる 既存のビルドシステムを置き換えない この条件で各ツールを比較しました。 観点 XcodeGen Tuist Bazel 定義形式 YAML Swift DSL Starlark 定義ファイルの型検査1 なし あり なし CocoaPods互換性2 ○ ○ △ ビルドシステムの置き換え なし なし あり 結果、Tuistを導入することにしました。TuistはSwiftで記述できるため、引数の型や構文の誤りを定義ファイルのコンパイル時に検出できます。 XcodeGenは、YAMLゆえの型安全性の低さが気になりました。Bazelはリモートキャッシュや再現可能なビルドの面で強力な一方、Xcodeのビルドシステムごと置き換える規模感が今回の目的には釣り合わないと判断しました。 ! 選定後に知ったことですが、XcodeGenとTuistはどちらも tuist/XcodeProj を利用しています。Xcodeプロジェクトの読み書きを担う層は共通のため、この層に限れば、どちらを選んでも継続性の懸念は小さいと考えています。 Tuist導入の進め方 導入は影響範囲を絞るため3段階のPRに分割しました。 miseによるツールのバージョン固定 miseは、Node.jsのnvmやasdfのように、ツールのバージョンをプロジェクト単位で固定できるツールです。 mise.jdx.dev Tuistはインストール方法にmiseを推奨している3ため、本アプリでもバージョン固定にmiseを採用しました。 まずは .mise.toml を導入し、開発者間でTuistのバージョン差異が生じないようにしました。CIでも jdx/mise-action を使い、ローカルと同じバージョンのTuistを利用しています。 [tools] tuist = "4.195.9" Project.swiftの定義とMakefile整備 次に、定義ファイルの追加と便利コマンドの整備を行い、自動生成の運用フローを整えました。 Project.swift 既存のビルドターゲット・スキーム・ビルドスクリプトを Project.swift で再現し、従来と同等のビルド動作を維持しました。 import ProjectDescription private let appDependencies: [TargetDependency] = [ .sdk(name: "AdSupport", type: .framework, status: .optional), ] private let appTarget = Target.target( name: "ECNaviEnqueteApp", destinations: .iOS, product: .app, deploymentTargets: .iOS("15.0"), sources: [ .glob( "ECNaviEnqueteApp/", // ... ), ], resources: [ "PrivacyInfo.xcprivacy", .glob(pattern: "ECNaviEnqueteApp/", excluding: commonResourceExclusions), ], dependencies: appDependencies, // ... ) let project = Project( name: "ECNaviEnqueteApp", targets: [appTarget, appDevTarget, testsTarget, previewTarget], schemes: [appScheme, appDevScheme, previewScheme, testsScheme], // ... ) ビルドターゲットのファイルはglobで指定するため、ファイルを追加しても定義ファイルの編集は不要です。 CocoaPodsの統合方法 本アプリは当時CocoaPodsで依存関係を管理しており、 pod install が生成済みのXcodeプロジェクトへビルドフェーズやxcconfig参照を書き込む構成でした。そのため、 tuist generate から pod install までを一括で実行する make sync-develop 等を Makefile に用意しました。ここで地味にハマったのが、 pod install の挙動です。 sync-develop: 環境ごとに差し替えるファイルを事前にコピー cp ECNaviEnqueteApp/Resource/GoogleService-Info-Develop.plist ECNaviEnqueteApp/Resource/GoogleService-Info.plist Xcodeプロジェクト生成と依存関係の解決 tuist generate --no-open bundle exec pod install CocoaPodsには、依存関係に変更がなければ、変更のないPodのターゲットの再生成とプロジェクトへの統合を省略する 「インクリメンタルインストール」 （Incremental Pod Installation）があります。この仕組みは、 Pods/.project_cache/ に保存した前回のキャッシュキーと、今回の依存関係やビルド設定から作ったキャッシュキーを比べて変更の有無を判断します。このときアプリ側のXcodeプロジェクトの状態は見ません4。本アプリの Podfile では、当初 :incremental_installation => true を指定して有効にしていました。 install! 'cocoapods', :generate_multiple_pod_projects => true, :incremental_installation => true ... 一方、Tuistは tuist generate のたびにXcodeプロジェクトを完全に再生成するため、直前にCocoaPodsが追加したビルドフェーズやxcconfig参照は消えます。 tuist generate 直後の pod install では、 Pods/ 側のキャッシュが残っているため変更なしと判断され、ビルドフェーズやxcconfig参照が書き込まれませんでした5。原因はインクリメンタルインストールの差分判定にあったため、 :incremental_installation => false で無効化したところ、毎回書き込まれるようになりました。 ! 何らかの理由でインクリメンタルインストールを true のまま維持する場合は、 bundle exec pod install --clean-install で同様に統合できます。 project.pbxprojなどをGit管理から除外 第2段階でプロジェクト生成が安定して行えることを確認できたため、最後に ECNaviEnqueteApp.xcodeproj/ と ECNaviEnqueteApp.xcworkspace/ を git rm --cached でGit管理から除外しました。 Tuist Derived/ ECNaviEnqueteApp.xcodeproj/ ECNaviEnqueteApp.xcworkspace/ これにより project.pbxproj に起因するコンフリクトは発生しなくなりました。 Project.swift の同時編集によるコンフリクトは残りますが、読みやすいSwiftファイルの差分になります。生成物が手元に存在しない状態になるため、チームへの周知とドキュメント整備も合わせて行いました。 環境構築手順をまとめた docs/setup.md に、プロジェクト生成と依存関係のインストールの手順を追加した AIエージェント向けの CLAUDE.md に、 make sync-develop が必要になるタイミングとコマンドを記載した ドキュメントの記載例## プロジェクト生成と依存関係のインストール ECNaviEnqueteApp.xcodeproj/ と ECNaviEnqueteApp.xcworkspace/ はTuistによって自動生成されるためGit管理から除外されており、以下のコマンドによって管理している。 | コマンド | 用途 | | --- | --- | | make sync-develop | 開発用の GoogleService-Info.plist を配置し、Tuistでプロジェクトを生成、CocoaPodsを統合する | | make sync-release | 本番用の GoogleService-Info.plist を配置し、Tuistでプロジェクトを生成、CocoaPodsを統合する | 以下のケースで make sync-develop の実行が必要: - git clone の直後 - git pull やブランチ切り替え（ Project.swift やファイル構成に差分がある場合） - 依存関係の更新 - ファイルの追加・削除 make init は内部で sync-develop を呼び出すため、初回セットアップ時は make init を実行するだけでよい。 Xcodeを開いた状態で sync-* を実行した場合 Xcodeでプロジェクトを開いたまま make sync-* を実行すると、Xcodeプロジェクトが外部から書き換えられたことをXcodeが検知し、ダイアログが表示される。 「Use Version on Disk」を選択する。 make sync-* によって生成された最新のファイルがXcodeに反映される。 導入後の変化 記事の前半で挙げた4つの課題は、次のように変わりました。 課題 導入後 PR間のコンフリクト project.pbxproj 起因はなくなった ファイルの追加漏れ sources のglobに一任 GUI操作の煩雑さ Project.swift の編集と make sync-develop で完結 解読の容易性 定義ファイルの差分として追えるようになった 一方で、トレードオフもあります。 git clone 直後のほか、ブランチの切り替え、ファイルの追加・削除、依存関係の更新のたびに make sync-develop の実行が必要になりました。 また、実行のたびにXcodeプロジェクトを再生成する関係上、次の2点にも注意が必要になりました。 一時的に有効にしたい設定はXcode上のGUI操作で変更しますが、プロジェクトの再生成時に失われます。例えば、デバッグ用に追加した FIRDebugEnabled などの起動引数です。 Xcodeを開いたまま実行すると「The file "..." has been modified by another application」というダイアログが出ます。そのため、その都度Xcodeを再読み込みし、ディスク上の最新状態を反映する運用にしました。 コンフリクトの解消は内容を読み解く判断が必要でしたが、CLIで再生成する場合の結果は定義ファイルだけで決まり、失敗しても再実行で同じ状態に戻せます。この性質の違いから許容できると判断し、コマンドを Makefile にまとめ、手順をドキュメントに残しました。 まとめ project.pbxproj に起因するコンフリクトは、Tuist導入によって構造的になくせました。第1段階〜第3段階という小さなステップに分けたことで、各PRのレビューと動作確認の負荷を抑えられたのも良かった点です。 同様の課題を抱えている場合は、まず1つのビルドターゲットを Project.swift で再現し、生成物が既存の project.pbxproj と同等になることを確認してからGit管理から除外するのがおすすめです。除外した後は自動生成が通常の運用フローになるため、周知も忘れずに行いましょう。 脚注 ここでの型検査は、定義ファイルの型の誤りをコンパイル時に検出できることを指す。XcodeGenのYAMLとBazelのStarlarkは静的型を持たず、誤りは生成や評価の実行時に分かる。 ↩︎ XcodeGenとTuistはCocoaPodsを管理せず、プロジェクト生成後に pod install を実行して併用。Bazelには公式のCocoaPods統合がなく、 rules_ios やサードパーティ製のツールを使うか、Podごとにビルド設定やリソースの扱いを調整する必要がある。 ↩︎ Install Tuist · Guides · Tuist を参照。 ↩︎ 判定ロジックは project_cache_analyzer.rb と target_cache_key.rb にある。設計の背景は Phase 1 、 Phase 2 を参照。 ↩︎ Pods/.project_cache を退避すると統合が復活し、 Manifest.lock や Podfile.lock を退避しても復活しないことをCocoaPods 1.16.2で確認している。 ↩︎

mise入門まとめ：mise.toml でバージョンを揃え、mise dot で設定を運び、mise bootstrap でマシンを組む mise は、言語のバージョン（[tools]）・環境変数（[env]）・手順（[tasks]）を、リポジトリに置く mise.toml の1枚にまとめる開発環境マネージャです。いまの版では、設定ファイル（dotfiles）の持ち運びと、新しいマシンの準備まで同じ道具で書けます。 この記事は、この3つの使い方を実際の出力つきでまとめたものです。見出しの #1〜#3 が、それぞれの機能に当たります。注意点は機能ごとに1つです。 mise.toml: mise run を打つと、確認なしで信頼（trust）したことになる（2026.8.9 から）。知らないリポジトリでは、run の前に mise.toml を読む mise dot: API キーの関所は2段ある。ただし ~/.dotfiles を自分で git push する道には、どちらも掛からない mise bootstrap: 先に --dry-run で打つ予定のコマンドを見てから流す nvm・direnv・Makefile をリポジトリごとに使い分けている人に向けた記事です。設定ファイルを手でコピーしている人、新しいマシンのたびに入れ直している人も対象です。 ! この記事の内容は動画でも解説しています。下は #1 で、#2・#3 の動画は各節の頭にあります。 #1 mise.toml：Node のバージョン・環境変数・タスクを1枚に揃える シェルで有効にしておけば、cd で入るだけで Node のバージョンと環境変数が切り替わり、手順は mise run test の一言で走ります。 mise.toml の [tools]・[env]・[tasks] が、この3つに当たる nvm で切り替えていたバージョンは [tools]、direnv の環境変数は [env]、Makefile の手順は [tasks] に書きます。この節で最後にできあがる形です。 mise.toml [tools] node = "22.11.0" [env] DATABASE_URL = "postgres://localhost/shop" APP_MODE = "development" _.file = ".env" [tasks.clean] run = 'echo "[clean] done"' [tasks.build] depends = ["clean"] run = 'echo "[build] done"' [tasks.test] depends = ["build"] run = 'echo "[test] done"' 確認環境 Ubuntu 26.04 LTS（arm64）・bash・mise 2026.10.13。動作確認は 2026-10-18、公式ドキュメントの記述は 2026-10-18〜19 時点 手元の古い Node として、nodejs.org 配布の Node 18.20.8 を PATH の先頭に置いた。出力のホームは /home/zunda #2・#3 も同じ版で確かめた。API キーはすべてダミー mise の読みは「ミーズ」。作者は Jeff Dickey さん（@jdx）、MIT ライセンス。扱えるツールは登録簿（registry）に 1,000 超（公式 README） 準備：mise を入れて、シェルで有効にする macOS・Linux の公式の入れ方は curl の1行で、~/.local/bin/mise に置かれます（Windows は winget install jdx.mise）。bash なら .bashrc に有効化の1行を足し、ターミナルを開き直します（zsh・fish は公式 Getting Started）。 curl -fsSL mise.run | sh echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc mise doctor の出力が activated: yes になれば有効です。有効化の1行は、プロンプトのたびとディレクトリを移るたびに動くフックを足します。そのフックが、今いる場所の mise.toml に合わせて PATH と環境変数を書き換えます。 mise use でバージョンを決め、cd で切り替える Object.groupBy を使う ~/shop-api/server.js は、手元の Node 18.20.8 では TypeError: Object.groupBy is not a function で落ちます。mise use を1回打つと、Node 22.11.0 を入れて mise.toml を書きます。 server.js の中身 ~/shop-api/server.js const orders = [{ id: 1, kind: "book" }, { id: 2, kind: "pen" }, { id: 3, kind: "book" }]; const summary = Object.groupBy(orders, (o) => o.kind); console.log("summary:", summary); $ cd ~/shop-api $ mise use node@22.11.0 mise ✓ node@22.11.0 2.3s node-v22.11.0-linux-arm64.tar.gz mise ~/shop-api/mise.toml tools: node@22.11.0 $ cat mise.toml [tools] node = "22.11.0" $ node server.js summary: [Object: null prototype] { book: [ { id: 1, kind: 'book' }, { id: 3, kind: 'book' } ], pen: [ { id: 2, kind: 'pen' } ] } 18 のままにしたい別のリポジトリ ~/legacy-batch で mise use node@18 を打ち、行き来します。 $ cd ~/shop-api; node -v v22.11.0 $ cd ~/legacy-batch; node -v v18.20.8 $ cd ~; node -v v18.20.8 入れば 22、出れば戻ります。mise.toml をコミットすれば、clone した人も同じバージョンを使えます。どの設定で選ばれているかは mise ls で一覧できます。 [env] は信頼（trust）してから効く 外から渡す値は [env] に書きます。秘密の値は .env に 名前=値 の形で置いて _.file で読ませ、.env は .gitignore へ入れます。 ~/shop-api/.env DB_TOKEN=dotenv-dummy-token [env] は書いた値がそのままシェルに入るので、mise には「この設定を効かせてよい」と自分で許す信頼の仕組みがあります。自分で mise use して作ったファイルは最初から信頼済みです。ここでは mise trust --untrust で外し、人から受け取った設定と同じ状態で試しました。 $ cd ~/shop-api mise WARN ~/shop-api/mise.toml is not trusted, run mise trust to enable it $ node -v mise ERROR error parsing config file: ~/shop-api/mise.toml mise ERROR Config files in ~/shop-api/mise.toml are not trusted. （以下略） $ mise trust mise trusted ~/shop-api $ node -v v22.11.0 $ echo "[$DATABASE_URL]" [postgres://localhost/shop] $ echo "[$APP_MODE] [$DB_TOKEN]" [development] [dotenv-dummy-token] 未信頼のあいだは、[env] を含むファイルが [tools] ごと読まれず、node -v も止まりました。[tools] だけ・[tasks] だけのファイルは、信頼なしで読まれます（公式 security ページの What needs trust）。ホームへ出ると、環境変数は元に戻ります。 mise run を打つと、確認なしで信頼が記録される mise trust を打たなくても、信頼が記録されるコマンドがあります。未信頼の ~/team-api（[env] に GREETING = "hi"、タスク hello が1つ）で確かめます。 $ cd ~/team-api mise WARN ~/team-api/mise.toml is not trusted, run mise trust to enable it $ mise run hello [hello] $ echo hello-env=$GREETING hello-env=hi $ mise trust --show ~/team-api: trusted 確認は出ずに走り、信頼が記録されました。2026.8.9 からの仕様で、公式 security ページ（Implicit trust）はこう書いています。 Some commands trust the config they load without asking, because running them is already a decision to run the project's code. （いくつかのコマンドは、読み込んだ設定を確認なしで信頼する。それを実行すること自体が、プロジェクトのコードを走らせる判断だから） 対象は mise run・タスクの短縮形・mise install・mise exec・mise watch などです。CI（環境変数 CI がある）では、すべての設定が信頼済みとして扱われます。clone したリポジトリに mise.toml があったら、cat mise.toml で [env] と [tasks]（_.file の読む先も）を読み、mise trust --show で状態を見てから進めます。 [tasks] で手順をまとめ、mise x・mise exec で単発に動かす 順番は depends で書きます。冒頭の [tasks.clean]〜[tasks.test] がそれです。 $ mise run test [clean] $ echo "[clean] done" [clean] done [build] $ echo "[build] done" [build] done [test] $ echo "[test] done" [test] done 一言で clean → build → test の順に走り、名前を忘れたら mise tasks で一覧が出ます。人にも AI のコーディングエージェントにも「mise run test して」で渡せます。 設定に書かずに1回だけ別の版で動かすなら、mise x（mise exec の別名）です。 $ jq --version jq-1.8.1 $ mise x jq@1.7 -- jq --version mise ✓ jq@1.7 4.4s jq-linux-arm64 jq-1.7 $ jq --version jq-1.8.1 終わった後は、mise.toml にも PATH にも残りません。 有効化の1行を読まない CI・cron・スクリプトでは、mise exec -- を頭に付けます（公式 activate ページの案内）。 $ bash -c 'cd ~/shop-api && node -v' v18.20.8 $ bash -c 'cd ~/shop-api && mise exec -- node -v' v22.11.0 [env] も mise exec 経由なら入ります。mise exec も確認なしで信頼を記録するので、知らないリポジトリでは先に読みます。 なお mise が揃えるのはツールまでです。mise の Node を ldd で見ると、共有ライブラリはすべてホスト OS の /usr/lib/aarch64-linux-gnu/ を指していました。OS まで揃えるなら、コンテナや Nix の領分です。 #2 mise dot：設定ファイルを新しいPCへ運ぶ。API キーの関所は2段 mise は、dotfiles（.bashrc や CLAUDE.md のような設定ファイル）も mise dot で管理できます。この版では experimental の設定なしで動きました。 結論から言うと、API キーの関所は2段です。保存（mise dot save）はファイル名で判定し、公開（mise dot sync）は中身を読んで断ります。~/.dotfiles を自分で git push する道には、どちらも掛かりません。 mise dot add で登録し、新しいPCで apply する $ mise dot add ~/.config/starship.toml mise dotfiles: moved ~/.config/starship.toml to ~/.dotfiles/.config/starship.toml mise dotfiles: added ~/.config/starship.toml to ~/.config/mise/config.toml mise files: created symlink ~/.config/starship.toml -> ~/.dotfiles/.config/starship.toml mise files: applied ~/.config/starship.toml 1回で、ファイルを ~/.dotfiles の同じ相対パスへ移し（moved）、~/.config/mise/config.toml の [dotfiles] に "~/.config/starship.toml" = {} を足し（added）、元の場所にリンクを張ります。~/.claude/CLAUDE.md も同じ形で登録できます。 運ぶのは次の2つです。どちらも、自分だけが見られる非公開のリポジトリに置きます。 ~/.dotfiles（設定ファイルの実体）。丸ごと Git リポジトリにする ~/.config/mise の config.toml（リンクを張る先の一覧）。PC ごとの設定を置く config.local.toml は入れない（公式 dotfiles ページの案内） cd ~/.dotfiles git init -b main && git add . && git commit -m "dotfiles" git remote add origin <dotfiles リポジトリのURL> git push -u origin main cd ~/.config/mise git init -b main echo "config.local.toml" > .gitignore git add config.toml .gitignore && git commit -m "mise config" git remote add origin <mise 設定リポジトリのURL> git push -u origin main 新しいPCでは、mise を入れてから clone → trust → apply です。 git clone <dotfiles リポジトリのURL> ~/.dotfiles git clone <mise 設定リポジトリのURL> ~/.config/mise $ mise trust ~/.config/mise/config.toml mise trusted ~ $ mise dot apply mise files: created symlink ~/.claude/CLAUDE.md -> ~/.dotfiles/.claude/CLAUDE.md mise files: created symlink ~/.config/starship.toml -> ~/.dotfiles/.config/starship.toml mise files: applied ~/.claude/CLAUDE.md, ~/.config/starship.toml 出力の ~ は、グローバル設定の起点（config_root）が ~ と決まっているためで、ホーム全体を信頼したわけではありません。apply の前に何が変わるかは mise dot diff で見られます。リンクを置く場所に普通のファイルがあると、apply は置き換えずに止まります（公式 dotfiles/managed。--force で置き換え）。 API キーが紛れたら：関所は2段、自分の git push には無い 左の2つは mise の履歴にだけ掛かる。右の道（上の clone → apply で運ぶ道）には掛からない 関所があるのは mise dot add ではなく、別の機能の履歴です。mise dot track ~/.dotfiles で追跡すると、mise dot save のたびに版（checkpoint）が残ります。ここへ、anthropic_token という名前のファイルと、CLAUDE.md の末尾に足した1行 # メモ: API キー sk-ant-api03-DUMMY-0000 を置きました。 保存（mise dot save）は、ファイル名で外す $ mise dot save mise WARN history: omitted: ~/.dotfiles/anthropic_token (credential store; encrypt the file before tracking it) mise history: saved checkpoint 2: edited ~/.dotfiles/.claude/CLAUDE.md anthropic_token は外れ、CLAUDE.md はキーの行ごと版に入りました（mise dot history diff -p 1 2 で確認）。保存の段は .key・.pem・id_*・token・secret のような名前で見分け、中身は読みません（公式 dotfiles/history の Credential filtering）。 公開（mise dot sync）は、中身を読んで断る 履歴を外へ出すには、mise dot origin set で履歴用の Git リポジトリ（非公開）をつなぎ先に決め、mise dot sync を打ちます。--sync manual は、自分で sync を打ったときだけ通信する設定です。 mise dot origin set <履歴用リポジトリのURL> --sync manual mise dot sync $ mise dot sync mise ERROR cannot publish: line 4 of home/.dotfiles/.claude/CLAUDE.md in saved version 7774b4a7ea38 looks like a secret. Removing it from the file does not remove it from saved versions. Rotate the secret and remove that history (see mise.jdx.dev), then set encrypt = true on the file so later saves are protected, or run mise dot sync --allow-plaintext-history to publish it anyway 要約すると「保存済みの版の CLAUDE.md 4行目が秘密に見えるので公開しない。ファイルから消しても版からは消えない。秘密を取り替え、その履歴を消し、encrypt = true を付けること」です。押し切るなら --allow-plaintext-history です。この検査は 2026.10.5 から入りました（公式 dotfiles/encryption）。 自分で git push する道には、関所が無い 運ぶ道 何を見るか キーを書いた CLAUDE.md 保存 mise dot save ファイル名 平文のまま手元の履歴に入った 公開 mise dot sync 保存済みの版の中身 秘密に見えるとして、公開を断った 自分で git push 見ない（mise を通らない） そのまま外へ出る 上の clone → apply の運び方は3行目です。もう1つの「履歴で運ぶ道」は、mise dot track した版（checkpoint）を、つなぎ先のリポジトリとやり取りします。origin set の出力の案内では、mise dot sync が版を送り出して取り込み、mise dot pull が取り込んだ版を手元のファイルへ当てます。~/.config/mise/config.toml は、mise dot track で足さない限り運ばれない、とも出ました。 公式の推奨（Recommended setup）はこの履歴の道です。ただしつなぐと途中の版も共有されるので、公式 dotfiles/sync はつなぐ前に追跡中のファイルと過去の版を見直すよう書いています。別のPCで履歴から復元するところは試していません。 Git を自分で持ち、試した手順で運びたい → clone → apply。キーは自分で防ぐ 版の履歴ごと運び、公開前の検査も掛けたい → 履歴の道。別のPCでの受け取りは公式 dotfiles/sync で確かめる どちらの道でも、キーは設定ファイルに書かないのが前提です。書いたら、まずキーを取り替えます。履歴に残したいファイルは、mise dot track --encrypt（[history.encryption] の recipients が要る）で暗号化して追跡します。暗号化そのものは試していません。 dotfiles 専用の chezmoi で Go のテンプレートを作り込んでいるなら、そのままで足ります。ツールを mise で管理しているなら、道具を増やさずに済みます。 #3 mise bootstrap：パッケージからシェル設定まで1回で組む 動画は 11/2 07:00 公開予定です → youtu.be mise bootstrap は、「このマシンに要るもの」を1枚の TOML に書き、コマンド1回で入れる機能です。apt などの OS パッケージ、dotfiles のリンク、シェルの有効化、macOS の設定、[tools] の開発ツールまでを受け持ちます。2026.7.4 で安定版のコマンドになり、打ったときだけ動きます。 ~/.config/mise/config.toml に [bootstrap] を書く ~/.config/mise/config.toml [tools] jq = "latest" [bootstrap.packages] "apt:tree" = "latest" [bootstrap.macos.defaults] "com.apple.dock".autohide = true [bootstrap.mise_shell_activate] bash = true [dotfiles] "~/.config/starship.toml" = {} "apt:tree": キーは "マネージャ:名前" で、dnf・pacman・brew:・WinGet なども書ける。"latest" は、入っていれば上げない。mise が sudo で apt-get を呼ぶので、sudo を使える利用者で打つ [bootstrap.macos.defaults]: Dock を自動で隠す。Linux では飛ばされるだけなので、1枚を Mac と Linux で共有できる bash = true: ~/.bashrc に mise activate bash、~/.bash_profile に shims 版（mise が置く中継用のコマンドを PATH に足す形）のブロックを足す [dotfiles]: #2 と同じ形。リンク元の ~/.dotfiles/.config/starship.toml は先に置いておく curl で入れた mise では、シェルのブロックが mise を名前で呼びます。そのため ~/.bashrc と ~/.bash_profile の mise のブロックより前に、export PATH="$HOME/.local/bin:$PATH" が要ります（公式 shell activation ページ）。 status → --dry-run → --yes の順に流す $ mise bootstrap status packages apt:tree missing dotfiles ~/.config/starship.toml symlink ~/.dotfiles/.config/starship.toml missing shell bash_profile bash ~/.bash_profile shims missing shell bashrc bash ~/.bashrc activate missing defaults com.apple.dock autohide skipped (only available on macos) tools jq@latest 1.8.2 missing $ mise bootstrap --dry-run mise bootstrap: system packages sudo env DEBIAN_FRONTEND=noninteractive apt-get install -y -- tree mise bootstrap: dotfiles ln -sf ~/.dotfiles/.config/starship.toml ~/.config/starship.toml mise bootstrap: shell activation edit ~/.bash_profile (block:activate) edit ~/.bashrc (block:activate) mise bootstrap: system defaults mise bootstrap: tools mise jq@1.8.2 ⇢ would install bootstrap: follow-up if applied - macOS defaults: 1 entry(ies) skipped (only available on macos) --dry-run は何も変えず、段の見出しの下に打つ予定のコマンドを並べます。sudo が要る所も、どのファイルに手が入るかも、ここで分かります。 --yes（確認なしで当てる）で流すと、パッケージ → dotfiles → シェル → macOS の設定 → ツールの順に進みました。~/.bashrc の末尾には、目印で囲んだブロックが入ります。 >>> mise:activate >>> managed by mise — do not edit between markers eval "$(mise activate bash)" <<< mise:activate <<< 何も足さずに2回目を流すと、揃った所は飛ばします（段の見出しは省略）。 $ mise bootstrap --yes mise apt: 1 package(s) already installed mise files: all files are applied mise edits: all edits are applied mise ⇢ jq@latest 0ms · already installed 宣言した段は、マシンの今と比べて違う所だけを変えます。毎回走るのは、フック（[bootstrap.hooks]）と bootstrap タスクだけです。 既存のファイルとぶつかる所は、上書きせずにエラーで止まります。~/.config/starship.toml にリンクでないファイルを置いて試しました。 $ mise bootstrap --dry-run --only dotfiles mise bootstrap: dotfiles mise ERROR files: refusing to overwrite existing files (use --force-dotfiles or run mise dot apply --force): ~/.config/starship.toml --yes でも同じで、置き換えてよいときだけ --force-dotfiles を付けます。mise bootstrap はトランザクションではなく、途中で失敗すると手前の段の変更は残ります。直してから、同じコマンドを流し直します。 新しいマシンへ：--adopt で設定リポジトリから1回で --adopt に渡すのは設定リポジトリだけ。dotfiles のリポジトリは、その中の [bootstrap.repos] で取ってくる 設定リポジトリの直下に config.toml を置きます。上の設定に [bootstrap.repos] と CLAUDE.md の行を足し、Linux だけで試したので Dock の行は外しました。 config.toml [tools] jq = "latest" [bootstrap.packages] "apt:tree" = "latest" [bootstrap.repos] "~/.dotfiles" = { url = "you/dotfiles" } [bootstrap.mise_shell_activate] bash = true [dotfiles] "~/.claude/CLAUDE.md" = {} "~/.config/starship.toml" = {} [bootstrap.repos] が無いと、dotfiles の段が sources do not exist で止まります。repos の段は dotfiles の段より先に走るので、1回で clone からリンクまで進みます。#2 の clone → trust → apply を、この1回にまとめた形です。 新しいマシンでは、mise を curl で入れ、上の PATH の行を bootstrap より先に書きます（ブロックより前に来るように）。今のシェルにはまだ効かないので、1回目はフルパスで呼びます。 curl -fsSL mise.run | sh echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bash_profile ~/.local/bin/mise bootstrap --adopt you/mise-config --yes シェルの有効化は bootstrap が足すので、新しいマシンでは #1 の有効化の1行を手で足す必要はありません。 ls -A ~ が空のホームで、手元の Git リポジトリ（file://）を渡して流した結果です。mise 本体はホームの外の PATH が通った場所に置いたので、curl で入れる手順と認証が要る経路は試していません。 mise bootstrap: system packages mise apt: 1 package(s) already installed mise bootstrap: repos mise repos: applied ~/.dotfiles mise bootstrap: dotfiles mise files: created symlink ~/.claude/CLAUDE.md -> ~/.dotfiles/.claude/CLAUDE.md mise files: created symlink ~/.config/starship.toml -> ~/.dotfiles/.config/starship.toml mise files: applied ~/.claude/CLAUDE.md, ~/.config/starship.toml mise bootstrap: shell activation mise edits: applied ~/.bash_profile (block:activate), ~/.bashrc (block:activate) mise bootstrap: tools mise ✓ jq@1.8.2 3.2s jq-linux-arm64 設定リポジトリは ~/.config/mise に clone され、以後の mise はこれをグローバル設定として読みます（tree は先に入れていたので already installed）。--adopt は渡したリポジトリの設定を、その実行では信頼して流します。人のリポジトリなら先に読んでください。 自分の設定は変えずに、チームが保守するセットアップ用リポジトリを当てるなら --from です（~/.local/share/mise/bootstrap-repo に置く。この記事では試していません）。 Mac で使うとき 公式ドキュメントの記述で、Mac では動かしていません。 brew: は、Homebrew が無くても Apple Silicon なら mise が /opt/homebrew に入れる。brew: の行は Linux でも当たるので、Mac だけに入れたい行には os = "macos" を付ける Dock の設定は、Dock を開き直すまで見た目が変わらない。フックで開き直せる 設定から行を消しても元に戻らない。戻すときは defaults delete などで自分で消す ~/.config/mise/config.toml [bootstrap.packages] "brew:ripgrep" = { os = "macos" } [bootstrap.hooks] post-defaults = "killall Dock || true" まとめ mise.toml の1枚で、cd だけでバージョンと環境変数が切り替わり、手順は mise run で走る [env] を含む設定は信頼してから効く。mise run・exec・install は確認なしで信頼を記録するので、知らないリポジトリでは先に読む mise dot の関所は、保存（名前で見る）と公開（中身を見る）の2段。自分の git push には掛からないので、キーは書かない。書いたら取り替える mise bootstrap は status → --dry-run → --yes。2回目は揃った所を飛ばし、ぶつかる所は止まる。新しいマシンでは、--adopt の1回で clone からツールまで通った（mise を curl で入れる手順は試していない） まずは自分のリポジトリで mise use node@<使うバージョン> を1回打ち、できた mise.toml をコミットしてみてください。 動画で見たい方はこちら（mise講座 #1〜#3）: mise入門 cdするだけでNodeのバージョンも環境変数も揃う｜mise講座 #1 【mise dotfiles】設定ファイルを新しいPCへ持ち運ぶ。APIキーが紛れたら止まる？素通り？ 【mise bootstrap】手元のTOML 1枚でマシンのパッケージから設定まで一括構築するのだ 参考リンク（一次情報） jdx/mise（GitHub・README） Getting Started（入れ方・有効化） Security（What needs trust・Implicit trust） Environments（ env ・_.file） TOML-based Tasks mise exec・mise activate Configuration（config_root） dotfiles・managed・history・encryption・sync Bootstrap・packages・Shell activation・from a repository CHANGELOG（2026.8.9 implicit trust・2026.7.4 stabilize bootstrap） chezmoi: Comparison table

mise: Your Dev Environment, Perfectly Orchestrated. ⚡ Tech breakdowns, AI news, and future trends. Hit subscribe to stay ahead. mise is a command-line tool that unifies the management of a project's development tools, environment variables, and tasks using a single `mise.toml` configuration. It ensures consistent environments across local development, editors, and CI, and can also bootstrap entire machines with packages and dotfiles. It drastically reduces developer onboarding time, eliminates 'it works on my machine' issues, and ensures consistent development and CI/CD environments. This leads to faster development cycles, improved team productivity, and more reliable deployments by standardizing toolchains and configurations. 🔗 GitHub: jdx/mise 🌐 Website: letsmakeourworld.vercel.app 🎁 The Essential `mise.toml` Starter Kit: Get Your Project Running Flawlessly in 5 Minutes (Includes common configurations for popular languages and frameworks). 💬 Comment "FUTURE50" below and we'll send you the link to try it yourself! 🔔 Subscribe for weekly deep dives on trending open source tools. #developer tools #devops #environment management #CLI #automation #project setup #productivity #consistency 🚀 Build with HyperAutomationLabs: Website: letsmakeourworld.vercel.app Source/demo repo: jdx/mise 🔔 Subscribe for more tech content from HyperAutomationLabs. 💬 Comment "POWER18" below to get The Essential `mise.toml` Starter Kit: Get Your Project Running Flawlessly in 5 Minutes (Includes common configurations for popular languages and frameworks). or tell us what use case you want us to build next. 📌 Timestamps: 0:00 Introduction #HyperAutomationLabs #tech #AI #Automation #BuildInPublic --- ⚠️ ARCHIVAL NOTICE & AGENT PRODUCTION DISCLAIMER: This video was researched, written, voiced, and edited autonomously by an AI documentary agent (ProjectNexus Autonomous Media Engine). Content is synthesized from public domain historical archives, declassified records, investigative news reports, and open cold case dossiers for educational, documentary, and historical preservation purposes. Living individuals mentioned are presumed innocent unless proven guilty in a court of law.

A single mise.toml turns setup from tribal knowledge into a runnable contract. mise is interesting because tools, env vars, and tasks start from the same file in shells, checkouts, and CI. The CLI is cheap. Maintaining the contract is the real work. #SystemsLiteracy

For me, mise is one of the defining tools of the past decade. Maybe, even the past two. Highly recommend it - mise.jdx.dev

mise: Dev tools, env vars, and tasks in one CLI (35k stars) What it does All text below is quoted directly from the project README. >mise (pronounced "meez", short for mise-en-place) installs a project's tools, sets its environment variables, and runs its tasks from one mise.toml that works in your shell, editor, and CI. With mise bootstrap, it can also set up a whole machine: packages, dotfiles, and services. What is mise?: - Install tools such as Node.js, Python, and Terraform from a registry of 1,000+, with a different version in each project. - Set environment variables and load .env files for each project. - Run tasks, such as build and test, with the project's tools and environment variables. - Set up a machine with mise bootstrap, which applies the system packages, dotfiles, repositories, and services you declare for it. >curl https://mise.run | sh Repository jdx/mise Repository stats |Metric|Value| |:-|:-| |Stars|35,120| |Forks|1,485| |Last release|v2026.10.13 (2026-10-17)| |Languages|Rust 81.7%, Shell 15.7%, PowerShell 1.7%| |Contributors|997| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|Copilot: 52, codex: 7, cursoragent: 27, claude: 1885| |AI co-authored commits|Claude: 1986, Codex: 7, Cursor: 28, Copilot: 51| Main contributor |Field|Value| |:-|:-| |GitHub|@jdx| |Commits to this repo|5,978 (top contributor)| |Company / Location|@entirehq / Dallas, TX| |Website|jdx.dev| |X / Twitter|@jdxcode| |Followers|4,381| |Public repos|693| |On GitHub since|2010-03-04| ----------------------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free

» fix(install): ignore interrupted installs when listing versions and runtime symlinks by jdx · Pull Request #13596 · jdx/mise mise#13596 «\n\nmise install中にincompleteマーカーを付けているのに参照側でそれを見ず、おかげでinstall/upgradeがアトミックでない問題、数年ごしでやっと解決してた…

perf in mise has improved significantly in 2026.10.11. the version listing (which is on the critical path for many commands) has been greatly optimized. With python, for example, it's gone down from 2.4s to 130ms in my benchmark. github.com/jdx/mise/releases/tag/v2026.10.11

@eloffd i've averaged 66/day over the past 30 days including weekends. all open source if you think it's BS have a look for yourself: github.com/jdx