I’m going to bed, but I thought I’d post this to gather some thoughts. The corresponding issue is here: https://github.com/thomashoneyman/purescript-halogen-hooks/issues/24
So, purescript-halogen-hooks
defines code in the repo’s src
folder. To test it, Thomas wrote code in the repo’s test
folder. Here’s the problem. If I want to use the test code in the halogen-hooks library to test other hooks in purescript-halogen-hooks-extra
, I run into a quandry.
- Since the
halogen-hooks
test code is in thetest
folder, Spago doesn’t pick it up by default when I depend upon the halogen-hooks library (i.e. the source globs that Spago adds by default is.spago/library/version/src/**/*.purs
. I can get around this by adding a.spago/halogen-hooks/*/test/**/*.purs
source glob to mytest.dhall
file, but that doesn’t seem ideal because theTest.Main
module name is already taken by the halogen hooks library. Thus,spago test
will rerun halogen-hooks’ tests, not the halogen-hooks-extra tests. I can get around that by usingspago test --main Test.Hooks.Extra.Main
, but it seems like there should be a better way. - If the test code is moved into its own repo, the next problem is a circular dependency. The hooks library would define the main code, the test repo would define the main test code, and the hooks library would use the main test code to test itself. I guess this could actually work. If Spago supported the concept of targets (https://github.com/purescript/spago/issues/416#issuecomment-613634984), then this would likely be bearable, too. However, we wouldn’t want to do this because there is one function in the test code that “just so happens” to be very similar to the real source code. If the source code’s implementation of that function changes, so would the tests code’s implementation. That is easier to track if they are within the same repo.
- If the
test
code is moved into thesrc
folder, which solves both of the above problems, the main code is now depending upon testing libraries (e.g.purescript-spec
), which seems weird. Consider this situation.purescript-spec
makes a breaking change. Sincehalogen-hooks
would depend uponspec
in this approach,halogen-hooks
would account for the breaking changes. Then, in the nexthalogen-hooks
release, it would need to make a breaking change, even though the main code that everyone uses in their projects never actually changed. Wuuuuuuut?