Credo: Looking at 1.0 and beyond

As José Valim eloquently put it:

Credo is not going to be able to run away from 1.0 for much longer :)

And he’s probably right 😅

Credo is nearly 2.5 years old and is probably the piece of work I am most proud of as an open source developer. Seeing it being adopted by so many people and eventually getting to the magical v1.0 in the coming months is pretty amazing.

So, without further ado …

What’s missing for 1.0?

The short answer is: nothing much.

v0.9 was released a week ago and contains all the features v1.0 should have. I am anxious to see what things will be built on top of the new JSON output.

Please report anything you find missing from the JSON output, so we can provide more value to editor integrations and other Credo-dependent pieces of software.

Development on v1.0 is steady, and with nearly a hundred contributors and just some known bugs left, you can expect a release candidate in the coming months 😎

What’s coming after 1.0?

That said, this also seems like a good time to look ahead and present a kind of “Credo Roadmap” for 2018.

After shipping v1.0, we should focus on improving Credo’s user experience.

The following aspects seem particularly relevant:

• Coding in the editor: Editor integration was not something I thought much about when creating Credo. I did not foresee so many people using Credo in so many different contexts. Therefore, editor integration did not take a front row seat in the early stages of this project. I want to change that and as a first step, v0.9.0 includes JSON support 🎉

• Speed: Credo can always be faster :) There are several ideas from the community, ranging from creating a caching mechanism to providing a Credo server running in the background, which plugins can use to avoid the penalty of starting Credo for each lint.

• Plugin architecture: Next to integrating with the technical ecosystem, I would like to enable people to build upon Credo in order to provide all the functionality the community can dream up. There should be an easy way to hook into Credo’s main process and leverage Credo’s analysis capabilities for your own purposes.

• Ecto, Phoenix, and Nerves: On top of the basic Credo package, we should make it possible to provide packages for the different emerging ecosystems inside Elixir.

• Legacy checks: There is the idea to put all the Credo checks into a “plugin” package, which are made obsolete by newer Elixir compiler checks and the Code Formatter. This way, people could still require them, but would have to do so explicitly.

• Configuration: With all the above in mind, I think configuration will play a bigger role down the road. For example, we should detect obsolete or mispelled checks and if you give parameters to a check, those should be linted (and incorrect parameters should cause an error alongside a description on how to fix the misconfiguration).

Hopefully, this list provides some context on where Credo is going. As always: None of this is set in stone. People have always given input to Credo’s direction and the roadmap has changed more than once in the past.

So don’t be shy: You can propose features and report bugs on GitHub!