elm-make
elm-make is a build tool for Elm.
-
Compile down to JS or HTML — turn Elm files into artifacts that
can be used with whatever backend you are already using.
-
Build in parallel — if you have four cores, elm-make will try to
compile four files at all times.
-
Build dependencies — elm-make is designed to work with
elm-package so if you use a bunch of 3rd party packages they will all
work just fine.
-
Build what you need — if a module is not needed for your project it
will not be built or appear in the resulting JS or HTML.
Basic Usage
Your Elm projects should all have a root directory, like project/ that all
of your Elm related stuff is going to live in. Lets imagine having the
following directory structure.
project/
Main.elm
SearchBox.elm
SearchResults.elm
Theme.elm
We have a couple Elm modules, maybe they depend on each other in some way. To
turn this into JavaScript, you can run the following command:
elm-make Main.elm --output=main.html
Before creating an HTML file called main.html, this will prompt you to
install elm-lang/core which contains all of the core modules needed to make
Elm programs work.
It will also create a file called elm-package.json which gives a structured
description of your project. elm-make uses this file to figure out what
directories it needs to look in and which packages are relevant.
More Advanced Usage
A lot of the more advanced stuff involves fiddling with elm-package.json to
make your directory structure nicer or to make sure you are working with the
right dependencies.
Directory Structure
In the Basic Usage section above, we saw a pretty boring directory structure.
As we actually used it, it would probably expand to look like this:
project/
elm-package.json
elm-stuff/...
LICENSE
Main.elm
README.md
SearchBox.elm
SearchResults.elm
Theme.elm
Pretty messy! There is a field in elm-package.json called source-directories
that allows you to list all the directories that contain Elm modules. By default
it only lists the root directory . but it is best to change that a bit. If you
are doing an Elm only project, this structure is pretty nice.
project/
src/
Main.elm
SearchBox.elm
SearchResults.elm
Theme.elm
elm-package.json
LICENSE
README.md
I would set "source-directories": [ "src" ] keeping the root of the project
as clean as possible.
If you have a project that has both frontend and backend components, I have
been experimenting with this directory structure.
project/
backend/...
frontend/
Main.elm
SearchBox.elm
SearchResults.elm
Theme.elm
elm-package.json
LICENSE
README.md
In this world you set "source-directories": [ "frontend" ]. This pattern is
used for the package.elm-lang.org project and seems to work pretty
well.
Managing Dependencies
There are two general approaches to managing dependencies depending on what you
are trying to do. These rules may not apply in every case, but they are good
guidelines.
-
If you are creating a package for others to use, you want to keep your
dependency ranges as broad as possible. You also only want to extend
ranges as far as you have tested. When you say "my library works with
4.0.0 of this package" before that version has been released or before
you have tested with it, you are likely to make life suck for your users.
Do not do that!
-
If you are creating an app or product, you want to keep your dependency
ranges very specific. When you build, a file is generated called
elm-stuff/exact-dependencies.json which lists all of the packages needed
for your project and the exact versions you happen to be using right now.
You may want to check this in to version control if you want the same
exact thing every time.
If you are in camp #1 creating a package for others, we have plans to help
automate the process of expanding version bounds. If your project compiles
with the new stuff and your tests pass, it is conceivable that everything
just works. We will be experimenting with this!
