package install

Install packages in an application or a package.

wrap package install elm/html
wrap package install elm/html@1.0.0
wrap package install elm/html elm/json elm/url
wrap package install elm/html@1.0.0 elm/json
wrap package install --test elm/json
wrap package install --from-file ./pkg.zip elm/html
wrap package install --from-url URL elm/html

package install behaves just like elm install when in a folder with an elm.json. If it's an application, it will just add the selected packages with latest version, just like you're used to.

If elm.json is of type package, it will add the selected package dependency with the proper version range.

Instead of installing the latest version, you may specify a specific version with @x.y.z syntax. The version must exist, of course.

options

--test

The flag --test installs the package into test section of elm.json and if the package has any dependencies, they'll go into test dependencies.

direct installs

--from-file PATH PACKAGE

--from-url URL PACKAGE

Sometimes it is convenient to install a package from a local archive or straight from GitHub. For example, when a package author changes the username on GitHub, packages published under the previous username are no longer accessible through the standard elm install command. With --from-url you can specify the URL of a Git tag on GitHub (or any other git host that publishes source zipballs) and install the package into the cache. The --from-file flag lets you install from a manually downloaded or created .zip file.

The --from-file / --from-url flags are also convenient for CI: you can ship a folder of dependencies or point to an S3 bucket or a URL, and have the packages pulled from there without hitting the public package registry.

--local-dev [--from-path PATH] [PACKAGE]

Local dev mode is wrap's star feature: it lets you install a package from its source directory during development, as if it were already published. It obviates the need for modifying source-directories in elm.json to include the package's source in the build.

There are two modes of operation. The usual one is to install the package under development from the application you are importing the package to, most likely the example app you are using to exercise the package's API:

wrap package install --local-dev --from-path path/to/package/directory/with/its/elm.json author/package

The author/package part must correspond to what's written in the package's elm.json. Once you do this, the package will be visible to the Elm compiler as if installed as usual, and wrap make (even elm make) will work as expected.

Adding the same package to another application is now a matter of wrap package install author/package---there's no need for --local-dev again, once it was done.

The other way to register a package for local development is to run wrap package install --local-dev author/package from the package's source folder. This registers the package in the local-dev registry, so wrap package install author/package in any app works as expected.

Note: during local development, use wrap make to build the package instead of elm make. The Elm compiler assumes that dependencies listed in elm.json are immutable and doesn't check if a package's source changed. It only builds the package if its metadata doesn't exist (on first install to the ELM_HOME) and after that never again. wrap make detects all local-dev packages and removes their metadata on build so that the compiler properly rebuilds them.

To review locally registered packages, use wrap repository local-dev.

Helper options

-y, --yes executes commands without asking for confirmation.

-v, --verbose shows a bunch of debug logs.

-q, --quiet is useful for batch operation, doesn't show the "Here's my plan" friendly banners.

see also

wrap package install is synonymous with wrap install