elm-app install

elm-app test

elm-app eject

Note: this is a one-way operation. Once you eject, you can’t go back!

If you aren’t satisfied with the build tool and configuration choices, you can eject at any time.

Instead, it will copy all the configuration files and the transitive dependencies (Webpack, Elm Platform, etc.) right into your project, so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point, you’re on your own.

You don’t have to use 'eject' The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However, we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.

elm-app <elm-platform-command>

Create Elm App does not rely on the global installation of Elm Platform, but you still can use its local Elm Platform to access default command line tools:

Dead code elimination

Create Elm App comes with an opinionated setup for dead code elimination which is disabled by default, because it may break your code.

You can enable it by setting DEAD_CODE_ELIMINATION environment variable to true

Changing the base path of the assets in the HTML

By default, assets will be linked from the HTML to the root url. For example /css/style.css.

If you deploy to a path that is not the root, you can change the PUBLIC_URL environment variable to properly reference your assets in the compiled assets. For example: PUBLIC_URL=./ elm-app build.

Changing the Page <title>

You can find the source HTML file in the public folder of the generated project. You may edit the <title> tag in it to change the title from “Elm App” to anything else.

Note that normally you wouldn’t edit files in the public folder very often. For example, adding a stylesheet is done without touching the HTML.

If you need to dynamically update the page title based on the content, you can use the browser document.title API and JavaScript interoperation. The next section of this tutorial will explain it in more detail.

JavaScript Interop

In the following example we will use JavaScript to write a log in the console, every time the state changes in outrElm app. To make it work with files created by create-elm-app you need to modify
src/index.js file to look like this:

Please note that for Inc and Dec operations Cmd.none was replaced with logger port call which sends a message string to the JavaScript side.

Adding a Stylesheet

This project setup uses Webpack for handling all assets. Webpack offers a custom way of “extending” the concept of import beyond JavaScript. To express that a JavaScript file depends on a CSS file, you need to import the CSS from the JavaScript file:

main.css

body {
padding: 20px;
}

index.js

import'./main.css'; // Tell Webpack to pick-up the styles from main.css

Post-Processing CSS

This project setup minifies your CSS and adds vendor prefixes to it automatically through Autoprefixer so you don’t need to worry about it.

In development, expressing dependencies this way allows your styles to be reloaded on the fly as you edit them. In production, all CSS files will be concatenated into a single minified .css file in the build output.

You can put all your CSS right into src/main.css. It would still be imported from src/index.js, but you could always remove that import if you later migrate to a different build tool.

Note: To use a different preprocessor, replace build-css and watch-css commands according to your preprocessor’s documentation.

Now you can rename src/main.css to src/main.scss and run npm run watch-css. The watcher will find every Sass file in src subdirectories, and create a corresponding CSS file next to it, in our case overwriting src/main.css. Since src/index.js still imports src/main.css, the styles become a part of your application. You can now edit src/main.scss, and src/main.css will be regenerated.

To share variables between Sass files, you can use Sass imports. For example, src/main.scss and other component style files could include @import "./shared.scss"; with variable definitions.

To enable importing files without using relative paths, you can add the --include-path option to the command in package.json.

At this point you might want to remove all CSS files from the source control, and add src/**/*.css to your .gitignore file. It is generally a good practice to keep the build products outside of the source control.

Why node-sass-chokidar?

node-sass has been reported as having the following issues:

node-sass --watch has been reported to have performance issues in certain conditions when used in a virtual machine or with docker.

Result filenames include content hashes, so you don’t need to worry about browsers caching their old versions.

However, there is a escape hatch that you can use to add an asset outside of the module system.

If you put a file into the public folder, it will not be processed by Webpack. Instead, it will be copied into the build folder untouched. To reference assets in the public folder, you need to use a special variable called PUBLIC_URL.

Inside index.html, you can use it like this:

<linkrel="shortcut icon"href="%PUBLIC_URL%/favicon.ico">

Only files inside the public folder will be accessible by %PUBLIC_URL% prefix. If you need to use a file from src or node_modules, you’ll have to copy it there to explicitly specify your intention to make this file a part of the build.

When you run elm-app build, Create Elm App will substitute %PUBLIC_URL% with a correct absolute path, so your project works even if you use client-side routing or host it at a non-root URL.

In Elm code, you can use %PUBLIC_URL% for similar purposes:

{- Note: this is an escape hatch and should be used sparingly! Normally we recommend using `import` and `Html.programWithFlags` for getting asset URLs as described in “Adding Images and Fonts” above this section.-}img [ src "%PUBLIC_URL%/logo.svg"][]

In JavaScript code, you can use process.env.PUBLIC_URL for similar purposes:

constlogo=`<img src=${process.env.PUBLIC_URL+'/img/logo.svg'} />`;

Keep in mind the downsides of this approach:

None of the files in public folder get post-processed or minified.

Missing files will not be called at compilation time, and will cause 404 errors for your users.

Result filenames won’t include content hashes so you’ll need to add query arguments or rename them every time they change.

When to Use the public Folder

Normally we recommend importing stylesheets, images, and fonts from JavaScript.
The public folder is used as a workaround for some less common cases:

You have thousands of images and need to dynamically reference their paths.

You want to include a small script like pace.js outside of the bundled code.

Some library may be incompatible with Webpack and you have no other option but to include it as a <script> tag.

Note that if you add a <script> that declares global variables, you also need to read the next section on using them.

Using custom environment variables

In your JavaScript code you have access to variables declared in your
environment, like an API key set in an .env-file or via your shell. They are
available on the process.env-object and will be injected during build time.

Besides the NODE_ENV variable you can access all variables prefixed with
ELM_APP_:

# .env
ELM_APP_API_KEY="secret-key"

Alternatively, you can set them on your shell before calling the start- or
build-script, e.g.:

ELM_APP_API_KEY="secret-key" elm-app start

Both ways can be mixed, but variables set on your shell prior to calling one of
the scripts will take precedence over those declared in an .env-file.

Setting up API Proxy

To forward the API ( REST ) calls to backend server, add a proxy to the elmapp.config.js in the top level json object.

module.exports= {
...
proxy:"http://localhost:1313",
...
}

Make sure the XHR requests set the Content-type: application/json and Accept: application/json.
The development server has heuristics, to handle its own flow, which may interfere with proxying of
other html and javascript content types.

Making a Progressive Web App

Progressive Web Apps are faster and more reliable than traditional web pages, and provide an engaging mobile experience:

All static site assets are cached so that your page loads fast on subsequent visits, regardless of network connectivity (such as 2G or 3G). Updates are downloaded in the background.

Your app will work regardless of network state, even if offline. This means your users will be able to use your app at 10,000 feet and on the Subway.

On mobile devices, your app can be added directly to the user's home screen, app icon and all. You can also re-engage users using web push notifications. This eliminates the need for the app store.

The sw-precache-webpack-plugin
is integrated into production configuration,
and it will take care of generating a service worker file that will automatically
precache all of your local assets and keep them up to date as you deploy updates.
The service worker will use a cache-first strategy
for handling all requests for local assets, including the initial HTML, ensuring
that your web app is reliably fast, even on a slow or unreliable network.

Opting Out of Caching

If you would prefer not to enable service workers prior to your initial
production deployment, then remove the call to serviceWorkerRegistration.register()
from src/index.js.

If you had previously enabled service workers in your production deployment and
have decided that you would like to disable them for all your existing users,
you can swap out the call to serviceWorkerRegistration.register() in
src/index.js with a call to serviceWorkerRegistration.unregister().
After the user visits a page that has serviceWorkerRegistration.unregister(),
the service worker will be uninstalled. Note that depending on how /service-worker.js is served,
it may take up to 24 hours for the cache to be invalidated.

Offline-First Considerations

Service workers require HTTPS, although to facilitate local testing, that policydoes not apply to localhost. If your production web server does not support HTTPS, then the service worker registration will fail, but the rest of your web app will remain functional.

The service worker is only enabled in the production environment, e.g. the output of npm run build. It's recommended that you do not enable an offline-first service worker in a development environment, as it can lead to frustration when previously cached assets are used and do not include the latest changes you've made locally.

If you need to test your offline-first service worker locally, build the application (using npm run build) and run a simple http server from your build directory. After running the build script, create-react-app will give instructions for one way to test your production build locally and the deployment instructions have instructions for using other methods. Be sure to always use an incognito window to avoid complications with your browser cache.

If possible, configure your production environment to serve the generated service-worker.jswith HTTP caching disabled. If that's not possible—GitHub Pages, for instance, does not allow you to change the default 10 minute HTTP cache lifetime—then be aware that if you visit your production site, and then revisit again before service-worker.js has expired from your HTTP cache, you'll continue to get the previously cached assets from the service worker. If you have an immediate need to view your updated production deployment, performing a shift-refresh will temporarily disable the service worker and retrieve all assets from the network.

Users aren't always familiar with offline-first web apps. It can be useful to let the user know when the service worker has finished populating your caches (showing a "This web app works offline!" message) and also let them know when the service worker has fetched the latest updates that will be available the next time they load the page (showing a "New content is available; please refresh." message). Showing this messages is currently left as an exercise to the developer, but as a starting point, you can make use of the logic included in src/registerServiceWorker.js, which demonstrates which service worker lifecycle events to listen for to detect each scenario, and which as a default, just logs appropriate messages to the JavaScript console.

By default, the generated service worker file will not intercept or cache any cross-origin traffic, like HTTP API requests, images, or embeds loaded from a different domain. If you would like to use a runtime caching strategy for those requests, you can eject and then configure the runtimeCaching option in the SWPrecacheWebpackPlugin section of webpack.config.prod.js.

Progressive Web App Metadata

The default configuration includes a web app manifest located at
public/manifest.json, that you can customize with
details specific to your web application.

When a user adds a web app to their homescreen using Chrome or Firefox on
Android, the metadata in manifest.json determines what
icons, names, and branding colors to use when the web app is displayed.
The Web App Manifest guide
provides more context about what each field means, and how your customizations
will affect your users' experience.

Deployment

elm-app build creates a build directory with a production build of your app. Set up your favourite HTTP server so that a visitor to your site is served index.html, and requests to static paths like /static/js/main.<hash>.js are served with the contents of the /static/js/main.<hash>.js file.

Building for Relative Paths

To override this, specify the homepage in your elmapp.config.js, for example:

module.exports= {
homepage:"http://mywebsite.com/relativepath"
}

This will let Create Elm App correctly infer the root path to use in the generated HTML file.

Static Server

For environments using Node, the easiest way to handle this would be to install serve and let it handle the rest:

npm install -g serve
serve -s build

The last command shown above will serve your static site on the port 5000. Like many of serve’s internal settings, the port can be adjusted using the -p or --port flags.

Run this command to get a full list of the options available:

serve -h

Netlify

Step 1: Create a package.json file

Step 2: npm install --save-dev create-elm-app

Since netlify runs the build step on their server we need to install create-elm-app.

Step 3: Add a build script to the package.json file

"scripts": {
"build": "elm-app build",
...
}

Step 4: Go to the netlify settings and set the build step to npm run build

This step is important to make sure netlify uses the correct build command.

GitHub Pages

Step 1: Add homepage to elmapp.config.js

The step below is important!

If you skip it, your app will not deploy correctly.

Open your elmapp.config.js and add a homepage field:

module.exports= {
homepage": "https://myusername.github.io/my-app",
}

Create Elm App uses the homepage field to determine the root URL in the built HTML file.

Step 2: Build the static site

elm-app build

Step 3: Deploy the site by running gh-pages -d build

We will use gh-pages to upload the files from the build directory to GitHub. If you haven't already installed it, do so now (npm install -g gh-pages)

Now run:

gh-pages -d build

Step 4: Ensure your project’s settings use gh-pages

Finally, make sure GitHub Pages option in your GitHub project settings is set to use the gh-pages branch:

Step 5: Optionally, configure the domain

You can configure a custom domain with GitHub Pages by adding a CNAME file to the public/ folder.

Notes on client-side routing

GitHub Pages doesn’t support routers that use the HTML5 pushState history API under the hood (for example, React Router using browserHistory). This is because when there is a fresh page load for a url like http://user.github.io/todomvc/todos/42, where /todos/42 is a frontend route, the GitHub Pages server returns 404 because it knows nothing of /todos/42. If you want to add a router to a project hosted on GitHub Pages, here are a couple of solutions:

You could switch from using HTML5 history API to routing with hashes.

Alternatively, you can use a trick to teach GitHub Pages to handle 404 by redirecting to your index.html page with a special redirect parameter. You would need to add a 404.html file with the redirection code to the build folder before deploying your project, and you’ll need to add code handling the redirect parameter to index.html. You can find a detailed explanation of this technique in this guide.

IDE setup for Hot Module Replacement

Remember to disable safe write if you are using VIM or IntelliJ IDE, such as WebStorm.