-
-
Notifications
You must be signed in to change notification settings - Fork 28
Description
This is about elm-test tests which are colocated with the source tree. So for example, following the convention of having an EverySet.ExtraTest
module next to an EverySet.Extra
module. These modules often contain imports to test dependencies that are not in the normal elm dependencies.
Expected Behavior
What I would expect is one of two things: Either the imports never correctly resolve in these files, which would be a bummer but understandable, or they always resolve.
Current Behavior
Instead, when I open one of these files or start editing in one that is currently saved, the extension shows errors as if the test dependencies were not found, but once I save the file, these errors disappear if there are no other problems with my code. This feels a bit inconsistent and always trips me up because the files switch between "fine" and "oh my god what did you do" constantly.
Possible Solution
The current behavior suggests that there is already some special logic to decide whether something is a test file or not. I do not have any concrete fix suggestions, but if this logic is not applied while the file is being edited, changing that might help
Context
We've recently added tests to our elm application at work, which is awkwardly structured because of the rest of the application. That means we cannot have a simple tests
folder with all the elm tests in it, and where this folder would be is sadly not configurable. We have instead opted to colocate the tests (which might make more sense from a reading perspective anyway). This works perfectly on the elm-test side, but leads to the IDE issues mentioned above.
Your Environment
- Version used: v2.6.0
- Editor name and version (e.g. VSCode 1.36.1): VSCode 1.75.0
- Environment name and version (e.g. node.js 5.4): elm 0.19.1-5, nodejs v18.4.0, elm-test 0.19.1-revision11, all running inside a Debian docker container connected via vscode remote containers
- Operating System and version: Fedora r37 on the host, Debian bullseye in the container