Ebert for Elixir/Phoenix

First steps

Photo by Rucksack Magazine on Unsplash

Until recently, I had somehow managed to overlook Ebert, a code review service that supports a bunch of languages including Elixir. As I’ve since made Ebert part of my workflow, I thought I’d share some initial impressions and show how to run the same linters locally.

After you’ve set up Ebert for your repo, there’s a button on the review page that says ”Download the configuration file”. This default config might be all you need but just for reference, here’s the .ebert.yml that I’m currently using for new Phoenix projects:

engines:
  credo:
    enabled: true
  fixme:
    enabled: true
  eslint:
    enabled: true
    exclude_paths:
      - assets/*config.js
  scss-lint:
    enabled: true
  remark-lint:
    enabled: true
exclude_paths:
- config
- priv
- assets/vendor
- test
- spec

Here I’m telling Ebert to ignore files such as brunch-config.js and webpack.config.js as well as vendored front-end libraries. Do note that all asset paths in this article are specific to the new Phoenix 1.3 directory structure.

Elixir

Ebert analyzes Elixir code with Credo and is apparently using strict mode. To ensure you’re using the same setup both locally and remotely, simply place a .credo.exs config in project root.

To save yourself from typing mix credo --strict repeatedly, you may also want to edit the config to force strict mode.

Ebert’s default Credo config | My edits

If you write Elixir apps without front-end assets, this is pretty much all there is to it. The rest of this article deals with the additional steps you need to take with Phoenix.

Phoenix

When I first ran Ebert using my GitHub repo as a testing ground, the result was 1090 issues found — not exactly the quality nirvana I had hoped for. Turns out that most of these issues were caused by the one line where Phoenix imports Bootstrap. You wouldn’t usually lint 3rd-party libraries, so that’s clearly a good candidate for disabling linting.

Stylesheets

Ebert’s default config includes CSSLint but as I rarely write pure CSS anymore, I switched over to SCSS Lint (your mileage may vary):

engines:
  csslint:
    enabled: false
  scss-lint:
    enabled: true

If you have Ruby installed, simply type

$ gem install scss-lint

Place .scss-lint.yml config in project root and run the linter with

$ scss-lint assets/css/

Now it’s just up to fixing any stylesheet issues and verifying that Ebert reports 0 issues found.

Ebert’s default SCSS Lint config | My edits

JavaScript

While you can install ESLint globally, a per-project setup seems to be the recommended way:

$ cd assets && yarn add --dev eslint eslint-plugin-react

Feel free to omit the plugin if React is not part of your setup. Next up, let’s add one line to package.json:

"scripts": {
  // etc...
  "eslint": "node_modules/.bin/eslint -c ../.eslintrc.js js/"
},

Once you have .eslintrc.js config in project root, you can now run

$ cd assets && yarn eslint

(npm run eslint would work too.)

See my edits to ESLint config below if you too write ES6 or use a code formatter like Prettier and want ESLint to follow similar rules.

Now we’re ready to fix any JavaScript issues and to verify that Ebert reports 0 issues found. Note that you probably shouldn’t spend time fixing issues manually but use the ESLint --fix command line option or have your text editor auto-format JavaScript on each save.

Ebert’s default ESLint config | My edits

Wrapping Up

If you followed the steps above, running code analysis on your local Phoenix project now looks something like this:

$ mix credo
$ scss-lint assets/css/
$ cd assets && yarn eslint

Happy linting!