Turfjs
Inline last-checks into @turf/turf's test script
Instead of having this be its own step, we can just run it as part of the tests turf-mask had an unused mkdirp dependency that it looked like we wanted to get rid of at some point @turf/turf wasn't reexporting @turf/directional-mean so I added that
@twelch and @mfedderly, can we have a time out before merging this change?
Looking at last-checks many of the tests seem to overlap with monorepo linting. Additionally they depend on the built JS files in dist/ which i'm hoping we can avoid generating for local and CI builds.
There may be benefits to keeping them in a separate step for the time being.
@smallsaucepan yeah we can definitely hold this one, I'm curious how you will avoid building on CI and still get typescript type checking done. The weird testing format in @turf/turf has always been somewhat overlapping with the capabilities of monorepolint, it predated when I brought in monorepolint to get things standardized across all of the packages years ago and never fully reconciled it all.
Thanks for that.
how you will avoid building on CI and still get typescript type checking done
The test:types target in each package runs a tsc --noEmit which should uncover any compile time TS errors. We can run that directly on the types.ts or index.ts file in each directory.
To be clear I'm not deep enough in the build workings to be able to contribute much to the discussion yet other than learn. I've been trying to only approve smaller build related PRs that don't seem to affect the larger deliberation you've both been having. Just to keep things incrementally improving. If this PR is more than that I apologize.
test:types target
That's actually really cool! My only two flags would be making sure that test:types exists everywhere, and that it really does trigger errors on build errors for itself and any packages it depends on if we need that behavior (I worry about something like skipLibCheck causing an issue).
@mfedderly,
- making sure that test:types exists everywhere
- it really does trigger errors on build errors for itself and any packages it depends on
Done, and done. Check out PR #2702