The elm-package.json file contains metadata about your application or package. The Elm platform uses it to compile your code and distribute it as a package.

To create a basic elm-package.json file, you can execute elm-package install or elm-make. This will set up a simple project and download the default dependencies.

{
    "version": "1.0.0",
    "summary": "helpful summary of your project, less than 80 characters",
    "repository": "https://github.com/user/project.git",
    "license": "BSD3",
    "source-directories": [
        "."
    ],
    "exposed-modules": [],
    "dependencies": {
        "elm-lang/core": "5.1.1 <= v < 6.0.0",
        "elm-lang/html": "2.0.0 <= v < 3.0.0"
    },
    "elm-version": "0.18.0 <= v < 0.19.0"
}

Overview

Note: All properties are required, even if not marked above as relevant. Properties not relevant to your project are best left with their default values intact.

version

There is no need to ever touch this for applications.

The version property defines the semantic version of the public API of your package.

Only stable packages can be published to http://package.elm-lang.org/. As such, version numbers start at 1.0.0.

There is generally no need to manually modify this value. Instead, when you are ready to publish a new version, use elm-package bump which will compare your API to the previously uploaded version and decide on the correct new version number to apply.

Before a version can be published with elm-package publish, it need to be tagged and the tag must be published. Using elm-package publish before doing so will give you specific instructions on how to tag and push that tag.

summary

There is no need to ever touch this for applications.

80 character (max) description of your package.

This is the description that shows up on the package listing at http://package.elm-lang.org. In order for people to be able to find your package, it's a good idea to use relevant keywords in here.

repository

There is no need to ever touch this for applications.

For packages, this should be the git repository, accessible over https, as hosted on GitHub. You will only want to change the user/project part of the URL, and leave the https://github.com/ prefix and .git suffix intact.

Note that this entry is case sensitive. If you do not use the exact same casing here as your actual GitHub username or GitHub repository, installation will not function correctly.

You'll generally want to refrain from using any "special" characters here. Using dots in the username or project, for example, will break the compiled code.

Unless your GitHub username is Elm-specific (for example elm-lang), it's generally a good idea to prefix the package name with elm-. This makes it easier for people to discover your package on GitHub.

license

There is no need to ever touch this for applications.

License under which you release this code. Note that most licenses also require a LICENSE file to be included in your repository as well as a copyright notice in your README in order to actually be valid.

Using the license generator on GitHub makes this a fairly painless process.

At the moment, this field is not restricted. However, it is recommended to use a proper SPDX license identifier.

source-directories

The source-directories property gives a list of (relative) paths where the Elm compiler will look for modules referenced in your code.

Typically, this will look like ["src"] if your sources live in the src directory, relative to the location of elm-package.json. In the case of the elm-package.json for elm-test, there would typically be a corresponding [".", "../src"] entry (the first is where you tests are, the second is where the code under test is).

Note that there is a direct mapping of filepaths to module names in Elm. For example, given a "source-directories": ["src"], the module Foo.Bar.Baz should live at src/Foo/Bar/Baz.elm.

On Mac OS X, the filesystem is case aware, but not case sensitive. What this means is that during development, you can probably get away with naming the above file src/fOO/bAR/bAZ.elm. However, people using your packages may be using case sensitive filesystems, so your package will not work for them.

As such, please use the exact same case for the path as for the module names.

exposed-modules

There is no need to ever touch this for applications.

The exposed-modules property indicates which modules from your package are exposed. Modules added to this list will be shown on http://package.elm-lang.org and, when a user installs your package as a dependency, the exposed modules will be available to import.

When a module is added to the exposed-modules property, elm-make will enable an extra set of checks for those modules to ensure that all exposed variables are properly documented. You can read a bit more on the exact format for documentation on package.elm-lang.org/help/documentation-format.

dependencies

This is probably the most important property for applications. It consists of a map of each dependency's name (identified by its author's name combined with a package name) to a range of semantic versions. The general syntax is <minimal> <= v < <maximal>.

For applications, it's generally a good idea to limit ranges or even pin them to specific versions (1.2.3 <= v < 1.2.4 would only allow version 1.2.3, for example). This prevents you from accidentally relying on behaviour that may change. To be extra-safe, one can also add transient dependencies here and pin those, too. That way, elm-package.json can double as a lock-file.

For libraries, it's recommended to use broad ranges (to minimize the risk of running into dependency conflicts) while also limiting the number of dependencies. For example, if you only need a single function from some package, it may be better to replicate that function rather than pull that package in as a dependency, and making consumers of your package depend upon it as well.

elm-version

This is a semantic version range specifying the version(s) of Elm your package is compatible with. You'll probably want to leave it set to its default value, unless upgrading a package from an older version of Elm to 0.18.