Large products and product sytems often come with specific bundles of packages that work together. It's a great way to factor out the code that is useful across all parts of the product line. And it's only natural to factor things on many levels: along functionality concerns, and then groups of concerns. Every packaging system recognizes this with some form of "meta-packages:" packages that do nothing but include other packages with the goal of making it easy to set up consistent sets of related, but still separate chunks.

But, it kinda feels off: we expect a package to contain reusable source artifacts, not link to other packages?! And what if we need just a tiny bit different mix? Like, a set of packages for frontend products, a set for backend, a common set, and then this new variant, that is kinda-one-of-these, but not really?

A better way is to separate this concern and describe what sets go together and way. That's what kitfiles are for in elm-wrap!

Here's a real one from the elm-run project:

elm 0.19.1

kit: elm-run
    version: 0.3.0-preview.2026-05-25T083419

tool: host-run
    url: https://github.com/elm-run/releases/releases/download/0.3.0-preview.2026-05-25T083419/host-run

package: elm-run/basis/1.0.0

local-dev: elm-run/cli/1.0.0

What have we here?

We name this "kit" and give it a version to make updates easy: combinations of packages might evolve differently from packages themselves, so we want to track this separately.

Then we list what the kit includes: tools (executables) that go with certain packages and understand their versions. This is just a usual binary download, but it lets us keep compatibility wth packages or other work. As in "if you're working on this problem today, these things work well together."

Then we have packages in package and local-dev mode. These things mean what you expect them to mean: either install this specific package version from the package repostiory, or use the package source in this kit directory structure and register it in local-dev mode.

And that's it!

Now simply wrap kit install PATH/TO/KITFILE.kit and wrap will take care of setting things up.

Obviously, for local-dev packages we need the source. wrap kit expects a directory packages/ELM_VERSION/ relative to the kitfile, and then within it the usual author/name/version directory layout.

Typical workflow

Typically we'll keep this in a git repo: it doesn't have to be a seaparate one, a monorepo is just fine. The only important constraint is that packages/ directory is relative to the kitfile itself.

Then we simply ask our colleagues to pull the monorepo and wrap kit install PATH and they should be in business.

It's a great way to have a private package repository without the overload of setting up a private package repo. Works well in CI as well, with local-dev packages like this.

Updating

Updating is as simple as installing: wrap kit update PATH will look up the kitfile, compare the name with its local registry in WRAP_HOME and then first uninstall the local-dev packages and tools, and then register the packages from the kitfile and pull the new tools.

Use it now

The wrap kit command group is available starting with version 0.7.0.