SharePoint Framework ツールチェーン
SharePoint Framework ツールチェーンは、クライアント側のプロジェクトの構築と展開を管理する一連のビルド ツール、フレームワークのパッケージ、その他のアイテムです。
ツールチェーンによって、
- Web パーツのようなクライアント側のコンポーネントを構築することができます。
- SharePoint ワークベンチなどのツールを使用して、ローカル開発環境でクライアント側コンポーネントをテストすることもできます。
- パッケージ化して、SharePoint に展開することもできます。
- 一連のビルド コマンドを使用して、コードのコンパイルなどの主要なビルド タスクを完了することができ、クライアント側のプロジェクトを SharePoint アプリのパッケージなどにまとめることができます。
重要
ローカル ワークベンチは Internet Explorer 11 の使用をサポートしていません。
npm パッケージを使用する
さまざまなツール チェーンのコンポーネントについて説明する前に、SharePoint Framework が npm を使用してプロジェクト内の異なるモジュールを管理する方法についての理解が重要となります。 npm は、JavaScript のクライアント側開発に適したオープンソースのパッケージ マネージャーの 1 つです。
通常の npm パッケージは、依存パッケージのリストに加えて、モジュールと呼ばれる 1 つまたは複数の再利用可能な JavaScript コード ファイルで構成されています。 パッケージをインストールすると、npm により、それらの依存関係もインストールされます。
公式 npm レジストリは、何百ものパッケージで構成されており、ダウンロードして、アプリケーションを構築することができます。 npm に独自のパッケージを発行して他の開発者と共有することもできます。 SharePoint Framework は、ツールチェーン中で npm のパッケージの一部を使用し、npm レジストリへ独自のパッケージを発行します。
SharePoint Framework のパッケージ
SharePoint Framework は、いくつかの npm パッケージで構成されます。これらのパッケージは、SharePoint 内でクライアント側のエクスペリエンスを構築できるよう連携して動作します。
SharePoint Framework には、次の npm パッケージがあります。
- @microsoft/generator-sharepoint SharePoint Framework と共に使用する Yeoman のプラグイン。 このジェネレーターを使用して、開発者は実用的な既定値とベスト プラクティスを備えた新しいクライアント側の Web パーツ プロジェクトを迅速に設定することができます。
- @microsoft/sp-client-base。 SharePoint Framework を使用して作成されたクライアント側のアプリケーションの中核となるライブラリを定義します。
- @microsoft/sp-webpart-workbench。 SharePoint ワークベンチは、クライアント側の Web パーツをテストしデバッグするスタンドアロンの環境です。
- @microsoft/sp-module-loader。 クライアント側のコンポーネント、Web パーツ、その他のアセットのバージョン管理と読み込みを管理するモジュール ローダーです。 また、基本的な診断サービスを提供します。 SystemJS や WebPack などの一般的な標準に基づいており、ページに読み込む SharePoint Framework の最初の部分となります。
- @microsoft/sp-module-interfaces。 SharePoint Framework モジュール ローダーとビルド システムでも共有されているいくつかのモジュールのインタ フェースを定義します。
- @microsoft/sp-lodash-subset。 SharePoint Framework のモジュール ローダーと共に使用する lodash のカスタム バンドルを提供します。 ランタイム パフォーマンスを向上させるため、最も重要な lodash 機能のサブセットだけが含まれています。
- @microsoft/sp-tslint-rules。 SharePoint のクライアント側プロジェクトで使用する tslint のカスタム ルールを定義します。
- @microsoft/office-ui-fabric-react-bundle。 SharePoint Framework のモジュール ローダーと合わせて使用するために最適化された office-ui-fabric-react のカスタム バンドルを提供します。
共通のビルド ツール パッケージ
TypeScript コードを JavaScript にコンパイルしたり、SCSS を CSS に変換したりするなどのビルド タスクの実行には、SharePoint Framework パッケージと共に、共通のビルド ツール セットが使用されます。
SharePoint Framework には、次の共通の npm ビルド ツール パッケージがあります。
- @microsoft/sp-build-core-tasks。 SharePoint Framework のビルド システム用のタスク コレクションで、gulp に基づいています。 sp-build-core-tasks パッケージは、パッケージング ソリューションやマニフェストの作成などの SharePoint 固有の処理を実装します。
- @microsoft/sp-build-web。 (Node.js 環境ではなく) Web ブラウザーで実行されるビルド ターゲットに適切な一連のビルド タスクをインポートし、構成します。 このパッケージは、SharePoint Framework ビルド システムを使用する gulp ファイルによって直接インポートされることを想定しています。
- @microsoft/gulp-core-build。 TypeScript、HTML、less、その他のビルド形式を構築するコア gulp ビルド タスク。 このパッケージは、次のタスクを含む他のいくつかの npm パッケージに依存します。
- @microsoft/gulp-core-build-typescript
- @microsoft/gulp-core-build-sass
- @microsoft/gulp-core-build-webpack
- @microsoft/gulp-core-build-serve
- @microsoft/gulp-core-build-karma
- @microsoft/gulp-core-build-mocha@microsoft/loader-cased-file。 webpack の file-loader 用ラッパーで、結果生じるファイル名の大文字と小文字を変更するのに使用することができます。 これは、小文字のファイル名のみを許可するコンテンツ配信ネットワーク (CDN) を使用する場合など、一部のシナリオで役立ちます。
- @microsoft/loader-load-themed-styles。
require('load-themed-styles').loadStyles( /* css text */ )と同等のスクリプトで CSS の読み込みをラップするローダー。 style-loader の代わりとして設計されています。 - @microsoft/loader-raw-script。
eval(…)を使用する webpack バンドルに直接スクリプト ファイルのコンテンツを読み込むローダー。 - @microsoft/loader-set-webpack-public-path。 引数で指定された値に webpack_public_path の変数を設定するローダーで、任意で SystemJs baseURL のプロパティに追加します。
新しいクライアント側のプロジェクトのスキャフォールディング
SharePoint のジェネレーターでは、クライアント側の Web パーツのあるプロジェクトをスキャフォールディングします。 またジェネレーターは指定されたクライアント側のプロジェクトの必要なツール チェーンのコンポーネントをダウンロードし構成します。
npm パッケージをインストールする
ジェネレーターは、必要な npm パッケージをプロジェクト フォルダーにローカルにインストールします。 npm では、パッケージをプロジェクトに対してローカルにインストールすることも、グローバルにインストールすることもできます。 双方にメリットがありますが、一般的なガイダンスとして、コードがこれらのパッケージ モジュールに依存している場合、npm のパッケージをローカルにインストールします。 Web パーツ プロジェクトの場合、Web パーツのコードはさまざまな SharePoint と共通のビルド パッケージに依存しているため、これらのパッケージをローカルにインストールする必要があります。
パッケージがローカルにインストールされていると、npm は各パッケージに関連付けられている依存関係もインストールします。 プロジェクト フォルダー内の node_modules フォルダーにインストールされたパッケージを見つけることができます。 このフォルダーには、パッケージとそのすべての依存関係が含まれています。 npm のパッケージは常に小さなモジュールに分割されており、数十から数百のフォルダーがインストールされるため、このフォルダーには数十から数百のフォルダーが含まれていることが理想的です。 キー SharePoint Framework パッケージは、node_modules@microsoft フォルダーの下にあります。 @microsoftは、Microsoft によって発行されたパッケージをまとめて表す npm スコープです。
ジェネレーターを使用して新しいプロジェクトを作成するたびに、ジェネレーターはローカルにその特定のプロジェクトの依存関係と共に SharePoint Framework パッケージをローカルにインストールします。 このように npm を使用すると、ローカル開発環境の他のプロジェクトに影響を与えることなく、Web パーツ プロジェクトを簡単に管理できます。
package.json で依存関係を指定する
クライアント側のプロジェクトの package.json ファイルは、プロジェクトが依存する依存関係の一覧を特定します。 一覧では、インストールする依存関係が定義されています。 前述のように、それぞれの依存関係にはさらにいくつかの依存関係が含まれることがあります。 npm では、dependencies および devDependencies のプロパティを使用して、パッケージのランタイムおよびビルドの依存関係の両方を定義できます。 Web パーツを構築する場合に、コード内でそのモジュールを使用したいとき、devDependencies プロパティを使用します。
以下は、helloworld-webpart の package.json です。
{
"name": "helloword-webpart",
"version": "0.0.1",
"private": true,
"engines": {
"node": ">=0.10.0"
},
"dependencies": {
"@microsoft/sp-client-base": "~1.0.0",
"@microsoft/sp-core-library": "~1.0.0",
"@microsoft/sp-webpart-base": "~1.0.0",
"@types/webpack-env": ">=1.12.1 <1.14.0"
},
"devDependencies": {
"@microsoft/sp-build-web": "~1.0.0",
"@microsoft/sp-module-interfaces": "~1.0.0",
"@microsoft/sp-webpart-workbench": "~1.0.0",
"gulp": "~3.9.1",
"@types/chai": ">=3.4.34 <3.6.0",
"@types/mocha": ">=2.2.33 <2.6.0"
},
"scripts": {
"build": "gulp bundle",
"clean": "gulp clean",
"test": "gulp test"
}
}
このプロジェクト用に多くのパッケージがインストールされていますが、これらは開発環境で Web パーツの構築のみに必要とされます。 これらのパッケージの力を借りて、モジュールに依存し、Web パーツをビルド、コンパイル、バンドル、およびパッケージ化して展開することができます。 CDN サーバーや SharePoint に展開する縮小されたバンドル化 Web パーツの最終バージョンには、これらのパッケージのいずれも含まれていません。 しかしながら、ユーザーの要件に応じて、特定のモジュールを含むように構成することもできます。 詳細については、「外部ライブラリを Web パーツに追加する」参照してください。
ソース管理システムを使用する
プロジェクトの依存関係が増えると、インストールするパッケージ数も増加します。 すべての依存関係を含む node_modules フォルダーを、ソース管理システムにチェックインするのは好ましくありません。 ファイルの一覧から node_modules を除外して、チェックイン時に無視する必要があります。
git をソース管理システムとして使用している場合、Yeoman のスキャフォールディング Web パーツ プロジェクトには、node_modules フォルダーやその他を除外した .gitignore ファイルが含まれています。
初めてソース管理システムから Web パーツ プロジェクトチェック アウトやクローン作成を行う場合、コマンドを実行して、プロジェクトの依存関係すべてをローカルに初期化しインストールしてください。
npm install
コマンドを実行した後、nmp は package.json ファイルをスキャンし、必要な依存関係をインストールします。
開発者情報を更新する
バージョン1.11 以降、package-solution.json ファイルで定義されたソリューションマニフェストが拡張されdeveloper、組織に関する追加情報を保存できるセクションが追加されました。 このソリューションを marketplace に発行すると、このセクションの情報が検証されます。 内部使用のためのソリューションを構築している場合でも、ソリューションマニフェストの別のプロパティを入力することをお勧めします。 この情報を指定すると、将来アプリケーションの使用状況に関する追加の分析情報にアクセスすることができる可能性があります。
重要
Microsoft Teams に Web パーツを表示するように選択した場合、developerアプリをチームにインストールすると、セクションの情報がユーザーに表示されます。
重要
開発セクションは、Office ストアまたは AppSource から入手できる SharePoint Framework ソリューションの有効な情報を含める必要があります。
developer セクションの一部として、次のプロパティを使用できます：
| 属性 | 説明 | 必須 |
|---|---|---|
name |
アプリケーションを構築した組織名 | はい |
websiteUrl |
アプリケーションに関する追加情報が記載された Web サイトの URL | はい |
mpnId |
Microsoft Partner Network ID (MS パートナーネットワーク の詳細情報) | いいえ (ただし、提供することを強くお勧めします) |
privacyUrl |
プライバシーに関する声明の URL | はい |
termsOfUseUrl |
使用条件の URL | はい |
ビルド タスク
SharePoint Framework では、gulp をそのタスク ランナーとして使用して、次のようなプロセスを処理します。
- JavaScript と CSS ファイルをバンドルし、縮小します。
- ツールを実行して、各ビルドの前にバンドル化タスクと縮小タスクを呼び出します。
- LESS または Sass ファイルを CSS にコンパイルします。
- TypeScript ファイルを JavaScript にコンパイルします。
ツールチェーンは、@microsoft/sp-build-core-tasks のパッケージで定義されている次の gulp タスクで構成されています。
- build - クライアント側のソリューション プロジェクトをビルドします。
- bundle - クライアント側のソリューション プロジェクトのエントリ ポイントとそのすべての依存関係を 1 つの JavaScript ファイルにバンドルします。
- serve - クライアント側のソリューション プロジェクトとローカル マシンからのアセットを提供します。
- clean - 以前のビルドとビルド ターゲット ディレクトリ (lib と dist) からクライアント側のソリューション プロジェクトのビルド成果物をクリーンアップします。
- test - 可能な場合、クライアント側のソリューション プロジェクトの単体テストを実行します。
- package-solution - クライアント側のソリューションを SharePoint パッケージにパッケージ化します。
- deploy-azure-storage - Azure ストレージにクライアント側のソリューション プロジェクトのアセットを展開します。
さまざまなタスクを開始するには、gulp コマンドを使用してタスク名を追加します。 たとえば、SharePoint のワークベンチに Web パーツをコンパイルしプレビューするには、次のコマンドを実行します。
gulp serve
注:
同時に複数のタスクを実行することはできません。
serve タスクはさまざまなタスクを実行し、最後に SharePoint ワークベンチを起動します。
ビルド ターゲット
前のスクリーンショットで、タスクが、次のようにビルド ターゲットを示しているのを確認できます。
Build target: DEBUG
パラメーターが指定されていない場合、コマンドは BUILD モードを対象とします。 ship パラメーターが指定されている場合、コマンドは SHIP モードを対象とします。
通常、Web パーツ プロジェクトの出荷または運用サーバーに展開する準備ができると、SHIP を対象とします。 テストおよびデバッグのような他のシナリオでは、BUILD を対象とします。 対象が SHIP の場合、Web パーツのバンドルの縮小版が構築されていることも保証します。
SHIP モードを対象とするには、タスクに --ship を追加します。
gulp --ship
DEBUG モードでは、ビルド タスクは Web パーツのバンドルを含むすべて Web パーツ アセットを dist フォルダーにコピーします。
SHIP モードでは、ビルド タスクは Web パーツのバンドルを含むすべての Web パーツ アセットを temp\deploy フォルダーにコピーします。