- Run
elm init
at the top-level (in the directory containing your separate Elm apps), creating a newelm.json
- If using elm-watch, run
elm-watch init
, creating a newelm-watch.json
- For each Elm app, open its
elm.json
and :- take the list of direct dependencies, install them all in your new
elm.json
- preferably using
elm-json
(although I don’t remember what doesn’t work with regularelm install
) - don’t worry about dependencies that are already installed, it will just ignore them. It’s safer to just mechanically copy them all.
- I guess you can encounter conflicts between dependencies of different versions. If that’s the case, you will have to decide on one version, and update code accordingly.
- preferably using
- do the same for test dependencies
- take the list of source-directories, add them to your new
elm.json
(usually something likemy-app/src
)- be careful to adapt the paths since you’re moving to the parent directory
- remove
elm.json
in the subfolder - run
elm make --output=/dev/null my-app/src/Main.elm
just to check that you’re doing it right − you might have conflicts if several modules share the same name across different apps, in this case you will have to disambiguate them before doing this (so don’t forget to commit often!) - if using elm-watch, add a new target to your
elm-watch.json
for this app. If you’re runningelm-watch hot
, you should see instantly if you’re doing it right - If you have tests, move your Elm test files (or folders, if any) to a new
tests/
folder at the top level. You might have to fix conflicts by renaming or moving stuff. (I had very few, so I just had to move one folder up:elm/my-app/tests/Integration.elm -> elm/tests/Integration.elm
) - eventually the
src/
subfolder is probably useless, and it should be as simple as moving everything inside it up one folder (intomy-app
) and adapting thesource-directories
entry inelm.json
(my-app/src
→my-app
) - remove nested
elm-stuff
folders (likemy-app/elm-stuff
), now useless - elm-review:
- I didn’t have worked so much on the configuration, so I started with a brand new starter configuration template:
elm-review init --template jfmengels/elm-review-config/application
- In order to work progressively on bringing all the apps into a clean state (no errors), I pass the list of rules to
List.map (Rule.ignoreErrorsForDirectories ["my-app", "my-other-app", "etc"])
, allowing me to fix errors on one app at a time by removing it from the list.
- I didn’t have worked so much on the configuration, so I started with a brand new starter configuration template:
- take the list of direct dependencies, install them all in your new
This keeps the Elm files separated by folder, but does not namespace them. So what was previously a top-level PersonId
module in one of the apps stays a top-level module in your new "meta" Elm project. You still use import PersonId
to use it, not import MyApp.PersonId
. That’s why you might have conflicts when trying to do this. You might also unknowingly use in app A a type that initially comes from app B, whether that is a problem or not. It’s probably a good idea to take advantage of this new unified Elm app to move all "global" modules in a folder such as common
.