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
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-hookstest code is in the
testfolder, 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/**/*.purssource glob to my
test.dhallfile, but that doesn’t seem ideal because the
Test.Mainmodule name is already taken by the halogen hooks library. Thus,
spago testwill rerun halogen-hooks’ tests, not the halogen-hooks-extra tests. I can get around that by using
spago 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
testcode is moved into the
srcfolder, 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-specmakes a breaking change. Since
halogen-hookswould depend upon
specin this approach,
halogen-hookswould account for the breaking changes. Then, in the next
halogen-hooksrelease, it would need to make a breaking change, even though the main code that everyone uses in their projects never actually changed. Wuuuuuuut?