• Run elm init at the top-level (in the directory containing your separate Elm apps), creating a new elm.json
• If using elm-watch, run elm-watch init, creating a new elm-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 regular elm 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.
  • do the same for test dependencies
  • take the list of source-directories, add them to your new elm.json (usually something like my-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 running elm-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 (into my-app) and adapting the source-directories entry in elm.json (my-app/src → my-app)
  • remove nested elm-stuff folders (like my-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.

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.