-
Notifications
You must be signed in to change notification settings - Fork 217
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
Enable coverage reporting #3100
Conversation
f243786
to
80024ca
Compare
We now break the deadlock as described in #527 (comment) by using standard-things/esm#877
After the ESM patch in this PR:
|
0eb1573
to
bbd7554
Compare
This is about as good as coverage is going to get until the caveats in |
COVERAGE.md
Outdated
well as implementing source maps in all of our source-to-source transforms (such | ||
as `@agoric/bundle-source`, `@agoric/transform-metering`, and | ||
`@agoric/static-module-record`), the coverage line numbers will be out-of-sync | ||
with reality. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a pretty big caveat. Do the percentages still seem to be accurate? Is there a human-manageable way to get from the line numbers this emits to the actual source code? Or should we preface all the reports with a note that we should ignore the line numbers entirely and just look at the percentages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, does this affect basic unit tests that use -r esm
(like everything we do) but do not use bundle-source
or import-bundle
? I'd be happy with getting accurate coverage for library code that we can test outside the context of swingset.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the basic plan is: if we adopt the Node.js esm
package patch I made in this PR, we can do a gradual bottom-up migration of our packages to be dual -r esm
and Node.js ESM (nesm
) compatible.
I've changed the HTML file generation only to coverage-test the packages which can support nesm and explicitly implement a test:c8
script. Currently only swing-store-simple
implements that (and incidentally, also supports resm
).
@@ -82,6 +82,15 @@ | |||
"patch-package": "patch-package", | |||
"build-xs-worker": "cd packages/xs-vat-worker && yarn build:xs-lin" | |||
}, | |||
"ava": { | |||
"files": [ | |||
"packages/*/test/**/test-*.js" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this interfere with / override ava
settings in individual package's yarn test
?
It looks like this is meant for use by a top-level yarn test
which runs tests in all packages in parallel. When I last looked into doing that, I got stuck on the different require
options we needed for different sets of tests (in particular importing install-ses
, or install-metering-and-ses
). Did you find a solution for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this interfere with / override
ava
settings in individual package'syarn test
?
Only when run from the top level. If yarn test
is run in the specific package, the package's settings will take effect.
It looks like this is meant for use by a top-level
yarn test
which runs tests in all packages in parallel. When I last looked into doing that, I got stuck on the differentrequire
options we needed for different sets of tests (in particular importinginstall-ses
, orinstall-metering-and-ses
). Did you find a solution for that?
Yes. It turns out we only use "require"
for two modules: "esm"
(which appears in basically every "ava"
config), and an enzyme setup script (only used in packages/ui-components/package.json
). So, the situation is not nearly as grim.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think @dtribble was once keen on using the AVA config to jam a -r @agoric/install-ses
into e.g. all zoe tests, to avoid adding a line to the top of every test file, and that was going to push us to e.g. move all @agoric/install-metering-and-ses
tests into one directory, and have two top-level AVA calls (with one set of -r
options each). I think we talked him down from that :).
I've got nodeArguments: [ "--expose-gc" ]
in the SwingSet package.json, to enable GC controls while testing. We may need to move that to the top-level package.json to make sure swingset tests work both from the top level and from packages/SwingSet
(and also when e.g. Zoe does swingset-based tests, although if they're short enough, we can probably tolerate the inability to provoke GC).
@@ -5,14 +5,14 @@ | |||
"parsers": { | |||
"js": "mjs" | |||
}, | |||
"type": "module", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh, does this work? I'm suspicious that this PR changes the type for this one package and none of the others. @kriskowal does this interact well/badly with the other ESM/-r ESM
changes you're planning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does #527 (comment) answer these questions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh, does this work?
Yep!
I'm suspicious that this PR changes the type for this one package and none of the others.
I did that to demonstrate that incremental, bottom-up support of NESM is possible without having to throw away -r esm
.
@kriskowal does this interact well/badly with the other ESM/
-r ESM
changes you're planning?
In talking with @kriskowal, this is a fine step forward.
@@ -1,9 +1,9 @@ | |||
diff --git a/node_modules/esm/esm/loader.js b/node_modules/esm/esm/loader.js | |||
index e0bbca5..8710025 100644 | |||
index e0bbca5..0b5bfe8 100644 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised this patch changed, since we didn't change the version of esm
that we're using. Is this intentional? Same for the other patch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised this patch changed, since we didn't change the version of
esm
that we're using. Is this intentional?
Yes, as discussed in #527 (comment)
Same for the other patch.
nyc
is no longer referenced, so I needed to remove that patch or patch-package
complains about its absence.
50a0c92
to
9f83426
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be good to also change scripts/repackage.sh
to reflect this new mode.
COVERAGE.md
Outdated
open coverage/html/index.html | ||
``` | ||
|
||
## NESM Support |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s spell this “Node.js ESM” formally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
How is your fork of |
We're patching upstream esm with |
77d71db
to
fe3ef2d
Compare
fe3ef2d
to
856abbe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, as long the top-level yarn test
provides the right set of AVA options to the right packages (I'm specifically looking at nodeArguments: [ "--expose-gc" ]
for SwingSet, as I'm about to add a test that depends upon it), I'm in.
1a7f906
to
464b464
Compare
I added this to SwingSet/package.json in commit d4bc617 (PR #3136). However I overlooked the fact that #3100 had already landed, which changed the top-level `yarn test` from one that just did a (sequential) `yarn workspaces test`, testing one package at a time with whatever the local `package.json` said to do, to one that does a (parallel) `ava` invocation, which does all packages at the same time but ignores the local `package.json` settings. We need to include `--expose-gc` in the `nodeArguments` in the top-level package.json to make sure the parallel form give the correct arguments when SwingSet's turn comes around (as well as other packages which benefit from enabling GC but don't have tests which directly assert that it can be done).
I added this to SwingSet/package.json in commit d4bc617 (PR #3136). However I overlooked the fact that #3100 had already landed, which changed the top-level `yarn test` from one that just did a (sequential) `yarn workspaces test`, testing one package at a time with whatever the local `package.json` said to do, to one that does a (parallel) `ava` invocation, which does all packages at the same time but ignores the local `package.json` settings. We need to include `--expose-gc` in the `nodeArguments` in the top-level package.json to make sure the parallel form give the correct arguments when SwingSet's turn comes around (as well as other packages which benefit from enabling GC but don't have tests which directly assert that it can be done).
See COVERAGE.md for more information.