The coverage location is not the original source location when the previous plugins transformed

[billowz]

Issue tracker is ONLY used for reporting bugs. Use stackoverflow for supporting issues and questions.

Expected Behavior

Coverage requires the sourcemap of the previous plugins to return to its original form

Current Behavior

The coverage points to code transformed by the previous plugins

Possible Solution

see #22, rollup/rollup#2983, the istanbul-lib-instrument require the inputSourceMap to maps the not instrumented code back to it's original form

Steps to Reproduce

fixtures/main.js:

export const foo = bar => (bar ? whatever.do() : whatever.stop());

rollup:

rollup .rollup({
        input: "fixtures/main.js",
        plugins: [
          babel({
            presets: [
              [
                "env",
                {
                  loose: true,
                  modules: false
                }
              ]
            ]
          }),
          istanbul()
        ]
      })
      .then(bundle =>
        bundle.generate({
          sourcemap: true,
          format: "iife",
          name: "test",
          globals: {
            whatever: "whatever"
          }
        })
      )

fixtures/main.js transformed by babel:

export var foo = function foo(bar) {
  return bar ? whatever.do() : whatever.stop();
};

The instrument uses transformed code from babel

[artberri]

Hi @billowz

First of all, thank you for taking the time to review the new version and open the issue.

I've double checked the issue and your proposed solution in #22. I think that you are asking for a fix that I've implemented in #25. Could you review it?

Anyway, before merging it, I want to understand why it is needed and why are you instrumenting the code after transforming it with babel. I mean, I think that a solution to your problem could be to instrument the code before transforming it:

/* ... */ 
        plugins: [
          istanbul({ /* ... */ }),
          babel({ /* ... */ })
        ]
/* ... */ 

If you do so, I think that you will have the coverage pointing to the proper lines. Why are you instrumenting at the end?

In addition, I've been doing some tests with the sample project in examples/karma. If I apply the fix (using the code in sourcemap-fix-24) and your approach of instrumenting the code at the end, I'm getting these results:

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	77.78	75	100	77.78
index.js	77.78	75	100	77.78	7,17

Which is wrong because, as you can see the example, it is not covering the 100% of the functions.

But if I use the current 3.0.0 version and I instrumenting the code at the beginning (being istanbul the first transformation plugin) I get the following:

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	77.78	75	66.67	77.78
index.js	77.78	75	66.67	77.78	7,17

Which is more accurate and it points to the proper uncovered lines also.

Could you help me understanding why I should make the change?

[DamienChing]

@artberri svelte code must be preprocessed with rollup-plugin-svelte before being instrumented, hence the need for this.

[tifrel]

I have a similar issue when compiling TypeScript. I feel the source maps always correspond to the compiled JS, not the TS source. I also tried multiple config options (including instrumenting first, then compiling), but nothing seems to help.

[Tommos0]

I have the same problem with a react/typescript/vite project, and wrote my own plugin based on rollup-plugin-istanbul: https://gist.github.com/Tommos0/217c8457f40be60434aecf1f3f23c7a3#file-istanbul-plugin-ts

[powerdong]

@tifrel I also have this problem, have you solved it?

[tifrel]

@powerdong Yes and no. The code is on my old machine, so I cannot check it right now. I played around with istanbul + TS + gulp. It turned out that there was one specific combination of options which would do, IIRC instrumenting the TS and then compiling without TS source maps. Didn't get it to work with rollup though, but you might find a way (let me know, still interested)

[artberri]

I'll add the fix in the next version that will be published during this week.