You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sources in source maps are used, remap-istanbul takes the filename (including the path) from the source map. If those source file names are not provided with a path, they get passed to the Istanbul reporter without a path. When the Istanbul HTML reporter gets files without a path, it outputs them in the __root__.
The solution is to provide some sort of pathed filename with the path the source map.
Do you have a link of a generated source map (or a source file with the map in it) and I can try to validate that is the case. It would be helpful to get some more examples of what people have in the wild.
I'm using karma so don't have any files to show really, I can explain what it is I'm doing though.
I'm running karma with webpack, karma is loading a spec.bundle.js that pulls in all the specs and using [webpack, sourcemap] plugins for karma. I am also using the source-map-loader as a preloader in my webpack config but I've tried with and without it, made no difference.
in my tsconfig I'm using:
"inlineSourceMap": true,
"inlineSources": true
I have tried setting devtool in webpack but that made no difference.
The coverage is transformed correctly and works well however the path is always root no matter what I try.
These source maps are inlined when the typescript compiler runs.
Thinking about this, I think I realise the problem. Many people were complaining that with inline sources, the file paths were invalid, because the source files were no longer there, and so we basically took whatever path was in the source map as the authoritative path. The problem though is, when there is no path at all in the source map, just a source file name, then end up with a situation where all the files end up in the __root__ because none of them have paths.
So I need to rework the logic so that if there is no path at all, we copy the path of the covered file.
@kitsonk you are doing an amazing job of maintaining this library and I love using it. I have the same issue as @waeljammal though. Everything ends up in __root__. Let me know how I can help fix the logic for this, if I can.
Thanks @devCrossNet this fixed it for me also. @kitsonk any chance of pulling this in for 0.6.5? Took a more than a few hours to track down the root cause.
@devCrossNet
Your fork breaks the gulp task for me with the following error:
[10:57:26] Using gulpfile C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\gulpfile.js
[10:57:26] Starting 'remap-istanbul'...
C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\source-map\lib\array-set.js:92
throw new Error('No element indexed by ' + aIdx);
^
Error: No element indexed by 2
at ArraySet_at as at
at SourceMapConsumer_originalPositionFor as originalPositionFor
at getMapping (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:76:25)
at C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:256:20
at Array.forEach (native)
at C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:254:37
at Array.forEach (native)
at C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:192:22
at Array.forEach (native)
at remap (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:191:12)
at DestroyableTransform._transform (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\gulpRemapIstanbul.js:41:20)
at DestroyableTransform.Transform._read (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_transform.js:159:10)
at DestroyableTransform.Transform._write (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_transform.js:147:83)
at doWrite (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_writable.js:313:64)
at writeOrBuffer (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_writable.js:302:5)
at DestroyableTransform.Writable.write (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_writable.js:241:11)
The remap-instanbul 0.6.4 is working normally, but putting the reports on the wrong location. Any clues?
Run: gulp remap-istanbul [This task will cause an error]
Sorry for the big repo, the important files are:
gulp/scripts.js (Setup typescript, sourcemap and bundle task] (it will output the files: src/main/resources/public/bundle.js and src/main/resources/public/maps/bundle.js.map)
gulp/unit-tests.js & src\test\ui\karma.conf.js (Configure the coverage reporter and the remap-istanbul gulp task) (The karma will output the file src/test/ui/unit/coverage/js/coverage.json, which is being used as source to remap-sourcemap gulp task)
Anyway. I'm not sure if you guys are facing the same issue as I am. In my case I've found a solution/workaround.
On it, the HTML Reporter was outputing my source code htmls at "C:\source".
Debugging the code I've found out that the culprit for it was instanbul/lib/report/html.js:484 that.writeFiles(writer, child, path.resolve(dir, child.relativeName), collector);
In my specific case, dir was "src\test\ui\unit\coverage\ts\html" and child.relativeName was "/source/recebimento/devolucao-assinatura", so path.resolve(dir, child.relativeName)
evaluated to "c:\source\recebimento\devolucao-assinatura"
So I changed my sourcemap task to use "source" as sourceRoot instead of the default "/source". .pipe($.sourcemaps.write("maps", {sourceRoot: 'source'}))
This way, path.resolve(dir, child.relativeName)
evaluated to the correct full path "c:\autuacao\recebimento\src\test\ui\unit\coverage\ts\html\source\recebimento\devolucao-assinatura"
and the files were put on the correct folder.
Activity
kitsonk commentedon Apr 26, 2016
When sources in source maps are used,
remap-istanbultakes the filename (including the path) from the source map. If those source file names are not provided with a path, they get passed to the Istanbul reporter without a path. When the Istanbul HTML reporter gets files without a path, it outputs them in the__root__.The solution is to provide some sort of pathed filename with the path the source map.
Do you have a link of a generated source map (or a source file with the map in it) and I can try to validate that is the case. It would be helpful to get some more examples of what people have in the wild.
waeljammal commentedon Apr 26, 2016
I'm using karma so don't have any files to show really, I can explain what it is I'm doing though.
I'm running karma with webpack, karma is loading a spec.bundle.js that pulls in all the specs and using [webpack, sourcemap] plugins for karma. I am also using the source-map-loader as a preloader in my webpack config but I've tried with and without it, made no difference.
in my tsconfig I'm using:
"inlineSourceMap": true,
"inlineSources": true
I have tried setting devtool in webpack but that made no difference.
The coverage is transformed correctly and works well however the path is always root no matter what I try.
These source maps are inlined when the typescript compiler runs.
kitsonk commentedon Apr 27, 2016
Thinking about this, I think I realise the problem. Many people were complaining that with inline sources, the file paths were invalid, because the source files were no longer there, and so we basically took whatever path was in the source map as the authoritative path. The problem though is, when there is no path at all in the source map, just a source file name, then end up with a situation where all the files end up in the
__root__because none of them have paths.So I need to rework the logic so that if there is no path at all, we copy the path of the covered file.
erikdonohoo commentedon May 13, 2016
@kitsonk you are doing an amazing job of maintaining this library and I love using it. I have the same issue as @waeljammal though. Everything ends up in
__root__. Let me know how I can help fix the logic for this, if I can.devCrossNet commentedon May 31, 2016
what about something like this:
if(options.someFlag){
var fileName = filePath.replace('.js', '.ts'); //or a custom replace function
rawSourceMap.file = fileName;
rawSourceMap.sources = [fileName];
}
at line https://github.com/SitePen/remap-istanbul/blob/master/lib/remap.js#L226 ?
devCrossNet commentedon Jun 2, 2016
@kitsonk I think I got it, can you have a look: https://github.com/devCrossNet/remap-istanbul/commit/bd1fdbca7df58905db19c103c9ba89342f440065
Blackbaud-BobbyEarl commentedon Jun 7, 2016
Confirming we have the exact problem @waeljammal has described, and that the changes from @devCrossNet fixes it for us.
waeljammal commentedon Jun 8, 2016
It's working for me on the @devCrossNet commit.
senseiweb commentedon Jun 12, 2016
Thanks @devCrossNet this fixed it for me also. @kitsonk any chance of pulling this in for 0.6.5? Took a more than a few hours to track down the root cause.
Great library...keep up the awesome work.
tomasgodoi commentedon Jul 6, 2016
@devCrossNet
Your fork breaks the gulp task for me with the following error:
[10:57:26] Using gulpfile C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\gulpfile.js
[10:57:26] Starting 'remap-istanbul'...
C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\source-map\lib\array-set.js:92
throw new Error('No element indexed by ' + aIdx);
^
Error: No element indexed by 2
at ArraySet_at as at
at SourceMapConsumer_originalPositionFor as originalPositionFor
at getMapping (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:76:25)
at C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:256:20
at Array.forEach (native)
at C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:254:37
at Array.forEach (native)
at C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:192:22
at Array.forEach (native)
at remap (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\remap.js:191:12)
at DestroyableTransform._transform (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\remap-istanbul\lib\gulpRemapIstanbul.js:41:20)
at DestroyableTransform.Transform._read (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_transform.js:159:10)
at DestroyableTransform.Transform._write (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_transform.js:147:83)
at doWrite (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_writable.js:313:64)
at writeOrBuffer (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_writable.js:302:5)
at DestroyableTransform.Writable.write (C:\Desenv\STF\Java\VCS\Git\Remote\stfdigital-ms-dev1\autuacao\recebimento\node_modules\through2\node_modules\readable-stream\lib_stream_writable.js:241:11)
The remap-instanbul 0.6.4 is working normally, but putting the reports on the wrong location. Any clues?
devCrossNet commentedon Jul 6, 2016
@tsmgodoi thanks for sharing this. I will have a look at it this weekend. can you provide a gulp setup to reproduce this error?
tomasgodoi commentedon Jul 6, 2016
@devCrossNet
Of course, I've setup a repository with the problem at https://github.com/tsmgodoi/stfdigital-autuacao-recebimento .
Just:
Sorry for the big repo, the important files are:
tomasgodoi commentedon Jul 6, 2016
Anyway. I'm not sure if you guys are facing the same issue as I am. In my case I've found a solution/workaround.
On it, the HTML Reporter was outputing my source code htmls at "C:\source".
Debugging the code I've found out that the culprit for it was instanbul/lib/report/html.js:484
that.writeFiles(writer, child, path.resolve(dir, child.relativeName), collector);In my specific case, dir was "src\test\ui\unit\coverage\ts\html" and child.relativeName was "/source/recebimento/devolucao-assinatura", so
path.resolve(dir, child.relativeName)evaluated to "c:\source\recebimento\devolucao-assinatura"
So I changed my sourcemap task to use "source" as sourceRoot instead of the default "/source".
.pipe($.sourcemaps.write("maps", {sourceRoot: 'source'}))This way,
path.resolve(dir, child.relativeName)evaluated to the correct full path "c:\autuacao\recebimento\src\test\ui\unit\coverage\ts\html\source\recebimento\devolucao-assinatura"
and the files were put on the correct folder.
fixed: Missing folder structure in html output #50 (#65)
dylans commentedon Jan 11, 2017
I think this was fixed in 0.7.0 and we forgot to close this issue.
akki-12345 commentedon Sep 22, 2018
@devCrossNet https://github.com/devCrossNet/remap-istanbul/commit/bd1fdbca7df58905db19c103c9ba89342f440065 -- this link is not working , can you please provide solution once again
akki-12345 commentedon Sep 22, 2018
can anyone please provide the solution ??
devCrossNet commentedon Sep 22, 2018
@akki-12345 I am sorry but I don’t have the solution anymore. It’s already 2 years ago and too much changed 😕
akki-12345 commentedon Sep 22, 2018
Ok @devCrossNet . Thanks for the quick reply.