-
-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coverage with c8 and tsx reporting as 100% since version 4.3.0 #433
Comments
I have the same issue. FWIW, you can work around this by running tests on the built js output. If you have TypeScript generate .map files, then the CC output should look the same as before (i.e. reported on ts files rather than js files). Here's an example of the changes necessary (besides building with tsc): |
This comment has been minimized.
This comment has been minimized.
I haven't investigated this but I'm thinking this is as simple as removing this check so sourcemaps are always inlined: Line 23 in 8c77891
There will need to be tests though. PR welcome if anyone wants to tackle. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, I'm going to hide your comment because it doesn't lead to a solution in tsx. Seems like both versions of tsx in the reproduction doesn't work in the latest version of Node, but the reproduction still works fine with Node v20.10.0. I'm curious what happened between tsx v4.2.1 and v4.6.2 that broke c8 in Node v20.10.0. |
@privatenumber the generated sourcemap content could be different
|
You're right! I tested removing pnpm i 'privatenumber/tsx#npm/esbuild-sourcesContent' (Here's how to make a installable branch, if you're interested) I'll need to look into a way to add tests for this. |
This has been completed in the development repo. |
## Description - replaces c8 with node 'native' --experimental-test-coverage ## Motivation and Context c8 in our setup always returned 100% coverage for all things - which might have to do with an issue in tsx (see [tsx #433](privatenumber/tsx#433) ), but might just as well be caused by something unexpectedly breaking in de nodejs / v8 w.r.t. loader coverage. `--experimental-test-coverage` is not perfect either (i.c.w. tsx it's unstable on node > 20.12.2, and line numbers are off), but at least the coverage data we get is more realistic. ## How Has This Been Tested? - [x] green ci ## Screenshots ``` > tsx --experimental-test-coverage --test-reporter ./tools/dot-with-summary.reporter.js --test src/*.spec.ts src/**/*.spec.ts ................................................. 49 passing (1.420 ms) =============================== Coverage summary =============================== Branches : 97,89 % (93/95) NOK Functions : 100 % (38/38) Lines : 99,76 % (422/423) ================================================================================ Uncovered lines: /Users/sander/prg/js/watskeburt/src/git-primitives.ts:80 Uncovered branches: /Users/sander/prg/js/watskeburt/src/git-primitives.ts:79 /Users/sander/prg/js/watskeburt/src/main.ts:22 ``` ## Types of changes - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Documentation only change - [ ] Refactor (non-breaking change which fixes an issue without changing functionality) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Chore
🎉 This issue has been resolved in v4.10.4 If you appreciate this project, please consider supporting this project by sponsoring ❤️ 🙏 |
## [1.15.0](v1.14.0...v1.15.0) (2024-05-21) ### 🚀 Features * **game:** options hub ([#407](#407)) ([16dc0ba](16dc0ba)) ### 🐛 Bug Fixes * **accessibility:** nav and list issues ([#417](#417)) ([c2da1f1](c2da1f1)) ### 🧹 Chore * **deps:** bump @nuxt/test-utils from 3.12.1 to 3.13.0 in the nuxt group ([#409](#409)) ([2ce6348](2ce6348)) * **deps:** bump @nuxt/test-utils from 3.13.0 to 3.13.1 in the nuxt group ([#413](#413)) ([89ff57e](89ff57e)), closes [#849](#849) [#851](#851) [#849](#849) [#851](#851) [#845](#845) * **deps:** bump happy-dom from 14.10.1 to 14.10.2 ([#405](#405)) ([1c89b29](1c89b29)) * **deps:** bump happy-dom from 14.10.2 to 14.11.0 ([#408](#408)) ([12258c3](12258c3)) * **deps:** bump sass from 1.77.1 to 1.77.2 ([#411](#411)) ([9c047d3](9c047d3)) * **deps:** bump the eslint group with 2 updates ([#414](#414)) ([761b21e](761b21e)) * **deps:** bump the eslint group with 3 updates ([#403](#403)) ([20bc95e](20bc95e)) * **deps:** bump the eslint group with 3 updates ([#416](#416)) ([37a1346](37a1346)) * **deps:** bump tsx from 4.10.1 to 4.10.2 ([#404](#404)) ([616d779](616d779)) * **deps:** bump tsx from 4.10.2 to 4.10.4 ([#412](#412)) ([c6fc544](c6fc544)), closes [#18](#18) [privatenumber/tsx#433](privatenumber/tsx#433) [#18](#18) [#555](#555) * **deps:** bump tsx from 4.10.4 to 4.10.5 ([#415](#415)) ([5c37023](5c37023))
An observation that I find interesting to relate is that after To fix it, I just used c8's recommendation: /* c8 ignore next */
import type { SomeType } from '../some-type.js';
@privatenumber, thanks for this project and the fix 💙 |
Hi @privatenumber 👋🏼 😊 |
Acknowledgements
Minimal reproduction URL
https://github.com/OscarBarrett/tsx-coverage-issue
Version
v4.6.2
Node.js version
v20.10.0
Package manager
yarn
Operating system
Linux
Problem & Expected behavior
We use c8 and tsx together when running our test suites, and since tsx version 4.3.0 any file that is imported in our tests gets 100% coverage.
Locking to tsx 4.2.1, we get the expected coverage.
Assuming this is related to #405
Contributions
The text was updated successfully, but these errors were encountered: