npmの代替となるvlt入門

vltは、npmを開発・保守してきたメンバーが手がける、無料のオープンソースJavaScriptパッケージマネージャーです。

vltは1.0のリリースによって本格的な選択肢になりました。package.json からのインストールに対応し、インストールをダウンロードとスクリプト実行の2段階に分け、依存関係グラフ用のクエリ言語も備えています。導入でつまずきやすいのは、ロックファイル、.npmrc の認証設定、postinstallスクリプト、そして何よりパッケージの取得元となるレジストリといった細部です。本ガイドでは、既存のプロジェクトを題材にこれらを順に確認し、最後に明確な結論を示します。

vltパッケージマネージャーとは？開発したのは誰か？

vltは、パッケージマネージャーのクライアントとホスト型レジストリサービスから成り、npmを開発したメンバーによって作られています。Darcy Clarke、Ruy Adorno、Luke Karrysの連名による2024年11月のローンチ記事では、無料かつオープンソースのツールとして紹介されました。vlt 1.0は2026年8月4日にリリースされ、その後も1.x系のリリースが続いています。

vlt CLIはnpmユーザーにとってなじみやすいものですが、アーキテクチャは異なります。もう一つの主要なnpm代替ツールと比較検討する場合は、pnpmが同じ課題にどう取り組んでいるかも参照してください。

vltをインストールして既存プロジェクトで実行する

vltは公式スクリプトまたはnpm経由でインストールできます。インストール後は、vlt install で依存関係を取得し、vlt build でそれらのスクリプトを実行します。

# official installer, then configure a registry and account
curl -fsSL https://install.vlt.sh | bash
vlt setup

# or install through npm
npm install -g vlt

cd your-project
vlt install   # resolve, download, extract; no dependency scripts run
vlt build     # run lifecycle scripts for eligible packages

npm経由のインストール方法はnpm移行ガイドに記載されています。vlt install を実行するには、事前にレジストリを設定しておく必要があります。設定に関するドキュメントによると、vltにはデフォルトのレジストリが用意されておらず、レジストリへのアクセスが必要なコマンドは、設定が完了するまで設定エラーで停止します。

プロジェクトのルートでは、次の2つのファイルを扱います。

• vlt.json：プロジェクト設定ファイル。.npmrc の役割を引き継ぎます。
• vlt-lock.json：vltのロックファイル。

npm移行ガイドによると、vltは package-lock.json を読み込まず、すべてをゼロから解決します。古いロックファイルは削除しても構いませんし、両方のツールを並行して使う間は残しておくこともできます。この点は、npmからpnpmへの移行で紹介しているpnpmのロックファイルインポート機能に比べると親切ではありません。マージする前に、解決されたバージョンの差分を必ず確認してください。

vltはそのまま置き換えられるのか？

「ドロップイン置き換え」は前提とせず、検証すべき事項として扱ってください。2024年のローンチ記事では、vltは「ほとんどの場合」既存のパッケージマネージャーを置き換えられるとされていました。1.0の記事ではさらに踏み込み、クライアントをnpmのドロップイン置き換えと位置付けています。ただし、どちらもベンダー自身の主張です。自分のプロジェクトで、次の5つの領域を確認してください。

1. .npmrc の設定：vltが .npmrc を読み込むとはドキュメントに記載されていません。レジストリとスコープの設定は、vlt.json の scoped-registries に記述します。認証トークンは、npm移行ガイドの説明どおり、vltのキーチェーンファイルまたは VLT_TOKEN 環境変数に格納します。移行で最初に問題が起きやすいのはプライベートスコープです。
2. インストールスクリプトを持つパッケージ：ネイティブアドオンやバイナリをダウンロードするパッケージは、vlt build を実行するまで動作しません（後述）。
3. peer dependencies：installのドキュメントによると、vltはpeer dependencyをそれぞれ1つのコピーに集約することを目指しています。ツリー内の複数の箇所が共存できないpeerバージョンを必要とする場合、vltはそれぞれに独自のpeerコンテキストを割り当てます。npmのERESOLVEエラーで失敗するツリーも、vltでは解決できる可能性があります（ただし、peerのコピーが複数になる場合があります）。
4. ワークスペース：モノレポについては、vltのドキュメントに専用のページがあります。自分のプロジェクト構成と照らし合わせて確認してください。
5. CI：vlt ci を実行した後に vlt build を実行します。

パッケージマネージャーの切り替えに起因するリグレッションは、CIを通過して本番環境で初めて表面化することがあります。推移的依存関係のバージョンが変わったり、ファイルを生成するはずだったpostinstallがスキップされたりすると、ブラウザのランタイムエラーとして現れることがあります。コンソールとネットワークのキャプチャを備えたセッションリプレイを使えば、そうしたエラーとロックファイルを変更したデプロイを結び付けられます。

レジストリ：パッケージの取得元

vltクライアントにはデフォルトのレジストリがないため、自分で選ぶ必要があります。レジストリに関するドキュメントによると、インストール系のコマンド（vlt install、vlt ci、vlx など）を実行するには、npm レジストリエイリアスが設定されている必要があります。vlt.json、フラグ、VLT_REGISTRY で単に registry の値を指定するだけでは、これらのコマンドには不十分です。もう一つの方法は vlt setup で、vlt.ioアカウントのレジストリを設定します。

vlt setup を実行すると、パッケージの取得元が変わります。npm エイリアスが、vltのレジストリ上にあるアカウント専用のミラーを指すようになるためです。vltのホームページによると、パブリックパッケージへのリクエストはすべてそのミラー上でセキュリティチェックを受け、既知のマルウェアはブロックされます。つまり、信頼の起点（トラストルート）がnpmからvltに移ることになります。

パブリックなnpmレジストリを直接使う場合は、次のコマンドを実行します。

vlt config set registries=npm=https://registry.npmjs.org/

プロジェクト内で実行すると、このエイリアスはプロジェクトの vlt.json に書き込まれます。チーム全体とCIで同じ取得元を使えるよう、このファイルをコミットしてください。

注意点が1つあります。2026年4月に報告されたissueによると、vlt install は既存の vlt-lock.json に記録されたレジストリURLを使い続けます。レジストリを切り替える場合は、ロックファイルを再生成してください。

レジストリによるブロックで防げるのは、すでに特定済みのマルウェアだけです。新たに公開された悪意あるバージョンは、誰かが報告するまですり抜ける可能性があります。プライベートなホスティングが必要なチームは、vltが提供するnpm互換かつFair Sourceのレジストリであるvsrをセルフホストすることもできます。ローンチ記事では、ローカル、セルフホスト、マネージドのいずれの形態でも利用できると説明されています。

セキュリティのデフォルト：段階的インストールと vlt build

vlt install は依存パッケージのスクリプトを一切実行しません。その後の vlt build で、ライフサイクルスクリプトを持つすべてのパッケージのスクリプトが実行されます。ただし、セレクターで対象を絞り込まない限り、既知のマルウェアアラートがあるパッケージは除外されます。buildのドキュメントでは、デフォルトの対象が次のように定義されています。

:scripts:not(:built):not(:malware)

承認のプロンプトはありません。スクリプトを承認するには、より範囲を絞ったDependency Selector Syntaxのクエリを記述します。そのクエリをbuildの対象として渡すか、install時に --allow-scripts で指定し、チーム全体で同じクエリを使えるよう vlt.json に保存してください。この仕組みについては、vlt build の紹介記事で詳しく解説されています。

実際には、段階的インストールにより、ビルド済みバイナリの取得やネイティブアドオンのコンパイルにpostinstallスクリプトを必要とするパッケージは、vlt install の後もビルドされていない状態になります。そのバイナリや生成ファイルに依存するものは、vlt build を実行するまで失敗する可能性があります。すべてのセットアップスクリプトとCIジョブに vlt build を組み込んでください。

この考え方は、npmのインストールスクリプトをデフォルトで無効化するアプローチと同じです。ただし、利用者側の対策で守れるのはインストールだけです。公開する側では、npm pack --dry-run でパッケージの内容を確認し、意図しないファイルを公開しないようにしましょう。

vlt query による依存関係グラフのクエリ

vlt query は、querySelectorAll がページから要素を抽出するのと同じように、CSS風のセレクターを使って解決済みの依存関係グラフからパッケージを抽出します。1.0の記事によると、グラフ用の疑似セレクターは60以上あり、そのうち約30がセキュリティ関連です。vltのinsightsセレクターに関する記事によると、セキュリティ関連のセレクターはSocketのメタデータを利用しています。

vlt query ':scripts'                  # packages with install scripts
vlt query ':malware'                  # packages with known malware alerts
vlt query ':prod'                     # production dependencies only
vlt query ':scripts' --view=mermaid   # render matches as a Mermaid diagram

queryのドキュメントには、出力モードとして human、json、mermaid、svg、png、count が挙げられています。まずは :scripts から始めましょう。このリストが、vlt build がデフォルトで対象を選ぶ母集団になるためです（そこからビルド済みのパッケージとマルウェアアラートのあるパッケージが除外されます）。vltのhost-contextに関する記事によると、:host(local) を使うと、vltのダッシュボードで設定した複数のプロジェクトを横断してクエリを実行できます。

同じセレクターはCIでも使えます。

- run: npm install -g vlt
- run: vlt ci          # vlt install --expect-lockfile
- run: vlt build
- name: Report dependencies with malware alerts
  run: vlt query ':malware' --view=count

最後のステップでジョブを失敗させたい場合は、queryのドキュメントに記載されている --expect-results=0 を追加します。クエリはどこでも同じです。1つのセレクター文字列として保存されたものが、そのままポリシーになります。

結論：サイドプロジェクトで試す価値はあるが、まだデフォルトには早い

vltは、現時点でサイドプロジェクトで試してみる価値があります。本番環境を担うチームは、自分たちのCI、プライベートレジストリの認証、インストールスクリプトを持つパッケージがすべてvltで問題なく動作するまで、現在のパッケージマネージャーを使い続けるべきです。段階的インストールと vlt query は便利ですが、ロックファイルをゼロから解決し直す点と、レジストリの選択については、慎重に判断する必要があります。インストール速度を最も重視するなら、Rustで書き直されたpnpm 12と自分のリポジトリで比較してみてください。

まずはブランチで始めましょう。npm レジストリエイリアスを明示的に設定し、vlt install、vlt build、vlt query ':scripts' を実行します。そして、mainにマージする前に、vlt-lock.json で解決されたバージョンを古いロックファイルと比較してください。

よくある質問

vltに必要なNode.jsのバージョンは？また、node_modulesフォルダーは作成されますか？

vltパッケージにはNode.js 22.22以降が必要です。vltはnode_modulesディレクトリを作成しますが、node_modules/.vlt/ 配下に独自の内部レイアウトを採用しており、npmのフラットなツリーとは異なります。デフォルトでは、Linuxではグローバルストアからファイルをハードリンクし、macOSとWindowsではパッケージごとに展開します。この挙動はstore-linker設定で変更できます。実行時のパッケージ解決は通常どおり行われるため、アプリケーションコードを変更する必要はないはずです。

vltでは、npxやnpm runの代わりに何を使いますか？

npxの代わりはvlt execです。vlt xやショートカットのvlxとしても呼び出せます。パッケージのバイナリを実行し、node_modulesにない場合はパッケージをダウンロードしますが、新しいものを取得する前に確認を求めます。vlxlはインストール済みのバイナリのみを実行します。vlt run（短縮形はvlr）は、package.jsonのスクリプトをpre/postフックとともに実行します。どちらも --scope セレクターでワークスペースを対象に指定できます。

npmのoverridesをvltに移行するには？

npmのoverridesフィールドに相当するvltの機能はGraph Modifiersです。vlt.jsonで定義し、Dependency Selector Syntaxのクエリとして記述します。これにより、パッケージ名だけでなく、パス、ワークスペース、semverの範囲で依存関係を指定できます。複数のモディファイアが同じ依存関係に一致した場合は、CSSに似た詳細度（specificity）のルールに従って、どれを適用するかが決まります。

vltのモノレポでワークスペースを設定するには？

vltはルートのpackage.jsonのworkspacesフィールドをそのまま読み込むため、既存のnpmやyarnのモノレポは変更なしで動作します。名前付きグループを使いたい場合や、pnpm-workspace.yamlから移行する場合は、ルートのvlt.jsonのworkspacesフィールドを使います。vlt.jsonにworkspacesフィールドがある場合、vltはそれだけを使用し、package.jsonのフィールドは無視します（両者はマージされません）。vlt.jsonでは、値としてglob文字列、packages/* のようなglobの配列、またはそれぞれがパスやglobに対応する名前付きグループのオブジェクトを指定できます。単純な配列はpackagesという名前のデフォルトグループに割り当てられます。