-
Notifications
You must be signed in to change notification settings - Fork 67
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
Fix coverage #100
Fix coverage #100
Conversation
sebinsua
commented
Sep 17, 2020
•
edited
Loading
edited
- Fixes coverage on the internal project we're currently working with.
- Come up with a better commit message.
🦋 Changeset is good to goLatest commit: 236f059 We got this. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
8a009a4
to
cf51cbd
Compare
setupFilesAfterEnv: globby.sync( | ||
[`${absolutePackagesPath}/**/src/setupTests.{js,ts}`], | ||
{ cwd: process.cwd() }, | ||
), |
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.
This is actually not coverage related.
I noticed that CRA would only load the setupTests.{js,ts}
of one application without changing this.
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.
is it correct to load all setupTests
though? what if they're conflicting somehow?
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.
Hm, I could change this. I somewhat agree with you.
However, if I change this there is only one application which can contain this setupTests.ts
file. That's a bit confusing since it means that one application is more important than all of the others, and there's nothing to suggest that this is the case.
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.
Perhaps we should totally change where these files are?
CRA is what configured them to be found in {app}/src/setupTests.{ts,js}
and {app}/src/setupProxy.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.
yeah this one is tricky. it's almost as if setupTests
should be conditionally included based on the path of the test.. not sure if possible since setupTests
is like a global thing.
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.
Yeah, this deserves an issue I think. It's likely that applications will each want their own setupTests.
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.
Following which, it's likely each app should probably run it's own jest command.
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.
Another thought is to have a top-level (default) setupTests
, but also allow apps to provide a stripped down version of Jest config with allowed keys that allow you to either replace setupTests
or return an array of [originalSetupTests, customSetupTests]
.
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 don't think we should allow for changing the jest config. If the complication is that it'll be hard for a dev to write a command that runs all apps' jest command at once, we could do that with modular test
for them. But either way, having an app define src/setupTests.js stays.
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.
Yammered on here: #103
rootDir: absolutePackagesPath, | ||
roots: ['<rootDir>'], | ||
testMatch: [ | ||
'**/src/**/__tests__/**/*.{js,ts,tsx}', |
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.
what's the leading ../
for?
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.
nvm, it seems like this is now **/src
, although maybe it should be *
? packages/*/src
instead of allowing arbitrary nesting
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.
LOL, yes, that was a mistake.
I tested the code internally but then did the open-source contribution via my own machine and did that by accident...
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.
maybe it should be
*
?
Yes, I'll go and check to see if this works.
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 turns out it couldn't be just a *
because testMatches
seems to not be in relation to <rootDir>
(it's just a basic glob) while on the other hand collectCoverageFrom
is by default.
However, I was able to prefix it with <rootDir>/*
which I think is even more clear. And, even though collectCoverageFrom
is by default prefixed by <rootDir>
it ignores this if use it as a prefix so I was able to make them consistent with each other.
collectCoverageFrom: ['**/src/**/*.{js,ts,tsx}', '!**/*.d.ts'], | ||
setupFilesAfterEnv: globby.sync( | ||
[`${absolutePackagesPath}/**/src/setupTests.{js,ts}`], | ||
{ cwd: process.cwd() }, |
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.
is this not the default?
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 errored without passing it in. This also seemed weird to me...
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.
https://github.com/mrmlnc/fast-glob#cwd i believe globby
uses fast-glob
under the hood. weird.
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 seem to have ran into this, which is obviously fixed, however I can see that installing CRA also installs old versions of globby
so that is probably why.
Actually, since I worked within the node_modules/
directory without installing globby
myself it's possible that I picked up one of the old versions, and that since within this PR I'm explictly installing a new version, I'd not run into the problem once this is published.
(I will keep it 'just in case'.)
'**/src/**/*.{spec,test}.{js,ts,tsx}', | ||
], | ||
coverageDirectory: path.resolve(modularRoot, 'coverage'), | ||
collectCoverageFrom: ['**/src/**/*.{js,ts,tsx}', '!**/*.d.ts'], |
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.
'**/src/**/__tests__/**/*.{js,ts,tsx}', | ||
'**/src/**/*.{spec,test}.{js,ts,tsx}', | ||
], | ||
coverageDirectory: path.resolve(modularRoot, 'coverage'), |
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 might as well set this here, rather than needing to via the CLI.
FYI, my assumption is that there is a shared coverage report for the whole application. I don't think people would want to have to run jest
for each application separately -- but we can change this at a later date if we need to...
return { | ||
...jestConfig, | ||
rootDir: absolutePackagesPath, | ||
roots: ['<rootDir>'], |
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.
This is actually the default for this property. CRA customizes it by postfixing src/
to it, but since <rootDir>
would be the packages/
directory that would be wrong.
My other option was to get multiple roots by detecting every directory in the workspace packages/
directory but that seems overly complicated.
configure(jestConfig) { | ||
return { | ||
...jestConfig, | ||
rootDir: absolutePackagesPath, |
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.
Tests are run in relation to the absolute packages/
directory instead of the modular root.
This makes sense to me since all of the application code would belong to this directory, and otherwise I'd need to prefix lots of these other properties with packages/
.
b555d16
to
61eb513
Compare
you can just come up with a detailed changeset instead. |
61eb513
to
236f059
Compare
/cc @kknoerz |