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
Set up codecov properly for this repo #838
Comments
#852 is related to this issue |
Have we tried looking at this issue again since the move to GitHub Actions?
It seems like we already pass a |
👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. |
Not sure what happened but codecov seems very confused about this repo - as if it is not set up at all. Probably need to revisit code coverage generation and reporting for this repo overall. Will try to take a look once major new versions of all the sub-packages in this repo are released (node 18+ only). |
Description
Currently, when tests are run within each package, they run within the context of only that package. That means that all file paths in the coverage report start at the package root. We use a separate flags, which enable us to evaluate changes to coverage in each package separately (this shows up in the PR comments from the codecov bot). However, there are common file heirarchies that create naming conflicts. For example, every package has a
src/index.ts
, so codecov's report for that filename is meaningless (it acts as a bucket with the mixed report of thesrc/index.ts
from each package). This also means there's no easy way (outside of a PR) to check the overall coverage of a specific package.Ideally, each package would run
nyc
from the repo root (as opposed to the package root) so that the file paths no longer overlap. This might also give us the opportunity to remove the duplicated.nycrc.json
files from the individual package and have only one in the root. However, the test scripts must provide some means of filtering the included files to only those that matter for the package being tested. Can.nycrc.json
files cascade and/or extend one another? Can command line configuration apply over.nycrc.json
configuration? Worth looking into.Requirements (place an
x
in each of the[ ]
)The text was updated successfully, but these errors were encountered: