次の方法で共有


Dynamics 365 Commerce オンライン SDK に関するよくあるご質問

この記事では、Dynamics 365 Commerce オンライン ソフトウェア開発キット (SDK) のユーザーにより頻繁に寄せられる質問とその回答をまとめています。

Node.ec のバージョンに互換性がないために、eコマース拡張パッケージのビルドに失敗するのはなぜですか?

オンライン SDK パッケージのバージョン 1.37 以降に更新した場合、バージョン 1.37 は Node.to バージョン 16.x をサポートするよう更新されたため、ノード バージョン12.x を使用している場合は、ビルドが中断される可能性があります。 次のエラー メッセージが表示されます:

The engine "node" is incompatible with this module. Expected version ">=16.x.x". Got "12.22.6".

この問題を解決するには、ローカルビルド環境および Azure DevOps パイプラインなどの任意の自動ビルド環境で、Node.exe をバージョン 16.x に更新する必要があります。

頻繁にメモリ不足のエラーが起こるのはどうしたらよいですか?

オンライン SDK のビルド時に頻繁にメモリ不足のエラーが発生する場合、コードに不正なインポートがある可能性があります。 パスが正しく設定されるように、ビュー拡張、コンポーネントの上書き、モジュールの複製などのカスタマイズを作成するために、オンライン SDK に含まれる CLI ツールを使用することをお勧めします。

node_modules ディレクトリに存在するモジュールからのインポートは、常に名前空間とモジュール名に対して行う必要があります。 モジュールの src フォルダーから絶対パスで任意のモジュールをインポートすると、ビルド プロセスがループに実行され、頻繁なメモリ不足エラーにつながる可能性があります。

次の例では、インポート可能なコンポーネントのすべてが既にモジュールによりエクスポート済みであるため、無効なインポートを示しています。

import { IHeaderViewProps } from '@msdyn365-commerce-modules/header/src/header';

次の例では、有効なインポートを示しています。

import { IHeaderViewProps } from '@msdyn365-commerce-modules/header';

ノード メモリ サイズを増やす方法は?

既定のメモリ設定は、ほとんどのカスタマイズ シナリオに十分対応できます。 ただし、アプリケーションにより多くの領域が必要な場合は、次の例に示すように、--max_old_space_size=4096 を追加することで、package.json ファイルのスクリプト セクションで環境変数を指定できます:

"build": "SET NODE_OPTIONS=--max_old_space_size=4096 && yarn msdyn365b build --use-eslint",

ノード アプリのキャッシュをクリアできますか?

はい。 Commerce サイト ビルダーでノード アプリのキャッシュをクリアするには、サイト設定 > 拡張機能を選択し、コンフィギュレーション タブを選択し、キャッシュ キー接尾語設定値の値を任意のランダム文字 ("xyz" など) に更新します。 値を更新するとノード アプリのキャッシュがクリアされます。

パッケージのアップロード中に、このエラー メッセージが表示されます: "eコマース パッケージのオンライン SDK が期限切れです。 新しいパッケージを作成し、展開をやり直してください。" または、パッケージ展開中にこのエラー メッセージが表示されます: "オンライン SDK が期限切れているため、eコマース パッケージを展開できません。 新しいパッケージを作成して、展開をやり直してください。" なぜでしょうか?

パッケージの展開中に展開時間を削減するため、最新のオンライン SDK を使用してyarn msdyn365 packコマンドライン インターフェイス (CLI) コマンドが実行されている間に、アップロード済のパッケージが再構築されます。 パッケージのアップロードが失敗し、エラー メッセージの 1 つが表示された場合は、yarn msdyn365 update-versions sdk CLI コマンドを使用して最新の SDK に更新します。 この方法により、最新のオンライン SDK をプルダウンするよう yarn を実行する前に、yarn.lock ファイルが削除されていることを確認します。 その後、yarn msdyn365 pack コマンドを使用してパッケージを再構築してから、新しいパッケージを再展開できます。

Webpack 5 を使用して Commerce アプリケーションをバンドルするようオプトインできますか?

Dynamics 365 Commerce オンライン SDK では、最新の Webpack 5 リリースを使用して Commerce アプリケーションをバンドルするようサポートしています。 Webpack 5 ではツリーの揺れやコード生成がと共にバンドルが改良され、ページでダウンロードおよび処理される JavaScript の量を削減するのに役立ちます。

オンライン SDK のバージョン 1.32 (Commerce バージョン 10.0.22) リリースでは、Webpack 5 に対してオプトインできます。 バージョン 1.34 (Commerce バージョン 10.0.24) リリースでは、Webpack 5 が既定オプションになり、オプトインは必要ありません。

yarn msdyn365 upgrade-webpack コマンドを実行することで、Webpack 5 を有効にできます。 このコマンドでは、Webpack 5 に必要な依存関係の一覧を使用して package.json ファイルが更新されます。 package.json ファイルを更新した後、yarn コマンドを実行して新しい依存関係をインストールできます。 次の例は、2 つのコマンドを示しています。

yarn msdyn365 upgrade-webpack

yarn

サーバー側モジュールのエラーをより明確にするには?

Dynamics 365 Commerce オンライン SDK のバージョン 1.3 では、開発環境で表示されるモジュール数が変更されました。 モジュールの開発中に、モジュールをサーバー側とクライアント側の両方で表示できます。 サーバー側でモジュールが失敗した場合、クライアント側でもモジュールが実行されているため、これらの失敗がマスクされ、検出するのが困難になります。

サーバー側のエラーをより明確にするため、オンライン SDK のバージョン 1.31 ではエラー メッセージが生成されます。 このメッセージでは、サーバーでのモジュール表示中に問題が発生し、モジュールを開発環境で正常に表示する前に対処する必要があることを示しています。 この検証は、開発環境でのみ行われます (運用環境には影響しません)。

開発者モードで表示されるエラー メッセージの例を次に示します:

'test-module' が例外をスローしました

エラー: タイプ test-module のモジュール test-module に対するサーバー側表示中にエラーが発生します。 注: このエラーは DEVELOPER モードでのみ表示されます。 これは PRODUCTION には影響しません。 これは、開発者がサーバー上で発生する問題に対処するための安全対策です。 以下の問題に対処してください: ウィンドウが定義されていません。

Commerce オンライン SDK バージョン 9.30 リリースにアップグレードした後、カスタム Application Insights API 呼び出しがビルドに失敗する理由は?

Commerce オンライン SDK バージョン 9.30 リリースには、非推奨の Applications Insights SDK からより新しい Microsoft Application Insights JavaScript SDK - Web への更新が含まれています。

Applications Insights の更新には、Application Insights インスタンスへのログ テレメトリにこれらの API を使用した場合、カスタマイズ コードに影響する可能性がある、重大な API 変更が含まれています。 変更の詳細については、Application Insights の古いバージョンからアップグレードするを参照してください。

SDK バージョン 1.28 (Commerce バージョン 10.0.18 リリース) で非推奨になった TSLint の代わりとなるものは何ですか?

オープンソースの TSLint 静的分析ツールは廃止されたので、Dynamics 365 Commerce オンライン SDK が ESLint 静的分析ツールに置き換えられます。 TSLint は SDK バージョン 1.30 (Commerce バージョン 10.0.20 リリース) まで引き続き使用できます。 SDK バージョン 1.30 以前では、必要であれば ESLint に手動で更新できます。 ただし、SDK バージョン 1.30 では、ESLint への更新が実施されます。

SDK バージョン 1.28 に更新した後は、yarn コマンドの実行時に非推奨である警告が表示されます。 その後、いつでも ESLint に切り替えることができます。 ただし、カスタム コードに対して新しいエラーおよび警告が表示される場合があります。

GitHub からオンライン SDK を取得した場合は、Commerce 10.0.18 プレビュー リリースと共に、ESLint に対して必要な変更が含まれています。 これ以外の変更は必要ありません。 ただし、SDK の古いバージョンから更新している場合は、SDK バージョン 1.30 以前の ESLint に対して手動で更新する必要があります。

このセクションの指示に従って、TSLint から ESLint に手動で更新します。

TSLint を ESLint に置き換える

SDK バージョン 1.28 以降に更新した後、ESLint ファイルを作成し、package.json ファイルを変更して、依存関係を含めるようにする必要があります。 また、コマンドが ESLint を使用するよう更新する必要があります。 TSLint と ESLint の両方を使用する場合は、package.json ファイルに TSLint 依存関係をそのまま残すことができます。 ESLint に更新した後、コードに対して新しい警告が表示される場合があります。 必要に応じて、警告を修正または無視できます。

.eslintrc.js ファイルを作成する

ルート SDK フォルダーに .eslintrc.js という名前の新しいファイルを追加する必要があります。 (このフォルダーには、既存の tslint.json ファイルも表示されています。) .eslintrc.js ファイルには、拡張可能な基本ルール セットが含まれます。

基本コンフィギュレーションには、リンティングの制約が緩和された一連のコア ルールが含まれています。 独自のルール セットを定義したり、別のルール セットを拡張したりもできます。

提供されている基本ルール セットを使用するには、.eslintrc.js ファイルを作成し、次のコードに貼り付けます。

module.exports = {
    extends: '@msdyn365-commerce/eslint-config',
    ignorePatterns: ['.eslintrc.js', '*.html', 'src/__mocks__/**', 'src/__tests__/**'],
    parserOptions: {
        project: ['tsconfig.json'],
        sourceType: 'module',
        ecmaFeatures: {
            jsx: true // Allows for the parsing of JSX
        },
        tsconfigRootDir: __dirname
    }
};

リンティング ルールを適用したくない追加ファイルやディレクトリがある場合は、それらを ignorePatterns セクションに追加できます。

また、.eslintrc.js ファイルにルールを定義して、ルールを拡張または置換することもできます。 たとえば、ヘッダー/ヘッダー ルールではファイルすべてにヘッダーが必要であり、基本コンフィギュレーションを拡張してルールをオフにします。 この場合、コンフィギュレーション ファイルで次のコードが使用されます。

module.exports = {
    extends: '@msdyn365-commerce/eslint-config',
    ignorePatterns: ['.eslintrc.js', '*.html', 'src/__mocks__/**', 'src/__tests__/**'],
    parserOptions: {
        project: ['tsconfig.json'],
        sourceType: 'module',
        ecmaFeatures: {
            jsx: true // Allows for the parsing of JSX
        },
        tsconfigRootDir: __dirname
    },
    rules: {
        'header/header': 'off'
    }
};

また、一部のファイルの種類によっては、ルールを上書きしたり、新しいルールを宣言したりすることもできます。 この場合、次の例に示すように、overrides プロパティを使用します。

overrides: [
    {
        files: ['*.props.autogenerated.ts', '*.data.ts'],
        rules: {
            'header/header': 'off'
        }
    },
    {
        files: ['*.tsx', '*.view.tsx', '*.test.ts'],
        rules: {
            'max-len': 'off',
            'max-lines': 'off'
        }
    }
],

詳細な情報やヘルプについては、ESLint ドキュメントを参照してください。

.prettierrc ファイルを作成する

Prettier は、ファイルを保存した後にコードを書式設定するように構成できる意見交換型のコード フォーマッタです。 .prercerrc ファイルを使用すると、Prettier が使用する新しいルールを追加できます。 次の既定設定を使用して、ルート SDK フォルダーに .prettierrc ファイルを作成する必要があります。

{
    "tabWidth": 4,
    "singleQuote": true,
    "printWidth": 140,
    "jsxSingleQuote": true,
    "bracketSpacing": true
}
package.json ファイルを更新する

TSLint と ESLint の両方を使用する場合は、package.json ファイルに TSLint 依存関係をそのまま残し、以下の依存関係を devDependencies セクションに追加することができます。

"@msdyn365-commerce/eslint-config": "^1.27.7",
"@typescript-eslint/eslint-plugin": "^4.2.0",
"@typescript-eslint/parser": "^4.10.0",
"eslint": "^7.16.0",
"eslint-config-prettier": "^7.0.0",
"eslint-plugin-header": "^3.1.0",
"eslint-plugin-import": "^2.22.1",
"eslint-plugin-jsdoc": "^30.7.8",
"eslint-plugin-no-null": "^1.0.2",
"eslint-plugin-prettier": "^3.3.0",
"eslint-plugin-react": "^7.21.5",

次に、ここに示すように lint および lint:fix コマンドを変更します。

"lint": "yarn eslint src/**/*.{ts,tsx}",
"lint:fix": "yarn eslint src/**/*.{ts,tsx} --fix"

最後に、ここに示すように build および start コマンドを変更します。

"start": "yarn msdyn365b start local --use-eslint",
"build": "yarn msdyn365b build --use-eslint",
"build-prod": "yarn clean && yarn msdyn365b build --use-eslint",

ESLint エラーを修正する

この手順はオプションですが、Visual Studio Code の ESLint 拡張機能をインストールすることをお勧めします。 この拡張機能を使用すると、エディターでエラーや警告を直接識別できます。 また、クイック アクションでは、コメントを使用してリンティング エラーを無視できます。

TSLint コメントによって抑制された TSLint エラーがすべて再表示され、新しい ESLint エラーが発生する可能性があります。 ESLint エラーは修正または無効にしたり、警告を無視することもできます。

コードで –use-eslint フラグを使用すると、エラーの発生時にビルドが失敗します。 ただし、警告は無視されます。

コードのリンティングを無効化する

TSLint 無効コメントを ESLint 無効コメントに置き換えることで、TSLint エラーを修正できます。 その方が簡単な場合は、ファイルの検索および置換機能を使用できます。 ただし、必ず結果を確認してください。

いくつかの役立つヒントを以下に示します:

  • TSLint 警告と同様に、ESLint 警告はコメントを使用して無効にすることができます。
  • 次の行を無効にするには、// eslint-disable-next-line <rule1>, <rule2>... を使用します。
  • ルールを無効にする理由を説明したコメントを追加するには、ハイフン (--) を 2 つ追加する必要があります (たとえば、// eslint-disable-next-line <rule1> -- Disabling this rule for reasons)。
  • ファイル全体のルールを無効にするには、複数行コメントを使用する必要があります (たとえば /* eslint-disable <rule1>, <rule2> */)。

次の表に、TSLint と ESLint の一般的な等価物を示します。

TSLint ルール ESLint ルール
// tslint:disable-next-line:no-any // eslint-disable-next-line @typescript-eslint/no-explicit-any
// tslint:disable:no-any /* eslint-disable @typescript-eslint/no-explicit-any */
// tslint:disable-next-line:cyclomatic-complexity // eslint-disable-next-line complexity
// tslint:disable-next-line:no-empty // eslint-disable-next-line no-empty

TSLint を使用して引き続きリンティングする

TSLint を使用して引き続きリンティングする場合は、次に示すように、package.json build および start コマンドで –use-tslint 引数を使用できます。

"start": "yarn msdyn365b start local --use-tslint",
"build": "yarn msdyn365b build --use-tslint",
"build-prod": "yarn clean && yarn msdyn365b build --use-tslint",

[メモ] TSLint のサポートは限定されているため、ESLint を可能な限り使用することをお勧めします。

ビルド時間中にリンティングを完全に無効にする

ビルド時間中にリンティングを完全に無効にする場合は、ここに示すように、package.json ビルド コマンドで --disable-linter 引数を使用できます。

"build": "yarn msdyn365b build --disable-linter",
"build:prod": "yarn clean && yarn msdyn365b build --disable-linter",

モジュール ライブラリ バージョン 9.27 (Commerce バージョン 10.0.17 リリース) にアップグレードした後に、購入ボックス モジュールのビュー拡張機能でコンパイル エラーが発生する場合があります。

コンパイル エラーは、Commerce バージョン 10.0.17 リリースで導入された製品クイック ビュー モジュールに関連するコード共有が原因で発生します。 クイック ビュー モジュールでは多くの機能が購入ボックス モジュールと共有されるため、一部の共通コンポーネントは共通フォルダーに移動し、購入ボックスおよびクイック ビュー モジュールでコードを共有できます。

コンパイル エラーを修正するには、次の例に示すように、buybox.tsx ビュー ファイル内のインポート参照を更新します。

この例では、buybox.view.tsx でのインポート用の古いコードを示します。

import { IBuyboxViewProps } from '../..';
import {
    IBuyboxAddToCartViewProps,
    IBuyboxAddToOrderTemplateViewProps,
    IBuyboxAddToWishlistViewProps,
    IBuyboxFindInStoreViewProps,
    IBuyboxKeyInPriceViewProps,
    IBuyboxProductConfigureDropdownViewProps,
    IBuyboxProductConfigureViewProps,
    IBuyboxProductQuantityViewProps,
    IBuyboxShopSimilarLookViewProps
} from './components';

この例では、buybox.view.tsx でのインポート用の新しいコードを示します。

import { IBuyboxAddToCartViewProps, IBuyboxAddToOrderTemplateViewProps, IBuyboxAddToWishlistViewProps, IBuyboxKeyInPriceViewProps, IBuyboxProductConfigureDropdownViewProps, IBuyboxProductConfigureViewProps, IBuyboxProductQuantityViewProps, IBuyboxShopSimilarLookViewProps } from '../../common';
import { IBuyboxViewProps } from './buybox';
import { IBuyboxFindInStoreViewProps } from './components/buybox-find-in-store';

モジュール ライブラリ バージョン 9.24 (10.0.14 リリース) にアップグレードした後に、データ アクションを使用するクローン モジュールでは次のエラーが表示される場合があります。"UserAuthorizationException. 要求の顧客アカウント番号が間違っていました"。

以下のコア データ アクションでは、署名の変更により、ユーザー アカウント番号パラメーターが (最初のパラメーターではなく) 2 番目のパラメーターに移動し、オプションのパラメーターとして設定されるようになりました。 ユーザー アカウント番号が不要になったほとんどのシナリオでは、現在のサインイン ユーザーのコンテキストでデータ アクションが実行されます。 ユーザー アカウント番号がサインイン ユーザーのユーザー アカウント番号と異なるカスタムシナリオでは、顧客の取得データ アクションを使用してユーザー アカウント番号をフェッチし、データ アクションに渡すことができます。

署名が変更されたコア データ アクションを次に示します:

  • 住所の追加
  • 住所の取得
  • 顧客の取得
  • ロイヤルティ カードの取得
  • ロイヤルティ トランザクションの見積の取得
  • ロイヤルティの発行

モジュール ライブラリ モジュールは、上記のデータ アクションに対する正しい呼び出しパターンで更新されたため、これらのモジュールではエラーは発生しません。 ただし、以前に複製されたモジュールの 1 つに古いデータ アクション署名が残る場合、実行時に次のエラーが表示されます: "UserAuthorizationException. 要求の顧客アカウント番号が間違っていました"。 署名は必要に応じて更新する必要があります。 この問題を解決する 1 つの方法として、モジュール ライブラリ モジュールを一時的に複製して新しい名前を付けてから、新しいモジュール コードと以前に複製したカスタム モジュールとを区別し、変更をマージします。 その後、一時的なモジュールを削除できます。

モジュール ライブラリ バージョン 9.23 (10.0.13 リリース) にアップグレードした後に、"CartlineComponent" または "WishListIconComponent" コンポーネントをインポートする複製したモジュールやビュー拡張機能では、"エクスポート 'CartlineComponent' が '@msdyn365-commerce/components' に見つからない" または "エクスポート 'WishListIconComponent' が '@msdyn365-commerce/components' に見つからない" というエラーが表示される場合があります。

"CartlineComponent" および "WishListIconComponent" コンポーネントの名前が、それぞれ "CartLineItemComponent" および "WishlistIconComponent" に変更されました。 以前のコンポーネント名が複製されたモジュールやビュー拡張機能で使用されている場合は、上記のビルド エラーが表示されます。 これらの問題を修正するには、以前のコンポーネント名を、複製されたモジュールまたはビュー拡張機能コードで新しいコンポーネント名に更新します。

追加リソース

コア データ アクション

モジュール ライブラリ モジュールの複製

Dynamics 365 Commerce 開発のベスト プラクティス