6

grunt-usemin の構成と使用のさまざまなポイントでパスがどのように処理されるかを理解するのに多くの問題があります。

次のレポ レイアウトがあります。ここで、レポ ルートは Web アプリ ルートにもなります。

/dashboard/index.html
/Gruntfile.js
/vendor/...some 3rd party CSS and JS...

したがって、index.html ファイル -> somedomain.com/dashboard/index.html です。

index.html ファイルには、/vendor フォルダーのいくつかの CSS および JS アセットが含まれています。ビルド出力をビルド フォルダーに配置するように grunt を構成しました。

/build/dashboard/index.html

index.html ファイルでは、すべての CSS リンクと JS スクリプト タグを usemin ブロックで囲んでいます。

<!-- build:css(.) app.min.css -->
<!-- build:js(.) app.min.js -->

「/vendor/backbone.js」のスクリプトタグが適切な場所で見つけられるように、「(.)」で「代替検索パス」を指定する必要がありました。それまでは、/dashboard/vendor/backbone.js を探していました。

CSS/JS アセットの処理の出力を build/dashboard/app.min.css および build/dashboard/app.min.js に出力し、単純な相対 "app.min. css/js」のパス。

問題は、grunt-usemin が、両方のコンテキストに指定している「app.min.*」パスを使用しているように見えることです。これにより、それらが連携できなくなります。

1）ファイルを作成する目的で、パスをビルドディレクトリに対する相対パスとして扱います。ファイルは build/app.min.css と build/app.min.js に配置されます。

2) 新しいリンク/スクリプト タグを生成する目的で、パスを index.html ファイルに対する相対パスとして扱います。ブラウザは build/dashboard/index.html をロードし、次に build/dashboard/app.min.css にマップされる「app.min.css」をロードしようとします。

解決策はありますか？

4

2 に答える 2

3

私はパーティーに本当に遅れましたが、この問題にも非常に不満を感じており、満足のいく修正や回避策が見つかりませんでした. そこで、うまくいけばこの問題を回避するために、いくつかのかなり汚いトリックを考え出しました。というわけでシェアしたいと思います。

まず、この問題が発生する理由を簡単に確認しましょう。usemin が出力 JS/CSS ファイルを生成するとき、destディレクトリと、usemin ブロックで指定した出力ディレクトリとの間の単純なパス結合を実行します。destであり、 useminbuildブロックが

<!-- build:css(.) app.min.css -->

次に、と結合buildしapp.min.cssて出力ファイルを吐き出しますbuild/app.min.css

しかし、 usemin タスクは単にブロック内のパスを置き換えて、最終的に

<link rel="stylesheet" href="app.min.css"/>

HTMLファイルが下にあるため、間違ったディレクトリにリンクしていますbuild/dashboard/index.html

したがって、私の回避策はこのアイデアを中心に展開しています:destディレクトリが HTML ファイルの場所に相対的な場合はどうなるでしょうか? それはこの問題を解決しませんか？上記の例を考えると、destはどうなるbuild/dashboardでしょうか? 出力ファイルの場所を吐き出し、正しくリンクすることがわかります。HTML ファイルをコピーするためのコピー タスクを作成する必要があることに注意してください。そのため、HTML ファイルがbuild/dashboard/index.html以前と同じようにコピーされていることを確認してください。

もちろん、次の質問は、HTML ファイルが複数のディレクトリにある場合はどうなるかということです。HTML ファイルが存在する可能性のあるディレクトリごとに useminPrepare ターゲットを作成するのは、非常に苦痛で直感的ではありませんか? これが、私が独自の grunt scaffold を作成しているときに、この問題を回避するためだけに非常に特別な grunt タスクを作成する理由です。私はそれをuseminPreparePrepareと呼んでいますはい、意図的にばかげた名前を付けています。

その名前が示すように、これは useminPrepare 構成を準備するタスクです。それはまさに私が上で説明したことを行います。すべての構成は、useminPrepare 構成をミラーリングします (実際、それらのほとんどは、useminPrepare にコピーされるだけです)。ただし、1 つの例外がありますsrc。 HTML ファイル。したがって、あなたの例src: "."では問題ありません。useminPreparePrepare を使用するには、最初にそれをビルドにインポートし (私のコードをコピーして貼り付けてもかまいません)、useminPrepare タスクの名前を useminPreparePrepare に変更し、先ほど説明したsrcプロパティを追加します。好きなターゲットを指定して useminPreparePrepare を実行してから、すぐにターゲットを指定せずに useminPrepare を実行してください。のターゲットが実行されます。これは、useminPreparePrepare が HTML ファイルが見つかったディレクトリごとに 1 つのターゲットを生成し、実行した useminPreparePrepare ターゲットの構成をコピーするためです。このようにして、構成はすべての HTML ファイルを簡単に探すことができます。

例

"useminPreparePrepare": {
    // Search for HTML files under dashboard even though src is .
    // because we want to avoid including files generated under build directory.
    html: "dashboard/**/*.html",
    options: {
        src: ".",
        dest: "build",
        ...

"usemin": {
    html: ["build/**/*.html"],
    ...

"copy": {
    html: {
        files: [{
                expand: true,
                src: ["dashboard/**/*.html"],
                dest: "build"
            }
        ]
    },
    ...

お役に立てれば！良い一日を過ごしてください。

編集:上記の例を考えると、実際に現在のディレクトリからすべての HTML ファイルを含める場合、事前にクリーンアップされていない場合は、生成された HTML ファイルも含めることになることに気付きました。したがって、それらを事前に消去するか、dashboardディレクトリの下を調べます。構成がより直感的に見えるように、srcとディレクトリを分離することをお勧めします。dest

于 2014-02-08T19:51:31.203 に答える