Linuxes

Homebrewやnvmで既にインストールしたバージョンをmiseでも使いたい nvmやpyenv、Homebrewで既にインストール済みのNode.jsやPythonがある状態でmiseを導入する場合、同じバージョンを二重にダウンロードし直すのは無駄である。mise syncを使うと、他のバージョンマネージャがインストール済みのバージョンをmise管理下にシンボリックリンクとして取り込める。

レジストリに登録されていないツールをリポジトリに同梱して配布したい 【mise】mise registryでツール名とバックエンド確認をする で紹介したツールの探し方は、mise.tomlの[tools]にツール名を書く前提である。

どの環境変数のトークンが使われているか分かりにくい miseはツールのインストール時に、GitHubなどのgitプロバイダーAPIへ認証付きでリクエストするため、環境変数からトークンを読み取る。しかし複数のトークン系環境変数が定義されていると、実際にどれが使われているのか分かりにくい。mise tokenを使うと、miseが実際に使うトークンとその解決元(環境変数名)を確認できる。

コミット前のlintやテストを毎回手動で実行するのは忘れがち mise.tomlにlintやテストを実行するタスクを定義していても、コミット前に毎回自分で実行するのは忘れがちである。mise generate git-pre-commitを使うと、コミット時にmise run <タスク名>を自動実行するgit pre-commitフックを生成できる。

CI用ワークフローを毎回手書きするのは手間 【mise】mise-actionの基本的な使い方 ではjdx/mise-actionのセットアップ方法を紹介した。 【mise】mise-actionのセットアップ後にmise runでタスクを実行する では、セットアップ後にmise runでタスクを実行する方法を紹介した。

mise pruneはどうやって使用中のバージョンを判定しているか 【mise】mise pruneで使われていないバージョンをまとめて削除する は、どの設定ファイルからも参照されなくなったバージョンを自動で検出する。この判定の元になっているのが~/.local/state/mise/tracked-configsというディレクトリで、これまでにmise installやmise useを実行したプロジェクトの設定ファイルが記録されている。

複数のDependabot PRを連続マージすると事故が怖い 同一リポジトリでDependabotが作成した複数のPull Requestをgh pr mergeで連続マージすると、後続のPRが直前のマージの影響でコンフリクトを起こすことがある。

バージョン範囲指定は環境によって解決結果が変わる mise.tomlにjq = "1.8"のようにバージョン範囲を指定すると、実行環境やタイミングによって解決される具体的なバージョンが変わりうる。【mise】mise use --pinで解決済みのバージョンをmise.tomlに保存する では、--pinでmise.toml自体に具体的なバージョンを書き込む方法を紹介した。mise.lockはmise.tomlの範囲指定を変更せずに、解決結果だけを別ファイルに記録する仕組みで、mise公式ドキュメントでは--pinよりもこちらが推奨されている。

mise.tomlからツールの記述だけを削除したい 【mise】mise uninstallでインストール済みツールを削除する は、ディスク上のツールの実体を削除するコマンドである。それに対してmise unuseは、mise.tomlからツールの記述を削除するコマンドであり、他の設定ファイルから参照されなくなったバージョンは、あわせてディスクからも削除される。

mise管理外のツールをmise.tomlから参照したい Homebrewや自前のビルドスクリプトなど、mise管理外の方法でインストールしたツールがある場合、mise linkを使うとそのツールをmise管理下のバージョンとしてシンボリックリンクで登録できる。登録後はmise.tomlやmise useから通常のバージョンと同じように参照できる。