リポジトリ
ドキュメント
サポートポリシー

オペレーティングシステム

turbo は、一般的に、x86_64 および ARM 64 アーキテクチャの両方で、Debian ベースの Linux ディストリビューション、macOS、および Windows でサポートされています。具体的には、次のバイナリを npm 経由で構築および配布します。

  • turbo-darwin-64 (Intel チップ搭載の macOS)
  • turbo-darwin-arm64 (Apple Silicon 搭載の macOS)
  • turbo-linux-64
  • turbo-linux-arm64
  • turbo-windows-64
  • turbo-windows-arm64

Darwin ビルドは、Intel および Apple Silicon 搭載の macOS を対象としています。Linux ビルドは Ubuntu でテストされていますが、ほとんどの Debian ベース (新しいタブで開く) のディストリビューションで動作することが期待されます。Windows ビルドは、GitHub Actions の windows-latest ランナー (新しいタブで開く) でテストされています。

サポートされていないプラットフォーム

サポートされていないプラットフォームで turbo を実行することは、ソースからコンパイルすることで可能です。手順は、貢献ガイド (新しいタブで開く) にあります。ビルドされたソースは単一のバイナリであるため、Node.js パッケージマネージャー (例: npm install turbo) でインストールして起動する代わりに、turbo バイナリを直接実行します。

/path/to/turbo run build

また、このような turbo の呼び出しは、node_modules ディレクトリにローカルインストールされた turbo にも従うため、package.json の依存関係に turbo が含まれる JavaScript プロジェクトで turbo を実行しようとする場合は、ローカルインストールされたバイナリへの遅延をスキップするために --skip-infer フラグを使用してください。

Node.js の互換性

ほとんどのコア turbo 機能 (特に turbo run) は、システム上のアクティブな Node.js のバージョンに依存しませんが、Turborepo およびそのエコシステムのいくつかの機能 (例: create-turboturbo-ignore、および eslint-plugin-turbo など) は依存します。これらの機能については、Node.js の Active および Maintenance LTS バージョン (新しいタブで開く) をサポートする予定です。

私たちのサンプルはすべて、これらのバージョンでも動作することが期待されています。

パッケージマネージャー

コアとなるturboの機能は、JSエコシステムにおけるパッケージマネージャーと、それらのワークスペース構成(モノレポ内)およびロックファイル形式の実装に依存しています。私たちは以下をサポートする予定です。

  • npm (v6+)
  • yarn (v1+)(v4は部分的にサポート)
  • pnpm (v6+)
  • bun (v1+)(ベータ版、すべての機能をサポートしているわけではありません)

パッケージマネージャー自体が独自のリリーススケジュール、バグ、および機能を備えていることに注意してください。私たちは新しいメジャーバージョンに対応するつもりですが、すぐにサポートをリリースできない場合があります。

バージョン管理

私たちは、.gitでバージョン管理されているリポジトリと、まったくバージョン管理されていないリポジトリをサポートしています。他のバージョン管理システムはすべて無視されます。gitを使用してファイルをハッシュするため、gitのないリポジトリはパフォーマンスや動作が異なる可能性があることに注意してください。

リリース

Turborepoは「緩やかに」SemVerポリシーに従います。これは、一般的に、パッチバージョンやマイナーバージョンで意図的な「破壊的」変更を加えることはないことを意味します。

これに対する例外としては、次のようなものがあります。

  • turbo.jsonにおける構成の変更。

    これらは通常、npx @turbo/codemod updateで実行できるcodemodと、少なくとも非推奨メッセージを含むマイナーリリースを伴う必要があります。

  • turboのCLIコマンドに対する意図的な動作変更。

    これらはマイナーリリースで着地する必要があります。変更が大きく、混乱を招くほどの場合は、以前の動作を選択するためのフラグを含めることがあります。