Sencha CmdにはSencha Package Managerが含まれます。パッケージは、消費および配布という2つの基本的問題を解決するよう設計されています。このガイドではこれらのテーマを主に取り上げます。パッケージの作成と共有については、Sencha Cmdパッケージの作成をご覧ください。
"packages"フォルダ
Sencha Cmdで作成されるワークスペースはすべて、ルートに"packages"フォルダがあります。このフォルダの場所は設定できますが、どの場所にあっても、"packages"フォルダの役割はそのワークスペースでアプリケーション（または他のパッケージ）が使用するすべてのパッケージのストレージとして機能することです。
パッケージは、ワークスペースでアプリケーションに要求されるか、sencha generate packageを呼び出すと、"packages"フォルダに追加されます。
アプリケーションでパッケージを要求する
パッケージの元の位置に関わらず（後述のようにローカルで作成されたかリモートリポジトリからダウンロードされたかに関わらず）、パッケージの消費の仕方は同じで、"app.json"のrequires配列にエントリを追加します。デモンストレーションのため、実験できるシンプルなパッケージを追加しました。
{
"name": "MyApp",
"requires": [
"ext-easy-button"
]
}上の要求を与えられると、sencha app buildおよびsencha app refreshはともにアプリケーションにパッケージを統合するためのステップを実行します。通常、パッケージ要求の変更後はsencha app refreshを実行して、「dev mode」をサポートするために必要なメタデータを最新にする必要があります。
いずれのコマンドを実行しても、Sencha Cmdはパッケージを"packages"フォルダにダウンロードし展開します。この後、ワークスペースに"packages/ext-easy-button"フォルダができています。
ローカルパッケージ
パッケージの1つの使い方には、ワークスペースで複数のアプリケーションが使用できるコードまたはテーマを単に保持することがあります。こうしたパッケージは（ソースコントロールに隠れて）開発に値を提供するために配布されることはありません。
Sencha Cmdの旧リリースでは、.sencha/workspace/sencha.cfg"ファイルのworkspace.classpathプロパティを使ってのみワークスペースでコードを共有することができました。これはまだ機能しますが、Sass/CSSスタイルや画像などのリソースを簡単に共有できないため、このメカニズムには限界がありました。パッケージを使うと、これらの作業がすべて可能です。
ワークスペースにパッケージを追加するには、単にパッケージを作成するだけです。
sencha generate package -type code commonパッケージはその"package.json"でlocal: trueとマークされます。このフラグは、Sencha Cmdがリモートリポジトリにあるバージョンでパッケージを上書きしないようにするためのものです（下記参照）。
それから次のように、アプリケーションの"app.json"に要求として「common」を加えます。
{
"name": "MyApp",
"requires": [
"common"
]
}詳細、特にパッケージを他者に配布する方法については、Sencha Cmdパッケージの作成をご覧ください。
リモートパッケージ
大規模なアプリケーションではローカルパッケージが非常に役立ちますが、パッケージの最も便利な点は、他者が消費するようパッケージを配布できることです。実際に、ここでも"ext-easy-button"というリモートパッケージを使用しています。
パッケージはパッケージリポジトリを使って共有および配布されます。Sencha Cmdは、パッケージをキャッシュし公開するための「ローカルリポジトリ」を自動的に作成します。パッケージ作成におけるローカルリポジトリの役割は、このガイドでは取り上げません。そのテーマについては、Sencha Cmdパッケージの作成をご覧ください。
ローカルリポジトリ
多くの動作が、上の"ext-easy-button"の例のようなローカルリポジトリを黙示的に使っています。例では、Sencha Cmdは"app.json"でrequires文を見つけると次の基本ステップを実行しました。
- ワークスペース内にパッケージがすでに存在するかどうか確認する。
- ローカルリポジトリにすでにダウンロードされたバージョンがあるかどうか確認する。
- 定義済みのリモートリポジトリのセットのいずれかがパッケージを持つかどうか確認する。
- リモートリポジトリからパッケージをダウンロードし、ローカルリポジトリに追加する。
パッケージが一度ダウンロードされると、以降のこのパッケージの要求はダウンロードを要求しなくなります。パッケージはローカルリポジトリに入れられています。
ローカルリポジトリの場所
ローカルリポジトリは、様々なバージョンフォルダの「そばに」作成され、キャッシュを容易にします。例えば、Windows上のSencha Cmdのデフォルトのインストールディレクトリは、ユーザーFooの場合、次のようになります。
C:\Users\Foo\bin\Sencha\Cmd\n.n.n.nそのインストールディレクトリを与えられると、ローカルリポジトリの場所は次になります。
C:\Users\Foo\bin\Sencha\Cmd\repoこれはSencha Cmdのインストールフォルダ内の"sencha.cfg"を編集すると変更できます。
ローカルリポジトリの内容については、詳しくはSencha Cmdパッケージの作成で説明しています。
リモートリポジトリ
パッケージをローカルリポジトリにダウンロードするためには、Sencha Cmdはリモートリポジトリを認識しなくてはなりません。デフォルトでは、Sencha CmdはSencha Package Repositoryを「sencha」という名前のリモートリポジトリとして追加します。
リモートリポジトリのリストを見るためには、sencha repository listコマンドを実行してください。
> sencha repository list
Sencha Cmd vn.n.n.xxx
[INF] Remote repository connections (1):
[INF]
[INF] sencha - http://cdn.sencha.com/cmd/packages/このリストから、sencha repository addおよびsencha repository removeコマンドを使ってリモートリポジトリを追加したり削除したりできます。ローカルリポジトリは、ホストすることを選んだ場合、実際には他者に利用できるリモートリポジトリになります。これについては、Sencha Cmdパッケージの作成をご覧ください。
パッケージのカタログ
使用できるパッケージセットは「catalog」にリスト化されています。次のコマンドを使ってグローバルカタログの内容を表示できます。
sencha package listパッケージを一覧にすると、リストが名前とバージョンを含むことがわかります。
名前の割り当て
Sencha Cmdのリポジトリ管理が配布され、リモートリポジトリを適切に追加または削除できるため、パッケージのユニバーサル名前空間はありません。Sencha Package Repositoryに対してデフォルトの「sencha」による接続を維持する場合、命名規則としてリポジトリの内容を見ることができます。
Senchaが公開するパッケージは次の形式の名前を使います。
- sencha-*
- ext-*
- touch-*
- cmd-*
上の接頭辞で始まるパッケージ名はすべて、SenchaがSencha Package Repositoryに対して維持します。Sencha Package Repositoryと接続していない場合も、これらの名前を競合させないようにすることをお勧めします。
バージョン管理
パッケージとその消費者（つまりアプリケーションか他のパッケージ）を接続するには、関連するバージョンの検討が重要です。これを管理しやすくするため、すべてのパッケージはrequires文が使用するバージョン番号を持ち、バージョン制限を処理します。
パッケージのバージョン割り当て
すべてのパッケージは名前とバージョンの組み合わせで記述されています。しかしパッケージの各バージョンには、下位互換性レベルを記述する別のバージョン番号もあります。このバージョンは、パッケージ作成者が、パッケージの特定バージョンが、ある特定の旧バージョンレベルと下位互換性があると考えることを宣言するものです。
"package.json"ディスクリプタには、2つの重要なプロパティがあります。versionおよびcompatVersionです。例：
{
...
"version": "n.n.n",
"compatVersion": "2.4.2",
...
}この番号は次のフォーマットでなくてはなりません。
\d+(\.\d+)*バージョン制限
上のrequiresプロパティを使用するとき、パッケージ名のみを指定して、例をできるだけシンプルにしました。正確には「最新バージョン」を指します。これがうまくいく場合もありますが、パッケージの次のリリースが完全な再設計で下位互換性がない場合はリスクのある要求です。
この事態からアプリケーションを保護するため、require文を変更して制限を強め、希望するバージョン番号をロックダウンすることができます。
{
"name": "MyApp",
"requires": [
"[email protected]"
]
}このやり方には良いところもありますが、パッケージのメンテナンスリリースさえもピックアップが制限されてしまいます。プロジェクトの最終段階ではこれがまさに適切ですが、開発中には制限を緩め互換バージョンを許容したい場合がおそらくあるでしょう。
それには、次の変更を行います。
{
"name": "MyApp",
"requires": [
"[email protected]?"
]
}上記はバージョン 1.0 と下位互換性のある "ext-easy-button" の最新バージョンをリクエストします。
バージョン照合を制限する別の方法には次があります。
- -1.2（下位制限なしでバージョン1.2まで)
- 1.0-（上位制限なしでバージョン1.0以上）
- 1.0+（上と同じでバージョン1.0以上）
- 1.0-1.2（バージョン1.0から1.2までで1.2を含む）
- 1.0-1.2?（1.0から1.2までで1.2を含むバージョンと互換性がある）
バージョンの解決
希望する利用可能バージョンがすべて与えられると、Sencha Cmdは適合パッケージの最適なセットを決定し、これらがワークスペースにある状態を確保します。
相互排他的な要求がある場合、このプロセスは失敗することがあります。この場合、どの要求が満たされなかったのかを説明するエラーメッセージが現れます。