Lint-Condo - A Lint Container for Docker
lint-condo is a linting container for Docker, built especially for continuous integration.
More specifically: Why make linting an automated part of your project?
Adding linting to your project pretty much anytime after your initial commit can be daunting, which is ever the more reason to start linting as early as possible. If after 10 weeks you add linting and find 1000 linting problems, you might think of that as like 100 per week. However, if you were to start linting in week 1, I guarantee you won’t have seen nearly as many as 1000 problems by week 10.
What happens is that after a few CI failures for the same linting reasons, you quickly learn not to do that again and tend to write according to best practices / style guide from the start.
For this reason, it feels like delaying linting is not a zero sum game (i.e. fix them now or fix them later) but instead can result in improved code quality “for free” once you start absorbing the best practices.
We try to use Docker for every piece of our projects - both in production as well as development - so it was an easy decision to create a Docker-based linting solution too. However, you could get a real benefit from running linting this way even if the rest of your project isn’t itself Docker-based.
Everything you need for linting is contained within the built image. i.e. no more worrying about installing dependencies.
npm, don’t forget about ones like
scss_lint in Ruby and
yamllint in Python.
Installing linters from three different dependency tools (
pip) can be a bit of a pain.
And if you run a Go-based backend you might even make that four dependency managers.
Once you add a config file, you can lint with a command as simple as:
docker run -v `pwd`:/src/ singapore/lint-condo
We’re also considering if anyone would like auto-detection of linters to avoid a configuration file, but the file itself is simple.
This is particularly handy when it comes to Continuous Integration.
Quick to run on Continuous Integration
In the past, around half our build failures come from linting errors in new commits.
Previously, lint tests were just one component of our test suite, and would run after install and build.
As a result, it would take us around ~5 minutes to detect a lint failure, with a lot of unnecessary libraries installed and built beforehand.
We desired to push linting as early and quickly as possible (e.g. before any
npm install) that lead us to this Docker-based solution.
By running this image before install and build commands, you can find linting errors first and give earlier feedback.
Run in parallel to other tests
Because lint testing is now quite removed from the rest of your project (doesn’t require install, build, or any test dependencies), it’s easy for you to configure it onto a second/different CI service to run in parallel to your other tests. e.g. if you already use CircleCI for tests, you could run linting using Shippable or SemphoreCI in parallel.
For this initial release, you need to create a simple
.lint-condo.yml file in the root of your repo to tell us which linters to run. However, we’re also considering which linters can be detected and run simply by looking for the presence of a config file (e.g.
Docker run capabilities
Refactor the project Dockerfile so that the image can be used for one-off
docker run commands, e.g. like
docker run singapore/lint-condo eslint ....
Parsing/normalisation of output
It would be a nice feature to capture the warning/error count from linters and display them consistently in the summary.
Non-root configuration file
Mandatory files in project roots are annoying, so soon you can locate it where you want and lint-condo will find it.