Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative paths in the coverage file are in violation of istanbul spec #110

Closed
jamestalmage opened this issue Dec 21, 2015 · 14 comments · Fixed by #164
Closed

Relative paths in the coverage file are in violation of istanbul spec #110

jamestalmage opened this issue Dec 21, 2015 · 14 comments · Fixed by #164
Labels

Comments

@jamestalmage
Copy link
Member

The istanbul spec calls for absolute paths, but we pass in relative ones. This is not just a nit, it causes real problems.

@novemberborn
Copy link
Contributor

Are these introduced by the source map path rewrite?

@jamestalmage
Copy link
Member Author

No, we pass relPath to the instrumentor instead of filename. As I recall it isn't necessary, because most/all the reporters look for the longest common parent path and truncate to that.

It won't be an issue until someone tries to combine with coverage generated outside of nyc

@jamestalmage
Copy link
Member Author

Let's punt on the issue until the caching PR is merged. I don't want to rebase that again

@riophae
Copy link

riophae commented Dec 21, 2015

fs.js:549
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                                                  ^

Error: ENOENT: no such file or directory, open './src/helpers/Users/lifangzhou/Development/react-dynamic-element/src/helpers/__DEV__.js'
    at Error (native)
    at Object.fs.openSync (fs.js:549:18)
    at Object.fs.readFileSync (fs.js:397:15)
    at LookupStore.Store.mix.get (/Users/lifangzhou/Development/react-dynamic-element/node_modules/nyc/node_modules/istanbul/lib/store/fslookup.js:40:19)
    at HtmlReport.Report.mix.writeDetailPage (/Users/lifangzhou/Development/react-dynamic-element/node_modules/nyc/node_modules/istanbul/lib/report/html.js:411:67)
    at /Users/lifangzhou/Development/react-dynamic-element/node_modules/nyc/node_modules/istanbul/lib/report/html.js:489:26
    at SyncFileWriter.extend.writeFile (/Users/lifangzhou/Development/react-dynamic-element/node_modules/nyc/node_modules/istanbul/lib/util/file-writer.js:57:9)
    at FileWriter.extend.writeFile (/Users/lifangzhou/Development/react-dynamic-element/node_modules/nyc/node_modules/istanbul/lib/util/file-writer.js:147:23)
    at /Users/lifangzhou/Development/react-dynamic-element/node_modules/nyc/node_modules/istanbul/lib/report/html.js:488:24
    at Array.forEach (native)

Maybe a related issue?

@bcoe bcoe added the bug label Jan 2, 2016
@MoOx
Copy link

MoOx commented Jan 3, 2016

Got the same issue as @riophae : absolute path added after local dir. That's weird (something like './src/blah/Users/ME/MY/ENTIRE/PATH/TO/A/RELATIVE/FILE.js)

@qasim
Copy link

qasim commented Feb 6, 2016

Getting this issue when trying to report coverage to coveralls.

Does my full absolute path twice, so my actual path is /Users/qasim/blah/blah/index.js, and nyc interprets it as ./Users/qasim/blah/blah/index.js, making it think of it as /Users/qasim/blah/blah/Users/qasim/blah/blah/index.js(incorrect).

@riophae
Copy link

riophae commented Feb 7, 2016

The same with @qasim

@bcoe
Copy link
Member

bcoe commented Feb 7, 2016

@novemberborn I wonder if some of the fixes for paths outside the working directory might have made this problem more prevalent?

@MoOx
Copy link

MoOx commented Feb 7, 2016

I can't really remember but I think I was doing something wrong, cause I don't have this issue anymore.

@novemberborn
Copy link
Contributor

@novemberborn I wonder if some of the fixes for paths outside the working directory might have made this problem more prevalent?

I don't think so…? In any case just did #164.

@riophae @qasim could you try with that branch?

@MoOx the change to absolute paths should have fixed an issue with source map sources being absolute and not being resolved correctly against the relative coverage report. If you manage to reproduce the problem could you try with #164?

@qasim
Copy link

qasim commented Feb 8, 2016

@novemberborn fixed with that branch 👍

@riophae
Copy link

riophae commented Feb 14, 2016

fixed!

@Tom-Dibble
Copy link

I'm still seeing this bug with remap-istanbul 0.11.0.

Specifically, we have our gulp target generate sourcemaps using gulp-sourcemaps (2.6.4) and a remapping function to put "../../src" in them (which is the path from the built file back to its source map). For example, we have a file at FULLPATH/src/util.ts, which generates JS at FULLPATH/build/src/util.js. In the .map file I see "sourceRoot":"../../src" correctly noted.

However, if I run remap-istanbul to generate the HTML coverage using:

cat coverage/coverage-final.json | ./node_modules/.bin/remap-istanbul --output html-report --type html

I get exceptions like:

Error: Could find source for : "src/FULLPATH/build/src/util.ts"
    at CoverageTransformer.addFileCoverage (/FULLPATH/node_modules/remap-istanbul/lib/CoverageTransformer.js:176:18)
    at /FULLPATH/node_modules/remap-istanbul/lib/CoverageTransformer.js:298:14
    at Array.forEach (native)
    at CoverageTransformer.addCoverage (/FULLPATH/node_modules/remap-istanbul/lib/CoverageTransformer.js:296:24)
    at /FULLPATH/node_modules/remap-istanbul/lib/remap.js:51:13
    at Array.forEach (native)
    at remap (/FULLPATH/node_modules/remap-istanbul/lib/remap.js:50:16)
    at Promise.then (/FULLPATH/node_modules/remap-istanbul/bin/remap-istanbul.js:133:21)
    at process._tickCallback (internal/process/next_tick.js:109:7)

Note that if I switch our sourcemaps to generate absolute paths for sourceRoot ("sourceRoot"="/FULLPATH/src") instead, everything works, except that those .map files will only ever work on my personal machine (or another which happens to have the repo cloned to the same path).

Did this bug surface again, or is this separate from the previously reported 2016 issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants