# What would you think about an $ELM\_HOME for local packages?

**URL:** <https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530>\
**Category:** Request Feedback\
**Created:** [January 21, 2026, 10:43am UTC](https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530 "2026-01-21T10:43:10Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![adamyakes](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/adamyakes/32/4385_2.png) [@adamyakes](https://discourse.elm-lang.org/u/adamyakes)\
**Post date:** [January 21, 2026, 10:43am UTC](https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530/1 "2026-01-21T10:43:10Z")

</div>

I write Elm for work in an enterprisey environment. We primarily write in-house tooling for other employees. Our repositories typically have `frontend` and `backend` folders at the root of the project, with all the Elm code living in `frontend/src`. We’ve found ourselves writing similar modules for common needs, but unfortunately cannot publish those modules to [package.elm-lang.org](http://package.elm-lang.org) since we would not be able to publish work done for the company as open-source projects (at least not without going through a lot of trouble).

The `source-directories` array in `elm.json` allows you to add additional source directories “outside” your project in order to have local copies of, say a package, but it has a few shortcomings

1. You’re limited to absolute or relative paths. `elm.json` gets checked in, so an absolute path is out, and a relative path would require everyone to have the same repository structure (side-by-side) and, if the `elm.json`s are to be consistent, the same internal structure as well. This isn’t ideal. We are also “not allowed” to use submodules, so a relative path _in_ to the repository wouldn’t work.
2. I’m not sure if it does allow environment variables, but if it did, the syntax for that is different between `%WINDOWS%` and `$LinuxOrMac`.

Would some sort of canonical environment variable the compiler used to look for source directories fix this? I am aware the compiler caches files in `~/.elm/0.19.1/packages`, but I don’t think it’s a good idea to edit that manually.

I would love to know if there’s a standard way to do this and am open to ideas!

---

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [January 21, 2026, 11:42am UTC](https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530/2 "2026-01-21T11:42:38Z")

</div>

> **[elm-wrap — dependable Elm dependencies](https://elm-wrap.dev/)**

Did you see this in the recent Elm newsletter? I think it covers your use case.

===

Actually that looks like its coming in the 0.7 version which is next on the roadmap:

> **[Roadmap — elm-wrap](https://elm-wrap.dev/roadmap.html)**

---

<div class="post-metadata">

**Author:** ![adamyakes](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/adamyakes/32/4385_2.png) [@adamyakes](https://discourse.elm-lang.org/u/adamyakes)\
**Post date:** [January 21, 2026, 1:24pm UTC](https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530/3 "2026-01-21T13:24:01Z")

</div>

I will certainly have to take a look. Thanks!

---

<div class="post-metadata">

**Author:** ![dwayne](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/dwayne/32/5478_2.png) [@dwayne](https://discourse.elm-lang.org/u/dwayne)\
**Post date:** [January 21, 2026, 3:28pm UTC](https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530/4 "2026-01-21T15:28:11Z")

</div>

@adamyakes Are you able to use Nix at the company?

---

<div class="post-metadata">

**Author:** ![damir](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/damir/32/5549_2.png) [@damir](https://discourse.elm-lang.org/u/damir)\
**Post date:** [January 22, 2026, 3:19pm UTC](https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530/5 "2026-01-22T15:19:39Z")

</div>

Packages are really the right means of sharing reusable code, as you point out yourself. `source-directories` is not.

As @Rupert said, `elm-wrap` is made to unlock your exact scenario: extracting code from the source tree into packages, publishing to local, team, org, private repositories; install from Git.

As of version 0.6, you can use `wrap package extract` to turn chunks of code into packages and use them locally for your own development and to git-version them separately. `extract` sets up [`local-dev`](https://elm-wrap.dev/manual/local-dev.html) mode that lets you work on the package in its source folder as if connected via `source-directories` but behaving like a normal dependency in your `elm.json`.

The 0.6-way of sharing for your scenario would be to keep your private packages in a parallel `packages` folder and then let each developer install them once into cache using [`wrap package cache --from-file PATH PACKAGE`](https://elm-wrap.dev/manual/package-cache.html) looping with a single script you keep in the same repo. (You’d set up a structure corresponding to `ELM_HOME` layout: `packages/author/name/version`, that way you can also version your packages nicely).

From there, the usual `elm install my/private-package` just works: if the package is in the cache, `elm install` is happy. `wrap` takes care not to confuse `elm` about which packages came from where, so your normal `elm install` will continue functioning as usual, picking up new public packages. And that also works in CI as long as you do the `cache --from-file` step before calling `elm make`.

The other way is to commit to git-repo-per-package and then every developer installs with [`wrap package install --from-url URL PACKAGE`](https://elm-wrap.dev/manual/package-install.html): this has the same effect as installing from the public repository. (The public repository just redirects `elm install` to Git to download the zipball from url and unpacks it in `ELM_HOME`. `wrap install –-from-url` does the same with explicit url of the zipball, without needing the initial metadata).

* * *

Upcoming version 0.7 brings local repository: you extract a package and then push it to local repository, similar to how you would publish to the public registry now, but without the tag-then-push-to-Github dance. (Behind the scenes it is really the `ELM_HOME` layout with more metadata and clean CLI UX to manage; no web servers/databases involved).

After that, my plan is to spend some time on policies: things that let you decide what you want in your repos and what you don’t want; (think of it like git pre-commit hooks). Then 0.9 brings us team/org package repositories.

Local private repository is easier and more robust to deliver than team/org as the latter require more setup (web servers, network rules, authentication, etc). But that doesn’t mean we can’t test things in advance if you are interested in solving the problem.

* * *

If you are interested, I’m curious about your environment. For example, when you say _enterprisey_, that usually rhymes with Windows. Are your servers also Windows? And would you/your org be open to beta test via a hosted private team repo? (That is, hosted on elm-wrap.cloud, with right authentication and security). Much easier during testing than also having to provide installation support.

* * *

One more thing: `0.6.1` doesn’t mean “not tested” or “in beta.” It just signals “not all features are in there yet,” like Elm versioning. All releases are production grade. (Betas are marked `~preview.{1,..,n}`).

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [February 1, 2026, 3:19pm UTC](https://discourse.elm-lang.org/t/what-would-you-think-about-an-elm-home-for-local-packages/10530/6 "2026-02-01T15:19:51Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.