Wondering what’s next for npm?Check out our public roadmap! »


    2.5.1 • Public • Published

    elm-review CLI

    Run elm-review from Node.js.

    elm-review reporter output


    # Save it to your package.json, if you use npm in your project.
    # This is the recommended way.
    npm install elm-review --save-dev
    # Install globally. This is not recommended.
    npm install -g elm-review

    See below if you want to try it out without installing it.


    # Print the help
    elm-review --help       
    # Review your project
    # Create an empty review configuration
    elm-review init         
    # Create a new project containing elm-review rules
    # aimed at being published on the Elm package registry
    elm-review new-package  
    # Create an empty new rule to get started.
    # Very helpful for projects created with new-package
    elm-review new-rule     

    Try it out

    You can try elm-review out without setting up anything!

    First of all, if you have node installed, it comes with npx, which lets you run elm-review without installing it by prepending the command by npx, like npx elm-review. It is a bit slower and requires Internet access, but it's useful to try it out.

    You can also run a configuration you found on GitHub, using the --template flag. Even if you already have a configuration, you can use this to try out the rules from a new package before adding them to your configuration. For instance, if you want to find and remove the dead code in your project, you can use the example configuration from the jfmengels/elm-review-unused package.

    npx elm-review --template jfmengels/elm-review-unused/example
    # You can even use the configuration to fix all the errors that can be auto-fixed.
    npx elm-review --template jfmengels/elm-review-unused/example --fix-all

    If you are happy with the configuration, you can base your own configuration off of it, and then edit it:

    npx elm-review init --template jfmengels/elm-review-unused/example

    I highly recommend reading this section on when to enable rules in your configuration though.

    You can use the same mechanic to try out a single rule before adding the dependency to your existing configuration and adding it to your configuration.

    npx elm-review --template jfmengels/elm-review-unused/example --rules NoUnused.Variables


    To run elm-review for the first time, you need to run

    elm-review init
    elm-review init --help # for more information and the available flags

    This will create a review/ directory containing an elm.json and a ReviewConfig.elm file, which you should commit into your project. Here is what it may look like:

    module ReviewConfig exposing (config)
    import Review.Rule exposing Rule
    import NoDebug
    import NoUnused.Variables
    config : List Rule
    config =
        [ NoDebug.rule
        , NoUnused.Variables.rule

    elm-review does not come with any built-in rules. You can read why here. You can find rules in the Elm package registry by using elm-search and searching for Review.Rule.Rule, and use them by going to your review/ directory and running elm install in your terminal.

    cd review/ # Go inside your review configuration directory
    elm install authorName/packageName

    Run a review

    Once you're done configuring, run elm-review to analyze your project.

    You can also run elm-review --fix. The CLI will present you fixes for the errors that offer an automatic fix, which you can then accept or not. When there are no more fixable errors left, elm-review will report the remaining errors as if it was called without --fix. Fixed errors will be reformatted using elm-format.

    Run elm-review --help for more information on the available flags.

    elm-review # Analyze your project
    elm-review --fix # Analyze your project and potentially proposes automatic fixes
    elm-review --help # for more information and the available flags

    Which parts of the project will be analyzed?

    elm-review targets a project, and therefore requires an elm.json. By default, it will review all the Elm files of the project and of the tests.

    • For packages: all the Elm files in src/ and tests/
    • For applications: all the Elm files in tests/ and in the project's elm.json's source-directories

    If you wish to, you can list the directories you wish to have reviewed, so as to review additional directories or to remove ignore some of directories, by adding them as arguments to the command line.

    # Review `src/` if project is a package, or the "source-directories" otherwise, along with `tests/`
    # Review only the Elm files in the `src/Dashboard/`
    elm-review src/Dashboard/
    # Review all the Elm files in the src/, tests/ and review/ directories
    elm-review src/ tests/ review/
    # Review a specific file
    elm-review src/Dashboard.elm

    The recommended way to use elm-review is without arguments. It is best not to "remove" directories from the project, because some rules expect to have access to all the files in order to make the best analysis. If some data is missing, they may make incorrect reports. If you wish to ignore some files, it is best to handle that in the implementation and/or configuration of your rules.

    If you add files that are not part of the project, you may run into different problems, such as conflicting module names (two Main.elm files), relying on different dependencies, etc. It is best to run elm-review once for each project, and depending on your needs, with different configurations (using the --config flag).

    Exit status

    If any rule from your configuration reports an error in one of the analyzed files, the process will exit with status 1. Otherwise, it will exit with status 0.

    If the process fails for any other reason (crash, misconfiguration, ...), it will exit with status 1.

    Why is there a need for a review/ directory?

    When the CLI looks at your configuration, it is in practice compiling an application using the configuration in your project, then running that application to analyze your project.

    The CLI need at least two pieces of information from your configuration:

    • An elm.json file to know the external packages your configuration depends upon (like the ones that contain the rules you enabled), and the Elm version of your project
    • A ReviewConfig.elm file that sets the rules to enforce for your project

    Your custom rules, unless you want to share them in the Elm package registry, should be in the review/ directory too, so as not to pollute your project's dependencies. If they are in here, we need to include these custom rules and their dependencies in the application files.

    Tooling integration

    If you are interested in using elm-review inside a different environment than a terminal (like editors, CI, other Elm tools, ...), check out the documentation for tooling integration.


    Thanks to @MartinSStewart for working on reducing the file cache size (and therefore speeding up the whole execution).


    npm i elm-review

    DownloadsWeekly Downloads






    Unpacked Size

    341 kB

    Total Files


    Last publish


    • avatar