Custom ESLint rules #1/5: introduction

You have your amazing project and you are working with an awesome team of people from all over the world. Everything's going great! Until one day you get an MR/PR from a colleague, you open it and...

const yummyPizza = eatPizzaWithPineapple()

"Oh no! Someone wants to eat pizza with pineapple!". I can hear you shout. No worries, I am Italian and I can feel your pain. No, no, no, don't resign from your job because of this, I am here to help. No one in the world should be allowed to put pineapple on pizza. Ever. It's illegal. There should be a dedicated Circle in Dante's Inferno, I am pretty sure.

How could we prevent our amazing team from eating that illegal pizza? Fortunately, ESLint allows developers to define their own ruleset to enforce consistency across the codebase. A lot of basic rules are already defined by ESLint itself and a lot of extended rules are out there in the npm universe, but still, no one knows your codebase and your teammates better than you.

We need a custom ESLint rule that will prevent pineapple pizza! It should work like this:

• highlight the error. We choose error severity as fatal or apocalypse are not available yet.

• provide a way to automatically fix it. It should be eatPizzaMargherita instead. Period. No room for discussion.

• provide a meaningful error message. Something along the lines of A notification was sent to the Italian police. They're coming. Pineapple pizza is illegal, please eat pizza Margherita instead.

Now that we know what to do to save our teammates from eating that pretent-to-be-a-pizza, we need to figure out how to do it.

In the next bite, we will start creating a sample project to show how to achieve this goal.