#227: Webpack code coverage support

[gtrombitas]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• New test runner
• Documentation
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

If you are adding a new test runner, have you...? (check all)

• Created an issue first?
• Registered it in /packages/base/runners.json?
• Added it to /README.md?
• Included one test that runs baseline.spec.vue?
• Added and updated documentation?
• Included a recipe folder with properly building quasar project?

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to the dev branch and not the master branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• It's been tested on Windows
• It's been tested on Linux
• It's been tested on MacOS
• Any necessary documentation has been added or updated in the docs (for faster update click on "Suggest an edit on GitHub" at bottom of page) or explained in the PR's description.

If adding a new feature, the PR's description includes:

• The modification introduces Webpack support for e2e-cypress package.

Other information:

• Instead of istanbul-instrumenter-loader package coverage-istanbul-loader was used to instrument code coverage
• The modification can be tested in test-project-webpack after following the instructions:

add @cypress/code-coverage according to this link (babel-plugin-istanbul isn't needed here because it's bundled with coverage-istanbul-loader.

add "code-coverage" option to quasar.extensions.json

"@quasar/testing-e2e-cypress": {
    "options": [
      "scripts",
      "typescript",
      "code-coverage"
    ]
  }

add nyc settings in the end of package.json

"nyc": {
    "temp-dir": "temp/.nyc_output",
    "include": [
      "src/**"
    ],
    "extension": [
      ".js",
      ".ts",
      ".vue"
    ],
    "report-dir": "test/cypress/coverage"
  }

execute sync:cypress npm script in test-project-webpack project

[gtrombitas]

@IlCallo When I've tried then hasWebpack condition was undefined. How can I set it according to the project's setting?

[IlCallo]

hasWebpack is undefined into q/app projects, but should be defined into all others
We could actually just remove hasWebpack and only rely on hasVite: if hasVite is false or undefined, then the project will automatically be webpack-based

[IlCallo]

Remember that the Cypress AE devDeps are the ones which are used into dev phase of the app extension, while packages which must be used into userland project must go into the app extension normal dependencies

So this package should be moved to dependencies

[gtrombitas]

Okay, I fixed it.

[IlCallo]

hasWebpack is undefined into q/app projects, but should be defined into all others
We could actually just remove hasWebpack and only rely on hasVite: if hasVite is false or undefined, then the project will automatically be webpack-based

[IlCallo]

This seems off, the include (provided the exclude isn't enough on its own) should be relative the the user folder, not to this AE location

[gtrombitas]

I removed include property and I extended exlcude with .quasar folder. Now it seems to be working with this setting.

[IlCallo]

Thanks for the contribution :)
I don't have time to test it right now, but I left some comments on what seems to be off at a first glance

[gtrombitas]

@IlCallo I fixed the requested changes please check them.

[maiolica]

hi @gtrombitas, and thanks for the PR, I have run some tests on it.
Coverage of .ts files is perfect, but .vue files seem to have some issues, it seems all files are getting the exact same coverage, with the same uncovered block position (see screens).

[gtrombitas]

@maiolica Thank you for the review and testing effort. Unfortunately I couldn't find any other solutions to handle .vue file instrumentation better.
I opened an issue to coverage-istanbul-loader library: link
Hopefully they can advise a concrete solution or a workaround for this problem.

[IlCallo]

I'm regularly checking that issue, but the project seems abandoned since 2020
The whole Instanbul ecosystem seems freezed in time right now

Is there any reliable alternative into JS ecosystem?

[gtrombitas]

Thanks for the sync-up. Yes, I have seen the same thing at Istanbul repo.
Unfortunately I'm not familiar with any other alternatives to this library.
When I have a little time for it then I'll try to look into some other libs. If something already exists at all...