JSPM

  • ESM via JSPM
  • ES Module Entrypoint
  • Export Map
  • Keywords
  • License
  • Repository URL
  • TypeScript Types
  • README
  • Created
  • Published
  • Downloads 17865
  • Score
    100M100P100Q153234F
  • License MIT

lcov posting to codecov.io

Package Exports

  • codecov.io
  • codecov.io/bin/codecov.io.js
  • codecov.io/lib/sendToCodeCov.io

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (codecov.io) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

#codecov.io

Build Status codecov.io

Codecov.io support for node.js. Get the great coverage reporting of codecov.io and add a cool coverage button ( like the one above ) to your README.

Supported CI services: travis-ci

##Installation: Add the latest version of codecov.io to your package.json:

npm install codecov.io --save

If you're using mocha, add mocha-lcov-reporter to your package.json:

npm install mocha-lcov-reporter --save

##Usage:

This script ( bin/codecov.io.js ) can take standard input from any tool that emits the lcov data format (including mocha's LCov reporter) and send it to codecov.io to report your code coverage there.

Once your app is instrumented for coverage, and building, you need to pipe the lcov output to ./node_modules/codecov.io/bin/codecov.io.js.

This library currently supports travis-ci with no extra effort beyond that.

Istanbul

With Mocha:

istanbul cover ./node_modules/mocha/bin/_mocha --report lcovonly -- -R spec && cat ./coverage/lcov.info | ./node_modules/codecov.io/bin/codecov.io.js && rm -rf ./coverage

With Jasmine:

istanbul cover jasmine-node --captureExceptions spec/ && cat ./coverage/lcov.info | ./node_modules/codecov.io/bin/codecov.io.js && rm -rf ./coverage

Contributing

I generally don't accept pull requests that are untested, or break the build, because I'd like to keep the quality high (this is a coverage tool afterall!).

I also don't care for "soft-versioning" or "optimistic versioning" (dependencies that have ^, x, > in them, or anything other than numbers and dots). There have been too many problems with bad semantic versioning in dependencies, and I'd rather have a solid library than a bleeding edge one.