ほとんどのアポストロフィプロジェクトで共通のセットアップを行うために、いくつかのカスタムnpm-moduleをビルドしてそれらをバンドルし、プロジェクトに追加する予定です。私がそれらでやりたい機能のいくつかは、ウィジェットとバックエンド機能の追加からのアパートであり、公式のアポストロフィモジュールのセットアップを編集し（たとえば、のデフォルトページタイプをセットアップするapostrophe-pages）、nunjuckブロックやテンプレートをオーバーライドします。
どちらも、アポストロフィの暗黙的なサブクラス化メカニズムを使用してプロジェクトレベルの構成で簡単に上書きできるため、異なるプロジェクトの共通ベースセットアップを共有するという私の目標は、カスタムボイラープレートで達成できますが、リリースすることでデフォルトをアップグレードする機能は失われます。ノードモジュールの新しいバージョン。
全体として、私は次のようなMavenスタイルの依存関係階層で考えていました。
Apostrophe npm modules <- custom npm modules <- project modules
JavaおよびMavenベースのCMSから来ると、私は多くの点で私の考え方を変える必要があることを理解しています。それで、私がやろうとしていることは可能であり、それはアポストロフィの世界で意味がありますか？このようなことを達成するための「アポストロフィの方法」とは何でしょうか。improve拡張したいモジュールごとにmoogオプションを使用してカスタムnpmモジュールを作成する必要がありますか？
前もって感謝します。
npm_modulesディレクトリ内でも、アポストロフィは最初にベースモジュールをスキャフォールディングし、次にそれらのモジュールを拡張するモジュールをスキャフォールディングします。つまり、カスタムnpmモジュールは、公式のアポストロフィモジュールと同じ継承チェーンに従います。他のアポストロフィモジュールと同じ方法でそれらをオーバーライドできます。
meta module (apostrophe-pieces) > custom-pieces (piece extension, custom npm module) > custom-pieces (project-level overrides)
あなただけの選択でファイルとメソッドをオーバーライドするだろうlib/modules/あなたがの部分を上書きしたいのと同じ方法apostrophe-blogのように、lib/modules/custom-pieces/views/widget.html
私はあなたが物事を上書きしたい方法を正しく理解していますか？
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加