grunt でコンパイルされたアプリのソース マップを含むワークフローを知っていますか?
uglifyjsソースマップを簡単に生成できるようなプラグインについてはよく知っています。しかし、これを 1 回限りのソース マップを作成するのではなく、より複雑なワークフローに組み込むことを検討しています。
最も人気のある Yeoman ジェネレーター (私が知っている) では、ワークフローでソース マップが欠落していることに気付きました。これは、ソース マップの主要なプラグインがサポートされていないためですか? それとも、ワークフローにソース マップが必要ないということでしょうか?
私が遭遇した一般的な grunt プラグインの注目すべき問題の原因は次のとおりです。
uglifyハッキーな修正なしでは、最も基本的なプロジェクト構造でさえ処理できません。
useminまた、プロジェクトごとに 1 つしかサポートできないという点で、最も単純な構成を超えてソース マップを処理することもできません(ただし、修正するにはハックが必要です)。可能な解決策は明らかに使用を完全に停止することですが、そうすると、 、、および とusemin組み合わせるなど、すべての利点を失うことになります。revwatchconnect
アプリをテストするときに、連結されていない/縮小されていないソースを使用してテストすることが最善の方法であると考えています。もちろん、これは理想的とは言えません。テスト環境が本番環境を可能な限り反映するようにしたいからです。
grunt プロジェクトでソース マップを使用しますか? どのようにしますか？そうでない場合、サポートの欠如をどのように回避しますか?