grunt-rev のデフォルトの動作は、指定されたリソースを評価し、コンテンツのハッシュをパスに入れることです。そのため、/images/sprites/rewards.png は /images/sprites/f936712a.rewards.png になります。
私はそれをしたくありません。いくつかのリビジョンが同時に提供されており、古いリビジョンを自由に削除できるようにしたいので、名前を /2013-06-10-e75607/images/sprites/rewards.png (e75607リビジョン全体の commit-id であり、個々のファイルとは関係ありません)。
これは grunt-rev と grunt-usemin で可能ですか? それを行う同等のツールはありますか？
編集
各ファイルのハッシュを使用しない理由について何人かから尋ねられました。説明させてください：
昔ながらの Web サイトでは、ほぼすべてのユーザー入力に応答してブラウザーがリロードされ、バックエンドが入力からまったく新しいページを生成し、HTML がブラウザーに送信されてページが表示されます。これは低速で、CPU と帯域幅を集中的に使用するプロセスですが、1 つの利点があります。これまでに読み込まれたすべてのアセットが、数秒以内にまとめて読み込まれます。
より近代的な Web サイトでは、ロードされるページがアプリケーション全体を説明します。ユーザーが何らかの入力を行うと、ページ上の Javascript が新しい DOM 要素をレンダリングし、必要に応じて新しいアセットをロードします。ページ全体がめったにリロードされない、またはまったくリロードされない 結果として、サイトの応答性が大幅に向上します (開発がはるかに容易になり、安全性が向上し、実行が安価になり、何度も繰り返されます) が、それに対応する欠点があります。ページが読み込まれてから数日。
たとえば、サイトがバージョン cd1d0906 を実行している午前 10 時にサイトにアクセスしたとします。10:30 に、サイトはバージョン 4b571377 にアップグレードされます。午前 11 時にボタンを押すと、sprite.png という画像でレンダリングされるポップアップが表示されます。明らかに、4b571377 バージョンではなく、sprite.png の cd1d0906 バージョンが必要です。
したがって、適切に管理されたサイトは、バージョンが変更された後も数日間、すべてのアセットの古いバージョンを提供し続けます。これを行う最も簡単な方法は、バージョンにちなんで名付けられたディレクトリにすべてのアセットを保持することです。
これが「不必要に」変更されていないファイルのキャッシュ エントリを破棄するという不満は、かなり説得力がありません。デプロイされたアセットのほとんどは、CSS ファイル、JS ファイル、およびスプライトであり、これらはすべて、多数の小さなファイルをコンパイルしたものです。1 つのCSS ファイルと1 つのJS ファイルと1 つのスプライト画像を変更しないという珍しい展開です。バージョンの変更後、キャッシュが貴重になることはめったにありません。