パッケージ依存関係
依存関係は、pubパッケージマネージャー の中核概念の1つです。依存関係とは、パッケージが動作するために必要な別のパッケージのことです。依存関係はpubspecで指定します。直接使用するソフトウェアである直接依存関係のみをリストします。Pubは推移的依存関係を自動的に処理します。
このページには、依存関係の指定方法に関する詳細情報が記載されています。最後にパッケージ依存関係のベストプラクティスのリストがあります。
概要
#各依存関係に対して、依存するパッケージの名前と、許可するそのパッケージのバージョンの範囲を指定します。また、ソースを指定することもできます。ソースは、Pubにパッケージの場所を伝えるものです。
例として、次の形式で依存関係を指定します。
dependencies:
transmogrify: ^1.0.0このYAMLコードは、デフォルトのパッケージリポジトリ（pub.dev）を使用してtransmogrifyパッケージへの依存関係を作成し、1.0.0から2.0.0（ただし2.0.0は含まない）までの任意のバージョンを許可します。この構文については、バージョン制約を参照してください。
pub.dev以外のソースを指定するには、sdk、hosted、git、またはpathを使用します。たとえば、次のYAMLコードはpathを使用して、ローカルディレクトリからtransmogrifyを取得するようにPubに指示します。
dependencies:
transmogrify:
path: /Users/me/transmogrify次のセクションでは、各依存関係ソースの形式について説明します。
依存関係ソース
#Pubは、パッケージの場所を特定するために次のソースを使用できます。
ホストされているパッケージ
#ホストされているパッケージとは、pub.devサイト（または同じAPIを使用する他のHTTPサーバー）からダウンロードできるパッケージです。ホストされているパッケージへの依存関係の宣言例を次に示します。
dependencies:
transmogrify: ^1.4.0この例では、パッケージがtransmogrifyという名前のホストされているパッケージに依存しており、1.4.0から2.0.0（ただし2.0.0自体は含まない）までの任意のバージョンで動作することを指定しています。
独自のパッケージリポジトリを使用する場合は、hostedを使用してそのURLを指定できます。次のYAMLコードは、hostedソースを使用してtransmogrifyパッケージへの依存関係を作成します。
environment:
sdk: '^2.19.0'
dependencies:
transmogrify:
hosted: https://some-package-server.com
version: ^1.4.0バージョン制約はオプションですが、推奨されます。バージョン制約が指定されていない場合、anyが想定されます。
Gitパッケージ
#最新の状態を維持し、まだ正式にリリースされていないパッケージを使用する必要がある場合があります。パッケージ自体がまだ開発中であり、同時に開発されている他のパッケージを使用している可能性があります。それを容易にするために、Gitリポジトリに保存されているパッケージに直接依存することができます。
dependencies:
kittens:
git: https://github.com/munificent/kittens.gitここのgitは、このパッケージがGitを使用して見つかり、その後のURLはパッケージのクローン作成に使用できるGit URLであることを示しています。
パッケージリポジトリがプライベートであっても、SSHを使用してリポジトリに接続できる場合、リポジトリのSSH URLを使用してパッケージに依存できます。
dependencies:
kittens:
git: git@github.com:munificent/kittens.git特定のコミット、ブランチ、またはタグに依存する場合は、説明にrefキーを追加します。
dependencies:
kittens:
git:
url: git@github.com:munificent/kittens.git
ref: some-branchrefは、Gitがコミットを識別するために許可するものであれば何でもかまいません。
Pubは、パッケージがGitリポジトリのルートにあると想定しています。リポジトリ内の別の場所を指定するには、リポジトリルートを基準とした相対パスを指定します。
dependencies:
kittens:
git:
url: git@github.com:munificent/cats.git
path: path/to/kittensパスはGitリポジトリのルートを基準とした相対パスです。
Git依存関係は、pub.devにアップロードされたパッケージの依存関係としては許可されていません。
パスパッケージ
#同時に複数の関連パッケージを操作している場合があります。フレームワークを作成しながら、それを使用するアプリを構築しているかもしれません。そのような場合、開発中は、ローカルファイルシステム上のパッケージのライブバージョンに依存することを本当に望むでしょう。そうすれば、あるパッケージの変更は、それに依存するパッケージによってすぐに検出されます。
それを処理するために、Pubはパス依存関係をサポートしています。
dependencies:
transmogrify:
path: /Users/me/transmogrifyこれは、transmogrifyのルートディレクトリが/Users/me/transmogrifyであることを示しています。この依存関係について、Pubは参照されたパッケージディレクトリのlibディレクトリへのシンボリックリンクを直接生成します。依存パッケージに加えた変更はすぐに反映されます。依存パッケージを変更するたびにPubを実行する必要はありません。
相対パスが許可されており、pubspecを含むディレクトリを基準とした相対パスとみなされます。
パス依存関係はローカル開発に役立ちますが、外部とのコード共有では機能しません。そのため、pubspecにパス依存関係がある場合、pub.devサイトにパッケージをアップロードすることはできません。
代わりに、一般的なワークフローは次のとおりです。
- パス依存関係を使用するようにローカルのpubspecを編集します。
- メインパッケージとその依存パッケージを操作します。
- 両方とも動作したら、依存パッケージを公開します。
- その依存パッケージを指すようにpubspecを変更します。
- 必要に応じてメインパッケージも公開します。
SDK
#SDKソースは、パッケージと一緒に配布されるSDK（それ自体が依存関係である可能性がある）に使用されます。現在、サポートされているSDKはFlutterのみです。
構文は次のようになります。
dependencies:
flutter_driver:
sdk: fluttersdk:の後の識別子は、パッケージがどのSDKから提供されるのかを示します。それがflutterの場合、依存関係は次の場合に満たされます。
- Pubが
flutter実行可能ファイルのコンテキストで実行されている - Flutter SDKに、指定された名前のパッケージが含まれている
未知の識別子の場合、依存関係は常に満たされていないと見なされます。
バージョン制約
#パッケージAがパッケージBに依存しているとします。パッケージAの特定のバージョンと互換性のあるパッケージBのバージョンを他の開発者にどのように伝えられますか？
開発者にバージョン互換性を知らせるには、バージョン制約を指定します。パッケージユーザーに柔軟性を提供するために、可能な限り幅広いバージョンの範囲を許可したいと考えます。その範囲には、動作しないバージョンまたはテストされていないバージョンを含めないようにする必要があります。
Dartコミュニティはセマンティックバージョニング1を使用しています。
Dart 2.19以降、バージョン制約は従来の構文またはキャレット構文のいずれかを使用して表現できます。どちらの構文も、互換性のあるバージョンの範囲を指定します。
従来の構文では、'>=1.2.3 <2.0.0'のように明示的な範囲を指定します。キャレット構文では、^1.2.3のように明示的な開始バージョンを指定します。
environment:
# This package must use a 3.x version of the Dart SDK starting with 3.2.
sdk: ^3.2.0
dependencies:
transmogrify:
hosted:
name: transmogrify
url: https://some-package-server.com
# This package must use a 1.x version of transmogrify starting with 1.4.
version: ^1.4.0pubのバージョン管理システムの詳細については、パッケージのバージョン管理ページを参照してください。
従来の構文
#従来の構文を使用するバージョン制約では、以下のいずれかの値を使用できます。
| 値 | 許可されるバージョン | 使用例？ | 備考 |
|---|---|---|---|
any | すべてのバージョン | いいえ | 空のバージョン制約を明示的に宣言する場合に使用します。 |
1.2.3 | 指定されたバージョンのみ | いいえ | パッケージを使用するアプリに追加の制限を加えるため、パッケージの採用が制限されます。 |
>=1.2.3 | 指定されたバージョン以降 | はい | |
>1.2.3 | 指定されたバージョンより後のバージョン | いいえ | |
<=1.2.3 | 指定されたバージョン以前 | いいえ | |
<1.2.3 | 指定されたバージョンより前のバージョン | いいえ | パッケージと互換性がない上限バージョンがわかっている場合に使用します。このバージョンは、破壊的な変更が初めて導入されたバージョンかもしれません。 |
バージョン値の任意の組み合わせを指定でき、それらの範囲が交差します。たとえば、バージョン値を'>=1.2.3 <2.0.0'に設定すると、両方の制限が組み合わされ、依存関係は1.2.3から2.0.0（2.0.0自体は除く）までの任意のバージョンになります。
キャレット構文
#キャレット構文は、バージョン制約をコンパクトな方法で表現します。^versionは、*指定されたバージョンと下位互換性が保証されているすべてのバージョンの範囲*を意味します。この範囲には、破壊的な変更が導入される次のバージョンまでのすべてのバージョンが含まれます。Dartはセマンティックバージョニングを使用するため、これは1.0以降のパッケージバージョンでは次のメジャーバージョン、1.0より前のパッケージバージョンでは次のマイナーバージョンになります。
| バージョン値 | 範囲（～まで） | キャレット構文 | 従来の構文 |
|---|---|---|---|
| >=1.0 | 次のメジャーバージョン | ^1.3.0 | '>=1.3.0 <2.0.0' |
| <1.0 | 次のマイナーバージョン | ^0.1.2 | '>=0.1.2 <0.2.0' |
次の例は、キャレット構文を示しています。
dependencies:
# Covers all versions from 1.3.0 to 1.y.z, not including 2.0.0
path: ^1.3.0
# Covers all versions from 1.1.0 to 1.y.z, not including 2.0.0
collection: ^1.1.0
# Covers all versions from 0.1.2 to 0.1.z, not including 0.2.0
string_scanner: ^0.1.2開発依存関係
#Pubは、通常の依存関係と開発用依存関係の2種類の依存関係をサポートしています。開発用依存関係は、通常の依存関係とは異なり、*依存しているパッケージの開発用依存関係は無視されます*。例を以下に示します。
transmogrifyパッケージがテストでのみtestパッケージを使用しているとします。transmogrifyを使用するだけで（ライブラリをインポートするだけ）testは実際には必要ありません。この場合、testを開発用依存関係として指定します。そのpubspecには次のような記述があります。
dev_dependencies:
test: ^1.25.0Pubは、パッケージが依存しているすべてのパッケージとそのパッケージが依存しているすべてのパッケージを推移的に取得します。また、パッケージの開発用依存関係も取得しますが、依存パッケージの開発用依存関係は無視します。Pubはパッケージ自身の開発用依存関係のみを取得します。そのため、パッケージがtransmogrifyに依存している場合、transmogrifyは取得されますが、testは取得されません。
通常の依存関係と開発用依存関係のどちらを選択するかのルールは簡単です。依存関係がlibまたはbinディレクトリの何かからインポートされている場合は、通常の依存関係である必要があります。test、exampleなどからのみインポートされている場合は、開発用依存関係にすることができますし、そうする必要があります。
開発用依存関係を使用すると、依存関係グラフが小さくなります。これにより、pubの実行速度が向上し、すべての制約を満たすパッケージバージョンのセットを見つけやすくなります。
依存関係の上書き
#dependency_overridesを使用して、依存関係へのすべての参照を一時的にオーバーライドできます。
たとえば、公開されたパッケージであるtransmogrifyのローカルコピーを更新しているとします。Transmogrifyは依存関係グラフ内の他のパッケージで使用されていますが、各パッケージをローカルに複製して、ローカルコピーのtransmogrifyをテストするために各pubspecを変更する必要はありません。
この状況では、dependency_overridesを使用して、パッケージのローカルコピーを含むディレクトリを指定することで、依存関係をオーバーライドできます。
pubspecは次のようになります。
name: my_app
dependencies:
transmogrify: ^1.2.0
dependency_overrides:
transmogrify:
path: ../transmogrify_patch/dart pub getまたはdart pub upgradeを実行すると、pubspecのlockfileが依存関係への新しいパスを反映するように更新され、transmogrifyが使用されている場所では、pubはローカルバージョンを使用します。
dependency_overridesを使用して、パッケージの特定のバージョンを指定することもできます。
name: my_app
dependencies:
transmogrify: ^1.2.0
dependency_overrides:
transmogrify: '3.2.1'パッケージの解決中に考慮されるのは、**パッケージ自身のpubspec内にある依存関係のオーバーライドのみ**です。依存パッケージ内の依存関係のオーバーライドは無視されます。
その結果、パッケージをpub.devに公開する場合は、パッケージの依存関係のオーバーライドは、パッケージのすべてのユーザーによって無視されることに注意してください。
ベストプラクティス
#依存関係の管理を積極的に行いましょう。可能であれば、パッケージは常に最新のバージョンに依存するようにしてください。パッケージが古いパッケージに依存している場合、その古いパッケージは依存関係ツリー内の他の古いパッケージに依存している可能性があります。古いバージョンのパッケージは、アプリの安定性、パフォーマンス、品質に悪影響を与える可能性があります。
パッケージの依存関係に関する推奨されるベストプラクティスを次に示します。
キャレット構文を使用する
#キャレット構文を使用して依存関係を指定します。これにより、pubツールは、新しいバージョンが利用可能になったときに、パッケージの新しいバージョンを選択できます。さらに、許可されるバージョンの上限を設定します。
最新の安定版パッケージバージョンに依存する
#dart pub upgradeを使用して、pubspecで許可されている最新のパッケージバージョンに更新します。アプリまたはパッケージで最新安定バージョンではない依存関係を特定するには、dart pub outdatedを使用します。
開発依存関係のバージョン制約を厳しくする
#開発用依存関係は、開発時にのみ必要なパッケージを定義します。完成したアプリでは、これらのパッケージは必要ありません。これらのパッケージの例としては、テストやコード生成ツールなどがあります。dev_dependenciesのパッケージのバージョン制約は、パッケージが依存する最新バージョンの下限を設定するようにします。
開発用依存関係のバージョン制約を厳しくすると、次のようになります。
dev_dependencies:
build_runner: ^2.4.12
lints: ^2.1.1
test: ^1.25.8このYAMLは、dev_dependenciesを最新のPatchバージョンに設定します。
パッケージ依存関係を更新するたびにテストする
#dart pub upgradeをpubspecを更新せずに実行した場合、APIは同じままで、コードは以前と同様に実行されるはずです。ただし、確実に動作することをテストしてください。pubspecを変更して新しいメジャーバージョンに更新した場合は、破壊的な変更が発生する可能性があるため、さらに徹底的にテストする必要があります。
ダウングレードされた依存関係でテストする
#公開するパッケージを開発する際には、可能な限り広い依存関係制約を許可するのが好ましいことがよくあります。依存関係制約を広げると、パッケージの利用者がバージョン解決の競合に直面する可能性が低くなります。
たとえば、foo: ^1.2.3に依存していて、fooのバージョン1.3.0がリリースされた場合、既存の依存関係制約（^1.2.3）を維持しても問題ありません。しかし、パッケージが1.3.0に追加された機能を使用し始めた場合は、制約を^1.3.0に上げる必要があります。
ただし、必要になったときに依存関係制約を上げるのを忘れることは簡単です。そのため、公開する前に、ダウングレードされた依存関係に対してパッケージをテストすることをベストプラクティスとしています。
ダウングレードされた依存関係に対してテストするには、dart pub downgradeを実行し、パッケージがエラーなく解析され、すべてのテストに合格することを確認します。
dart pub downgrade
dart analyze
dart testダウングレードされた依存関係を使用したテストは、最新の依存関係を使用した通常のテストと並行して行う必要があります。依存関係制約を上げる必要がある場合は、自分で変更するか、dart pub upgrade --tightenを使用して依存関係を最新バージョンに更新します。
ダウンロードされたパッケージの整合性を確認する
#新しい依存関係を取得する際には、--enforce-lockfileオプションを使用して、抽出されたパッケージの内容が元のアーカイブの内容と一致することを確認します。lockfileを変更せずに、このフラグは次の場合にのみ新しい依存関係を解決します。
pubspec.yamlが満たされているpubspec.lockが存在する- パッケージのコンテンツハッシュが一致する
特に明記されていない限り、このサイトのドキュメントはDart 3.5.3を反映しています。ページは2024年9月16日に最後に更新されました。ソースコードを見る または 問題を報告する。