Add support for gjs/gts files#405
Add support for gjs/gts files#405RobbieTheWagner merged 1 commit intoember-cli-code-coverage:masterfrom
Conversation
|
@kategengler seems like the error reported in CI was a known PNPM issue pnpm/pnpm#5056 which was fixed with the latest pnpm version. I updated the version for CI and Volta do you mind to rerun the workflow and see if it fixes it? |
|
@RobbieTheWagner can you or maybe some other maintainer please review this? |
| "@embroider/webpack": embroiderVersion | ||
| }); | ||
|
|
||
| await execa('rm', ['-rf', '.embroider'], { cwd: buildPath, env }); |
There was a problem hiding this comment.
Can you please explain why this was needed?
There was a problem hiding this comment.
@RobbieTheWagner so currently we are testing against emroider/core versions from 0 to 3.
During each build it creates a .embroider folder, but seems like when we run a test for a newer version it will try to re-use the .embrodier folder generated by the previous test and it was leading to some unpredictability.
For example there is a problem with babel plugin serialization in v3 that I solved here using this as a reference, but it would still fail on tests w/o cleaning up .embroider because it was relying on what was generated by the previous embroider version
So basically all I did was make sure the tests are totally isolated from each other and don't affect each other
There was a problem hiding this comment.
@vstefanovic97 that's good knowledge! Mind to drop a comment in the code with this explanation for future readers?
There was a problem hiding this comment.
Added a comment in the code about this @SergeAstapov, @RobbieTheWagner
|
@RobbieTheWagner sorry to bother you again, any progress with the review? |
|
@vstefanovic97 I really don't have enough knowledge about how this addon works to review. @SergeAstapov do you feel comfortable reviewing? |
SergeAstapov
left a comment
There was a problem hiding this comment.
@RobbieTheWagner Thank you for pinging me!
Functionally, this looks great to me! I'd suggest we spend a bit more effort on documentation part to make clear for ppl who'd like to start using this and for ppl who would need to understand code in future
| "test": "vitest" | ||
| }, | ||
| "devDependencies": { | ||
| "@babel/core": "^7.23.9", |
There was a problem hiding this comment.
@vstefanovic97 why is this needed in the root of monorepo? I guess each package that needs it should declare such kind of dependency.
There was a problem hiding this comment.
ah, now I see - test-packages folder contains both vite tests and test packages.
IMO seems confusing but for sure we should follow existing structure in this PR.
| return; | ||
| } | ||
|
|
||
| path.traverse(gjsGtsTemplateIgnoreVisitor, state); // we need to do early traverse to make sure this runs before istanbuls plugin |
There was a problem hiding this comment.
| path.traverse(gjsGtsTemplateIgnoreVisitor, state); // we need to do early traverse to make sure this runs before istanbuls plugin | |
| // we need to do early traverse to make sure this runs before istanbuls plugin | |
| path.traverse(gjsGtsTemplateIgnoreVisitor, state); |
just a tiny bit more readable
packages/ember-cli-code-coverage/lib/gjs-gts-istanbul-ignore-template-plugin.js
Show resolved
Hide resolved
| }, | ||
| ], | ||
| ...require('ember-cli-code-coverage').buildBabelPlugin({ | ||
| extension: ['.gjs', '.gts', '.js', '.ts', '.mts', '.cts', '.cjs', '.mjs'], |
There was a problem hiding this comment.
@vstefanovic97 this matches the default value so we can probably skip this?
| addon.hbs(), | ||
|
|
||
| // Ensure that .gjs files are properly integrated as Javascript | ||
| addon.gjs({ inline_source_map: true }), |
There was a problem hiding this comment.
@vstefanovic97 looks like it's worth to document this option in readme.
Maybe, I'm thinking we need a section with steps how to setup test coverage in v2 addons.
There was a problem hiding this comment.
@SergeAstapov I agree with you on this one, but I thinking documantation for setting up coverage in a v2 addon can be a separate PR as it's not tied to gjs/gts. I will rise a new PR for that
|
@RobbieTheWagner mind to rerun the workflow? |
|
@RobbieTheWagner looks like I had deleted something by accident, I fixed it now, mind running again? This time I think it will pass. |
|
|
||
| - `excludes`: Defaults to `['*/mirage/**/*']`. An array of globs to exclude from instrumentation. Useful to exclude files from coverage statistics. | ||
|
|
||
| - `extension`: Defaults to `['.gjs', '.gts', '.js', '.ts', '.cjs', '.mjs', '.mts', '.cts']`. Tell Istanbul to instrument only files with the provided extensions. |
There was a problem hiding this comment.
@vstefanovic97 should this actually be
| - `extension`: Defaults to `['.gjs', '.gts', '.js', '.ts', '.cjs', '.mjs', '.mts', '.cts']`. Tell Istanbul to instrument only files with the provided extensions. | |
| - `extensions`: Defaults to `['.gjs', '.gts', '.js', '.ts', '.cjs', '.mjs', '.mts', '.cts']`. Tells Istanbul to instrument only files with the provided extensions. |
There was a problem hiding this comment.
@SergeAstapov well in the code it really is extension reason for this is I decided to keep it the same as the option in Isntabul since it too is singular
c08c8c7 to
564962e
Compare
SergeAstapov
left a comment
There was a problem hiding this comment.
if you ask me, this looks great! Thank you @vstefanovic97 for working on this! cc @RobbieTheWagner @kategengler
RobbieTheWagner
left a comment
There was a problem hiding this comment.
If @SergeAstapov says this looks good, that is good enough for me 👍
Update pnpm version to fix invalid string error Fix emroider comparibility bump @embroider/addon-dev and assert sorcemap remap is working Add a comment why we need to cleanup .embroider folder between test runs Improve docs and add more comment explanations remove explicit extensions from test app bring back babel transpilation plugin Fix type Co-authored-by: Sergey Astapov <SergeAstapov@gmail.com> Fix typo 2 Co-authored-by: Sergey Astapov <SergeAstapov@gmail.com>
564962e to
c568ae9
Compare
|
@RobbieTheWagner mind to run again (I think this will be the final time)? I changed test name but forgot to update the snapshot |
|
@RobbieTheWagner, @SergeAstapov can we merge this and create a new minor release? |
|
IMO yes, we are good to go, but I don't have permissions here. |
|
After updating to this version I am now getting no coverage directory being created at all. Anything else I might have to do to configure? I did already have all the configurations from the readme in place for the prior version. |
|
@cah-brian-gantzler there should be no additional config required for it to work. Were you on Also if you can come up with a minimal reproduction I could also try to debug it |
|
was on 2.0.3 Since its in my app, doubt and will prob work with a new app, not sure where to start on a minimal not knowing what the problem is. Will experiment some. Its weird that it produces NO coverage at all though. Will also revert back and make sure it still produces then. Did last time I asked, but that was a couple weeks ago, was waiting for this update |
|
@vstefanovic97 must have been a glitch. Now produces COVERAGE directory, however no .gjs or .gts files appears appear (same as before) I checked to ensure I had the correct package in my I found I also picked up Lastly I have my |
|
@cah-brian-gantzler can you build the app with Here is an example of what istanbul should do to the code, if you aren't familiar Maybe also it's worth checking if you have source maps turned on for your tests Let's first check this then we can narrow it down further. Also I got some feedback here that it works #392 (comment) so maybe what you are seeing is some edge case, but we will try to figure it out and fix :D |
|
@vstefanovic97 Thanks, I do know what instrumented code looks like. I did the build, but couldnt really find the code in the asset chunks, no sure how to do that. I put a debugger statement in the code in the .gts and ran the tests, the code was definitely instrumented. No change on the output in coverage. I do not have the source maps turned on for template imports. The read me says it might be useful, not required. If it is required to get correct line numbers, then I would say the docs should be updated to say required. Also says should not be enabled for production. Should prob give example on how to do that, most people wouldnt know. End result though. Code is instrumented, source maps now turned on for template imports (as above), no change in output. Any file that has a .gjs or .gts does not appear in code coverage. On a side note, for a long time the code that is in the coverage has always been off by one line. It still is. |
|
@cah-brian-gantzler this looks to be an embroider + ember-cli-code-coverage with gjs/gts issue I was able to reproduce with a band new embroider app. For now can you try to add to your |
| const IstanbulPlugin = require.resolve('babel-plugin-istanbul'); | ||
| return [[IstanbulPlugin, { cwd, include: '**/*', exclude }]]; | ||
| return [ | ||
| // String lookup is needed to workaround https://github.com/embroider-build/embroider/issues/1525 |
There was a problem hiding this comment.
As it turns out... We're going to require string lookup eventually, and forbid passing JS references.
JS references are not parallizable, but string references are! (it's a babel thing 🤷 )
There was a problem hiding this comment.
hey @NullVoxPopuli are there any problems or situations where this string lookup might not work?
I just tried this out on a new embroider app, I'm investigating #407 and I don't get any errors but it seems like that plugin isn't running
There was a problem hiding this comment.
one thing you could try is using a resolved string, so you get the absolute path of the plugin for "this instance of ember-cli-code-coverage".
path.resolve('the-string-you-have'); // returns absolute string, so no matter who is requiring, their resolve isn't local to who is doing the requiring
So to sum it up the steps in this PR are:
When working with already transpiled code, that has sourcemaps included (inline or in separate file) in order for the lines to be correct we actually need to use istanbul-lib-source-maps to remap the coverage to the correct source code.
This is actually needed since when we build v2 addons we already transpile the code from
gjs/gtstots/jsfirst and we run babel on the already transpiled code, so we need to remap the coverage to the original source code.Disclaimer: gts/gjs->js/ts transpilation doesn't generate sourcemaps at the moment but there is a PR open which will enable it embroider-build/content-tag#62
evalmethod from the coverage reportBecause we instrument already transpiled code we end up instrumenting some method that shouldn't be instrumented, like for example
gets instrumented to:
Because istanbul instruments the
evalmethod it will report as uncovered in tests and also it skews coverage percentages, so we want it to not instrument this, for this I created a small babel plugin that will add istanbul ignore lines and run before istanbuls babel plugin.Include
.gjs/.gtsextensions in istanbulextensionoption by default so instrumentation will work on these filesWrite tests (create a v2 addon with gjs/gts where we build it with coverage and then tests the coverage with snapshots)
Lines in the snapshots coverage will still be offset until Add js/rust bindings for inline source map generation embroider-build/content-tag#62 is fixed and
we update the test app with the change