Test for tree shaking

[skeate]

No idea how to do this at the moment but we should make some tests to ensure that tree shaking works (and doesn't stop working accidentally)

(related to #187)

[jacob-alford]

Do you think we could jest mock certain modules to essentially nullify them, so any import would cause an error?

[skeate]

That might not be sufficient; if they are imported but do nothing (or at least nothing a "null" module might catch) then it's still a problem.

[skeate]

Idea 2: Actually write a small webpack-built program (or a few programs) which test different imports and check the output for certain things that shouldn't be there (e.g. if it only imports Arbitrary then we should probably not see the string TaskDecoder anywhere in the output)

[jacob-alford]

This would be pretty neat, we could write scripts to test tree-shakability, and write in a reader-like fashion to be able to test any number of tools. How hard do you think this would be? Should this be for 1.0?

[skeate]

Idea 3: Import graph analysis. This is pretty straightforward and I think relatively easy to do in a Jest test, but it might not reflect the reality of the actual tree-shaking performed by build tools.

[jacob-alford]

Container idea:

Github action to spin up a toy project with a ts-node script that only has fp-ts/io-ts as a dep (not fast-check) and tries to run each of the interpreters (besides arbitrary)

[skeate]

what is the difference between this and "Idea 2"? (genuine question)

[jacob-alford]

It's less about webpack and more about adding a Github action for it