試験は twada/battlefield-sourcemaps で行っている
- SourceMap 対応が入った espower 0.9.0 を使う
- espower(ast, options) の第二引数 options に
sourceMap
というキーで上流の SourceMap オブジェクトを入れる options.sourceMap
が与えられた場合、 AST 変換時のファイル名、ファイル行番号を補正する- AST の段階でできるのはここまで
- 方針が安定するまで SourceMap 対応の espower 0.9.0 を直接使う (espower-source ではなく)
- 上流の SourceMap を探す (探し方は各 instrumentor によって異なる)
- 上流 SourceMap を発見した場合 espower の options に入れる
- escodegen から出てきた SourceMap を上流の SourceMap とつなぐ
- 下流に流す (流し方は各 instrumentor によって異なる)
作業 PR support multistage sourcemap by vvakame · Pull Request #2 · twada/grunt-espower -> リリース完了
grunt では上流 SourceMap がどう来るか調べる必要がある。
- js と同一ディレクトリに外部 .map ファイルのパターン
- js ファイル末尾に base64 コメントで付いているパターン
- 作業 PR [WIP] gulp-sourcemaps support by twada · Pull Request #2 · twada/gulp-espower
- gulp では gulp-sourcemaps を使う
- vinyl の file.sourceMap に上流の SourceMap が入っている
- gulp-sourcemaps で囲まれた各 plugin は上流の SourceMap と下流の SourceMap をつなぐ責務を負う
- つないだ SourceMap を file.sourceMap に入れて下流に push する (コードには添付しない)
- しくみとして下流は存在しないので、読み込んだファイルに base64 形式の SourceMap が付いていた場合 espower に渡すだけで良い?
- 作業 PR SourceMap transform chain by twada · Pull Request #4 · twada/espowerify -> リリース完了
- 参考: browserify v2 adds source maps
- browserify の多段 SourceMap は各 transform がファイル末尾コメントの SourceMap に base64 で埋め込む責務を担う
- stream から読み込んだコード末尾に上流の SourceMap が付いている可能性がある
- 上流 SourceMap が付いていた場合は espower が出した SourceMap とつないでからコメントにして末尾に付ける
- CoffeeScript コンパイラから出てきた SourceMap を espower に渡す
concat 系、動きが怪しいものが多そうかな、という気がしています。
browserify だけはブレークポイントも含めてきちんと動作していますが、 gulp-concat は組み合わせ方によってはデバッガにファイルが一つしか出なかったりしています。
ブレークポイントは複数打ってみてください。ブレークポイントひとつだけだと、上手く行かない場合もありそうです (ここは要検証)。
concat 系がきちんと動く条件ですが、 sources の配列と soucesContents の配列の添字が一致していて、変換チェーンの一番最初のファイル名とファイル内容になっていること、そして各変換段階がきちんと前のファイルとつないでいることが条件かなと推測しています。