Here’s why source-directories matter.
Let’s say you find these three files (among others):
src/Foo/Helpers.elm
src/OtherFoo/Helpers.elm
src/Foo/Page/Foo/Helpers.elm
And you find this import (among) others:
import Foo.Helpers
You turn Foo.Helpers
into Foo/Helpers.elm
, and then do a “string contains” check on each file name. I understand where “contains” comes from – you don’t know the source directories (src/
in this case).
However, all the above files match Foo/Helpers.elm
, so all three count as used just from import Foo.Helpers
, which is incorrect. This can lead to some unused files not being detected.
Another way that unused files might not be detected, is if import Something
is inside comments and strings (both of which can be multiline!)
{- Commented out for now:
import Something.Cool
-}
templateCode = """
import Something.Cool
"""
A – luckily unlikely – way that your tool might remove too many files, is when import
statements have unusual formatting so that your tool does not extract them correctly:
-
It is legal to have a newline between
import
and the module name:import Something.Cool
Luckily, elm-format never does that.
-
It is legal to have comments between
import
and the module name:import{-{-{--}-}-}Something.Cool
Luckily, I’ve never seen Elm code with comments even near imports.
One final edge case thought – what happens if the code accidentally has a circular import? If 5 unused files import each other in a circle, they won’t be removed? And the user might not notice that circular import, since the files are unused so elm make
never runs on them.