jaredpalmer / tsdx

Zero-config CLI for TypeScript package development
https://tsdx.io
MIT License
11.28k stars 507 forks source link

Add Integration Tests #627

Closed agilgur5 closed 4 years ago

agilgur5 commented 4 years ago

This is quite a big PR as it refactors a bunch of the test set-up to handle two different types of tests, as well as adds integration tests for tiny-invariant, rollup-plugin-postcss, styled-components, and regeneratorRuntime. Fixes #481

I initially tried to have the integration tests have their own package.json and node_modules, as the build-withConfig folder had before (and with a new CI workflow with working-directory set to the integration test dir), but this proved extremely confusing and very time-consuming to deal with. It basically requires that scripts, like tests, run from the integration test dir, as if they run from root, they won't read the node_modules (node scans upward, so from the integration test dir, it'll get the integration deps and the TSDX deps, but the opposite doesn't work). And trying to run scripts from there causes lots of inconsistencies all over the place, so I just scrapped that idea. Open to ideas on better integration testing structures, but the other option proved completely not worth the time, so don't want to spend a ton more time trying to get something else to work either.

Also found some integration failures all over the place while adding this, welp 😕 These include:

agilgur5 commented 4 years ago

Ok fixing the conflicts with #582 in yarn.lock was not easy 😕 . But done now, so this is ready to merge. Should go in before #525 , so need to review this soon

Realized I might be able to use yarn workspaces to have the integration-tests dir split out. Then TSDX can still be used (and as tsdx in scripts), but shared devDeps might not work correctly unless we put them in root similar to Lerna. I feel like that's really involved prior to having a monorepo (see #634, #635), but that might correctly describe the relationship between TSDX and its integrations; i.e. that it's a separate dependency.

Hmmmmmm... Then again, the relationship between integration tests and E2E tests is actually the same -- they both should be separate workspaces with tsdx used inside of them. So can hold off on this for a bit I guess, since will be refactoring the E2E to be unit tests eventually (and so might do the same for integration?)

agilgur5 commented 4 years ago