Code Linting

Today was a great day, because I got to work on integrating ESLint into our codebase! I'm a funny code monkey. I enjoy good coding practices like linting, user/technical/product documentation, testing, accessibility, and security. These are topics that are usually deprioritized over shipping working code, because code can work without any of the things I listed as my programming passions. But if all those practices are implemented the code will rarely break (or be broken) and is more reliable code. Why not create "reliable working code" from the start?

Why I like Linting?

Linting will help you catch common errors early. Linting rules can identify poor coding practices, so developers don't introduce them into the project. Linting can identify when to use const instead of let, or shadow variables, for example.

Preventing bad code with linting, is worth the many sprints of debugging poor code.

My Challenge

We had an existing codebase that had many developers contributing. The code had over 5K linting violations after I installed ESLint and ran a report. I looked for the best linting rules to use with NextJS, TypeScript, A11y, and JavaScript. Since there were so many violations I decided to progressively hunt for errors. ESLint has an auto fix feature but never run that on a pre-existing codebase and expect it to work. No, no, no youngling. We must iterate!

I set the critical rules to ❌ "error" and the rest to "warn" or "off". Then I re-ran the report to identify what should be fixed before deploying our code again. After all errors are fixed manually and the code can build I ran our unit test to ensure we were still ✅ passing everything. Good linting should never break the code. At best linting is meant to support the developer. Helping junior devs learn a better way of writing code, because they have to.

After all my errors have been identified and fixed OR ignored, then we can deploy and know that our code is as good as we can get it "today". Now that the codebase has been fixed we can use "auto-magic-fix" in the future and feel confident it has a 50/50 chance of fixing the linting error.

My Learning

It seems ESLint has grown up! It will no longer support some more code formatting rules, that should be maintained by a code formatting library and not a linting library. ESLint has deprecated many features as of v9 and moved most, if not all, to Stylistic!

I use Prettier for code formatting and Typescript has flag support in Stylistic so I stuck with ESLint v8.53.0 so I could keep the superior code formatting of ESLint. But I will have to move eventually into 9 so this only "kicked the can down the road".

Happy Coding!

The above is the detailed content of Code Linting. For more information, please follow other related articles on the PHP Chinese website!