DEV Community

Kaleb M
Kaleb M

Posted on

Is ESLint Worth Your time?

Hello everyone!

I'm Kaleb and this is my first Dev.to post. I'm thrilled to finally post as part of the community, and look forward to connecting with more of you all as we grow and learn throughout our careers by sharing the journey with each other!!

Today I'm in the process of updating documentation for our team standards so anyone interested in following them can. I thought it would be a great time to post on why I believe ESLint is worth the team to set up!

What is Linting?

Linting is simply the static analysis of code against a set of rules to determine whether the rules are being followed.

What is ESLint

It's a Javascript linter!! ESLint is an open source project that was founded in 2013 by C. Zakas.

The main reason behind its creation was to give developers power in developing their own rules that could be linted against, especially for rules that are considered best practices.

You can learn more about the mission and philosophy of the project on its About Page.

For the web development community this be very helpful for beginners following the standards of experts over at Google or Airbnb, or for a team of developers at a start up who want to make sure they are following the same practices as they begin to grow.

SN - Typically the reasoning and style guides accompany ESLint configs, letting those using the config to understand the why behind certain rules.

Although the set up doesn't take long, is it worth introducing to your project?

I definitely believe so!!

ESLint is Worth the Time!

Code reviews, an opportunity for teammates to collaboratively introduce, fix, or break code in a code base. Code reviews are absolutely worth doing, but can also become a huge drag on productivity when minute details such as whether or not a developer should use trailing commas in their objects or not become heavily discussed.

Reason 1 - Enforce Standards Programmatically

By programmatically enforcing standards, teams save time and prevent team head butting!

Note: I'm not suggesting that rules themselves shouldn't be discussed, but once a they are decided and agreed upon, it's no longer a battle of two developer opinions during review processes. Instead, it becomes ESLint enforcing the standards.

Let's look a quick example:

const pikachu = {
    type: 'electric',
    color: 'yellow',
}

vs.

const pikachu = {
    type: 'electric',
    color: 'yellow'
}

Opinions and discussions on these lines of code during the review process can extend the amount of time both developers should actually be writing code.

ESLint removes the dynamic by enforcing those rules without the need of discussion, ego, or potential arguments.

For the particular example above, here's the rule: Comma Dangle

Remember, code reviews and code bases are no individual's on the team. It's our code!

SN - check out this great video from React Conf on code reviews.

Reason 2 - Automate Code Quality

I mentioned previously being able to easily follow best practices for our industry from top companies or well known web developers by using their ESLint config. It's important to note that you can also add or remove rules from these config extensions as well, meaning you can truly make ESLint work the way you want to for your team.

There are three common ways to enforce linting in your development process

  1. IDE - Download ESLint for your favorite editor by following the ESLint guide

This will show you problems to fix quick and easy before trying to commit.

  1. Pre-commit

Check out the Lint-Staged module to run linting against newly staged files, disallowing commits if any linting errors are found!

  1. Pipeline

Add linting into your pipeline to prevent any deployments with errors, preventing developers from completing stories when errors are found!

The effort to set up any of the 3 options above is trivial and so worth it!

Reason 3 - Code Maintenance

Enforcing standards that to prevent long discussion and ego battles, along with preventing developers from committing to the code base unless they adhere to the agreed standards are the first two big wins for using a linter like ESLint.

The last reason goes right along with the first, by following a team standard, working on other's code becomes a bit easier (can't say easy here :D) because you can now focus on logic compared to stylistic differences that contend for cognitive energy :).

Concluding Thoughts

As developers it's our responsibility to do our best writing high quality code in a productive manner. We owe this to ourselves as its part of the art in our profession, and to our company/client who pays us to do the work.

Why not make it a bit easier for yourself and also for your team to make impact, while saving time and enforcing higher quality code bases?

Thank you for reading!!

Top comments (16)

Collapse
 
tirthaguha profile image
Tirtha Guha

For small projects you can avoid linting. But for large ecosystems, like 50+ devs working with 1.5 million lines of code, we need some consistency to ease development, debugging and review. I'm absolutely for linting.

Collapse
 
avatarkaleb profile image
Kaleb M

I'd love to hear more on your reasoning for this?

I find that smaller teams have to handle larger responsibilities, meaning more of the code base (percentage wise), even though less of them are actually writing it.

Collapse
 
s3pt1c4n profile image
Richard Pap

I don't think it would be about just the size on the team. When you lead a team of junior devs for example, it's also a really useful thing to teach them.

Collapse
 
tirthaguha profile image
Tirtha Guha

Consistency is the keyword here. Random coding styles makes difficult to support code. Every class or file would start to have different styles, and that would make debugging a nightmare. Instead, enforce a consistent coding style and make everyone's life easy.

Thread Thread
 
avatarkaleb profile image
Kaleb M

Yes I would agree - wouldn't a linter help with that consistent style for small and large teams?

I was trying to understand the difference between the two from your perspective, as I've only worked on smaller web applications compared to enterprise level imho.

Collapse
 
avatarkaleb profile image
Kaleb M

Agreed! Especially if you use a config like Airbnb's which is strict :D

Collapse
 
lampewebdev profile image
Michael "lampe" Lazarski

EVERY project I work on has eslint enabled. There is no reason not to add it!

It's also super easy to add.

Eslint has an init command!

Path_to_eslint/eslint.js --init and then you can choose! What's so hard about it? Nothing! So use it 😀✌️

Collapse
 
avatarkaleb profile image
Kaleb M

Nice! I really like the ease of it and it comes with a default config for you :)

Collapse
 
lampewebdev profile image
Michael "lampe" Lazarski

Yes and that is the beauty of it!

😀✌️

Collapse
 
ben profile image
Ben Halpern

Yes!

Collapse
 
avatarkaleb profile image
Kaleb M

Thank you for reading Nick!

I totally agree - prettier + eslint => so much more time spent on the right things!

Collapse
 
strahinjalak profile image
Strahinja Laktovic

Definitely yes. I didn't like it at first, but the consistency and cleanliness of code it enforces is really satisfying and makes you really appreciate it once code base grows. Love it now.

Collapse
 
avatarkaleb profile image
Kaleb M

Agreed! Makes it so much easier to maintain standards for a team or big project :)

Collapse
 
cesar_mostacero profile image
Cesar Mostacero

Definitely, yes!
Code should not be enough, we should create quality code, and linters are one of the parts to achieve it.

Good post, Kaleb!

Collapse
 
avatarkaleb profile image
Kaleb M

Thanks Cesar! I definitely agree!

Collapse
 
avatarkaleb profile image
Kaleb M

lol! I've heard the TS tools make dev really wonderful with VSCode