Open nweldev opened 8 years ago
This issue is due to the lake of support for babel + systemjs by istanbul.
The following leads have been followed, without success :
Error: Cannot find module 'angular'
Now, you could see a possible resolution with the remap-coverage
npm script, which use istanbul report
to generate the html report from the remaped json report, but there is still some issues on it.
guybedford/systemjs-istanbul may be another possible solution
References to related issues :
and projects :
I mark this issue as external and reopen it, as the last pull request was just a "best way" to resolve it, but doesn't resolve it yet due to SitePen/remap-istanbul#1.
The jspm-test-demo repo is a bit wonky / one off test. I'd really not recommend it per se.
I have a repo, istanbul-jspm-coverage-example, with an example. Granted it's not a browser example, but I'll be swinging back around to that soon at some point.
I'm actually using istanbul 1.0.0-alpha2 and it seems to be working fine with ES6 + SystemJS sans browser support currently, but that is a different ball of wax so to speak. istanbul 1.1.0-alpha.1 was just released a week or so ago and I'll be checking it out soon.
I'll be looking to support NightmareJS quite likely when I swing back around to finishing up some JSPM efforts in the coming months.
Are you trying to get things working in the browser (headless?).
Thank you for your contribution. I'll take a look at your project and the istanbul alpha2 asap.
Until now, our best shot was remap-istanbul, but there is some issues that needs to be resolved on it before we could generate html reports, and we need to use stable dependencies only.
Yes, this is a "browser oriented" project, given that's it's a seed for AngularJS. But I don't think it could be really relevant regarding this issue.
The trick with browser testing in the direction that I'm approaching at least with NightmareJS is that a separate process is spawned as it uses Electron under the hood and the global variable that istanbul uses for gathering metrics is no longer directly available. I have to work out a two / three part process and easy hook into Nightmare. What I'm trying to accomplish is a minimal invasive approach and something that can be setup easily in a standard mocha (or other runner) test file.
The jspm-test-demo may work as a test case, but it pulls in tons of dev dependencies into JSPM which IMHO muddies the waters there. I'd rather have a small external NPM dependency which can be instrumented directly in the test and leave the JSPM dev and main dependencies free to clearly show what the web app itself depends on to function.
Despite the alpha tag I have found 1.0.0-alpha.2 to work solidly with mocha and Babel 6. Use babel-node
to launch an NPM script and don't forget to add --compilers js:babel-register
to options if using mocha.
Just adding a note here for JSPM 17.x
usage w/ Babel 6 to explore. It seems like there is now a babel plugin babel-plugin-istanbul.
I'll be swinging back around to exploring instrumenting JSPM 17.x tests soon especially hopefully getting things to work in the browser via ava / nyc / nightmare and babel-plugin-istanbul.
@noelmace Just posting here in case you have some time to get a jump on things before I get to exploring again for browser integration. There are new releases for NYC (v7+) which looks much improved for integrating instrumentation and perhaps there may be some interesting interaction w/ babel-plugin-istanbul w/ how SystemJS operates in the browser.
Guy dropped a recent blog post also describing new attempts at integration: http://guybedford.com/systemjs-mocha-istanbul
The karma-coverage reports are still related to the transpiled code after ef79014b125f28eeb20c2a502e516f68451fd4fd.
See the target/coverage folder after running
npm test
for reproduction (the bad behaviour is especially obvious on the html report).