Skip to content
This repository has been archived by the owner on Dec 8, 2024. It is now read-only.

lcov.info contains filenames instead of paths for babel6-translated code #512

Closed
ghost opened this issue Dec 28, 2015 · 8 comments
Closed

Comments

@ghost
Copy link

ghost commented Dec 28, 2015

Hi,

I'm using istanbul with babel's babel-node (version 6) to run coverage statistics collection over my unit tests.
I'm actually using the following command:

babel-node ./node_modules/istanbul/lib/cli.js cover ./node_modules/.bin/_mocha -- --recursive tests/unit/

Versions of the softwares:

  • babel ^6.0.0
  • istanbul ^1.0.0-alpha (solves an issue I had, similar to an issue I found here)

This generated a nice lcov.info file and a nice html report with the right lines reported. The issue is that when I upload lcov.info to a third-party service that needs access to my source repository (codecov.io accessing my github repository), files cannot be found due to a bad file path reported into the lcov.info file.

I tried to look into the configuration file of istanbul, hoping for a life-saving option down -there, but to no avail, since both documentation of the reporting/report-config dictionnary is a bit lacking, and I could not find any sample configuration to guide me.

I know this report is a bit vague, but I can't give access to my repository. At best, I can try to reproduce it in a more confined context/environment.

If I can do anything to help, please tell me, I'll try to provide as much information as I can.

@ghost
Copy link
Author

ghost commented Dec 29, 2015

I tried generating the report from the coverage.raw.json with istanbul report --root coverage --dir coverage/report/ (that contains the right paths), and this time the lcov.info file does contain the paths of the files instead of only the filenames.

I don't understand why the automatic generation does not include the file paths, could it be an internal bug ?

@jbinto
Copy link

jbinto commented Jan 9, 2016

Thanks for reporting. I am having the same issue.

I'm attempting to do a code coverage badge on Coveralls.io. I have Istanbul coverage working with the following command:

babel-node ./node_modules/.bin/istanbul cover ./node_modules/mocha/bin/_mocha -- --recursive --require ./test/test_helper.js

But as you note it ouputs an lcov.info with SF parameters containing neither relative paths, nor absolute paths, but just the filename.

grep ^SF coverage/lcov.info
SF:constants.js
SF:game.js
SF:game_states.js
SF:utils.js
SF:validate.js

These files are in ./src/, and my coveralls tool has no way to find them, it's looking for them in ./.

I ran the command @DavidPineauScality provided, and same for me, the report-generated-from-the-report has the correct absolute path.

My project is open source if it helps: https://github.com/jbinto/thirtyone-server

jbinto added a commit to jbinto/thirtyone-server that referenced this issue Jan 9, 2016
@jbinto
Copy link

jbinto commented Jan 9, 2016

cc: @DavidPineauScality

Unfortunately, for me anyway, that only has the appearance of working.

When I manually edit the initial lcov.info file to add src/ to my filenames, I get a reasonable looking code coverage report, that integrates well with Coveralls:

https://coveralls.io/builds/4671053/source?filename=src%2Fgame.js

But when I re-run the report, sure: I get absolute paths, but it somehow mangles the line numbers:

https://coveralls.io/builds/4671018/source?filename=src%2Fgame.js

I'm not sure what, exactly, re-running the report does, but here's the diff:

https://gist.github.com/jbinto/56064e0056fb4c591c53

Seeing stuff like _interopRequireWildcard, etc. it seems like the second report is not using the Babel source for line numbers, but instead the transpiled source.

@jbinto
Copy link

jbinto commented Jan 9, 2016

More info:

I was able to get everything working for my project by dropping in babel-istanbul:

jbinto/thirtyone-server@f2587e0

It correctly uses absolute paths and it gets the right line numbers. I'm not thrilled about using a fork but it'll do for now.

@gotwarlost
Copy link
Owner

I believe I have fixed this bug with istanbul-lib-source-maps@1.0.0-alpha.9. I verified the thirtyone-server project after this fix. Please try it out and let me know if this is working for you. Reopen the issue otherwise

@jbinto
Copy link

jbinto commented Jan 9, 2016

I can confirm upgrading to istanbul-lib-source-maps@1.0.0-alpha.9 has fixed this issue for me.

Thank you for your help @gotwarlost, much appreciated.

@gotwarlost
Copy link
Owner

You're welcome. Sorry for the delay.

@ghost
Copy link
Author

ghost commented Jan 25, 2016

Hello,

This is also now working for me. Thanks !

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

No branches or pull requests

2 participants