js-devtools / coverage-istanbul-loader Goto Github PK

There is a testing extension for Quasar Framework that introduces code-coverage support for Cypress e2e testing: link
I created a Pull Request for introducing Webpack code coverage support for this library: link
@maiolica highlighted that there some issues with the covered lines for .vue template files but there aren't with .ts files.
I've looked into it and I've had the same results in my template files.

I used the following webpack loader rule to instrument the code:

{
          test: /\.(js|ts|vue)$/,
          loader: '@jsdevtools/coverage-istanbul-loader',
          options: { esModules: true },
          enforce: 'post',
          exclude: [/\.(e2e|spec)\.(js|ts)$/, /node_modules/, /\.quasar/],
}

What could be the problem? Do I need to add an another loader to handle .vue files better?

You can test it when you follow the instructions from the PR.

1. Pull quasar-testing repo.
2. Checkout dev branch.
3. yarn install in the root directory.
4. Follow the instructions from Other information part of the PR to test cypress e2e coverage.

Hi,

I'm using coverage-istanbul-loader + karma-coverage-istanbul-reporter in a webpack + typescript + karma setup for tests (no Babel). All is working fine and coverage calculation is accurate. Thanks a lot for your work.

I'm only facing a minor, but quite annoying issue. When looking in html report, coverage informations are not at the same height that the related line in code. It appears that blank lines are ignored and each one add 1 line to the offset, that obviously grows wider and wider after many of those.

Here's a compared screenshot : https://imgur.com/a/QFdxQBw

Not really sure if it's related to your loader or to the reporter. I've checked available options in both but didn't find something relevant to fix this.

Any clue to solve this ?

Thanks !

Hello!

We're running tests in Karma, and while on master we're using istanbul-instrumenter-loader normally, I tested your package to see if it fixed our issue since you've upgraded to the newer APIs, but it was still demonstrating the issue.

We noticed that while running tests through karma-webpack, and using this package to get coverage numbers, the number of tests that are run changes between runs.

I tested removing this package and all unit tests are run every time, and I cannot reproduce the issue, so it seems that running this module is causing our setup to act oddly.

Any ideas as to what might be happening?

Our issue tracking this: video-dev/hls.js#2125

Hi, a refugee from https://github.com/webpack-contrib/istanbul-instrumenter-loader here...

The istanbul-instrumenter-loader project now appears to be archived/abandoned by it's maintainers, so the likelihood of it being updated to support webpack v5 seems remote at this point.

I was already considering replacing istanbul-instrumenter-loader with coverage-istanbul-loader, because the last published release ([email protected]) uses a very old version of instanbul-lib-instrument that doesn't support some newer ES2019 language features like optional catch bindings.

However it is not immediately clear whether coverage-istanbul-loader supports webpack 5 yet or not? (package.json file has webpack: ^4.43.0 in devDependencies)

If it does already support webpack 5, that's great. If not, are there any plans to add webpack 5 support?

There doesn't appear to be a lot of recent activity in this project, so I'm wondering whether this project is also at risk of being abandoned?

I'm transpiling my react app with babel-loader. How do I set up coverage-istanbul-loader to play nicely with babel?

Everything else is covered and working perfectly, however I've noticed that a custom React hook using two useCallbacks has both dependency arrays uncovered. The function containing the calls is being called, which would make me expect them to be covered.

For example:

const getThing = useCallback(() => {
  return client
    .get('/some-url')
    .then(res => res.json());
}, [client]);

has , [client] covered, whereas with the following it's not covered:

const getThing = useCallback(() => {
  return client
    .use()
    .get('/some-url')
    .then(res => res.json());
}, [client]);

I'm not suggesting there is an issue with this project - to rule that out, how should I go about finding the cause of this?

There can be an io exception when there is no sourcemap given nor there is a source map file.
The following stacktrace will be reproduced (I have ommited some parts of the file path) :

ERROR in ./src/main/javascript/app/components/path/traffic-diensten.component.js
Module build failed (from ./node_modules/coverage-istanbul-loader/lib/index.js):
Error: An error occurred while trying to read the map file at \path\src\main\javascript\app\components\path\traffic-diensten.component.js.map
Error: ENOENT: no such file or directory, open '\path\src\main\javascript\app\components\path\traffic-diensten.component.js.map'
at readFromFileMap (\path\node_modules\convert-source-map\index.js:40:11)
at new Converter (\path\node_modules\convert-source-map\index.js:47:32)
at Object.exports.fromMapFileComment (\path\node_modules\convert-source-map\index.js:110:10)
at Object.exports.fromMapFileSource (\path\node_modules\convert-source-map\index.js:122:22)
at Object.default_1 (\path\node_modules\coverage-istanbul-loader\src\index.ts:28:26)
@ ./src/main/javascript/app/components/overzichten/overzichten.module.ts 92:0-94 108:807-840
@ ./src/main/javascript/app/components/components.ts
@ ./src/main/javascript/app/app.angularjs.module.ts
@ ./src/main/javascript/flow-tests.ts

See also: https://github.com/JS-DevTools/coverage-istanbul-loader/blob/master/src/index.ts#L25

As described in this bug report on the Angular repo, when testing with code-coverage ng test --code-coverage, Devtools do not match the right files (for all non-spec files). So I can add a breakpoint in any *.spec.ts, but then when I step into the tested file the cursor is not at the right position within the file. It also mean I can't add breakpoint in non spec files.

angular/angular-cli#19084 (comment)

A working example for LCOV coverage with proper sourcemaps in an ng new Angular project would be very appreciated, since that use case has been blocked forever by the package this package was forked from.

EDIT: well, after hacking at it for a while, i can't reproduce the old problem which i thought was the fault of istanbul-instrumenter-loader. my LCOVs seem fine even without this package, and i'm not sure why.

Hello,

I'm facing an issue where my coverage report is not properly reflecting the actual bundle.
Code which is omitted thanks to tree shaking/minification is showing up as uncovered.

I'm using coverage-istanbul-loader, ts-loader and TerserPlugin for optimization.
devtool is set to source-map and sourceMap is enabled in both tsconfig and terserOptions.

I have been unable to find proper documentation on this topic so far, so any pointers would be appreciated.

Seeing issues of istanbul-instrument-loader, I changed my depencies just got blank file:

Here if my config:
karam.conf.js, use 'coverage-istanbul' reporter

 webpack: {
        mode: 'development',
        devtool: "inline-source-map",
        module: {
            rules: [
                {
                    test: /\.ts?$/,
                    // 指定源码位置
                    include: [path.join(__dirname, 'src')],
                    use: [
                        {
                            loader: "coverage-istanbul-loader",
                        },
                        {
                            loader: 'ts-loader',
                        },
                    ],
                    exclude: /node_modules/,
                }
            ],
        },
        resolve: {
            extensions: ['.ts', '.js', '.json']
        },
    },

tsconfig.json

 
{
  "compilerOptions": {
    "outDir": "./output",
    "target": "es2017",
    "module": "commonjs",
    "lib": ["es2015", "es2016", "es2017", "dom"],
    "allowJs": false,
    "jsx": "react",
    "declaration": true,
    "skipDefaultLibCheck": true,
    "skipLibCheck": true,
    "inlineSourceMap": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "noImplicitUseStrict": true,
    "noImplicitThis": true,
    "noUnusedLocals": false,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "baseUrl": ".",
  },
  "exclude": [
    "node_modules",
    "test",
    "lib"
  ]
}

The coverage report is not correct too:

Since I only tested 3 functional files, the right one is (using instrument-loader):