Streamlining Frontend Code Quality: A Deep Dive into Eslint and Prettier Integration at GoComet
Implementing a solid centralized linting system can enhance the efficiency of developers and avoid typical syntax issues and general javascript, react pitfalls during the development process. Therefore, it is essential to have a well-tailored linting system that aligns with our requirements.
Problems we are facing
- Like every other typical production codebase, we are already using a preconfigured ESLint setup bundled with Next.js. While ESLint primarily serves as a linter, it also includes certain code formatting rules. However, these formatting rules can occasionally clash with the rules set by Prettier, leading to inconsistencies in our code.
- The problem with using ESLlint and Prettier together is we need to sync both of these tools’ configs to avoid code formatting conflicts, which is challenging because They are both opinionated tools having different code formatting style guides.
- Another problem was not having a pre-commit hook in place which detects ESLint issues and prompts the developer to fix it in place before committing.
In this article, I have described how we fixed the above-mentioned problems and improved the overall developer experience.
What we use
Our Client-side application is developed using Next.js, which provides an excellent default configuration for linting. However, there is always room for improvement, and we leverage industry-standard tools such as ESLint and Prettier to ensure code quality.
For linting and code formatting, we use the Airbnb style guide as the base configuration for JavaScript. Additionally, we use eslint-plugin-prettier to integrate Prettier into our linting process. This plugin allows Prettier to be run as an ESLlint rule, which detects and reports any code formatting issues as individual ESLint issues
Why we use Prettier as an ESLint Rule
Previously, we were able to use ESLint and Prettier as separate tools, but there are advantages to having them work together. Specifically, Prettier’s code formatting issues are identified directly within the editor, allowing developers to address them on the spot. Additionally, since Prettier has been integrated into our Linting process, we no longer need to manage these two tools separately.
But, one caveat is that ESLlint also has some code formatting rules such as enforcing indentation and semi-colons. Since we are integrating Prettier as an ESLint rule, there might be some conflicting rules which is problematic.
Prettier is a more comprehensive and dependable code formatter as compared to ESLint. As a result, we prefer to have Prettier handle all code formatting concerns, while ESLint focuses solely on handling syntactical linting issues and best practices where the tool is actually good.
After installing the eslint-plugin-prettier plugin we want all the ESLint code formatting rules to be turned off, otherwise, there may be conflicts with Prettier. To accomplish this, we used the eslint-config-prettier configuration from https://github.com/prettier/eslint-config-prettier, which essentially disables all of ESLint’s code formatting rules, allowing Prettier to function smoothly.
Configuring VSCode according to this setup
As almost all of our frontend developers use VSCode as their primary code editor, it’s crucial that our existing linting setup is seamlessly integrated with it.
To accomplish this, we require the ESLint extension for VSCode so that linting errors appear directly within the editor. However, we also want to ensure that all auto-fixable issues are handled by the editor itself. To achieve this, we’ve added the following settings to our VSCode settings.json file:
"editor.codeActionsOnSave": [
"source.fixAll.eslint"
],By doing so, we’re able to automatically fix all auto-fixable issues, including those related to Prettier. As a result, we no longer need to have the format-on-save settings enabled, as this is now unnecessary.
Further improving our setup with pre-commit hooks
Currently, we are at a phase where we cannot afford to unintentionally push any linting errors. To avoid such a scenario, we have introduced a pre-commit hook that assesses our code for any linting errors and notifies us about them. This approach guarantees that no flawed code is pushed to the repository.
However, running ESLint on our entire codebase is time-consuming and needless. Instead, we prefer to only lint files that have undergone changes. Therefore, we leverage the benefits of lint-staged, which enables us to execute our pre-commit hook solely on the staged files. Consequently, the linting process becomes much quicker.
"lint-staged": {
"*.{js,jsx,ts,tsx,css}": [
"prettier - write",
"eslint - ext .js,.ts,.jsx,.tsx"
]
},Wrapping up
Investing time in Improving our linting and code formatting setup has made our development experience better and more streamlined. Our setup is opinionated and reflects our preferences and what works well for us, although one might not want to use prettier as an ESLint rule. It ultimately depends on how you want to use your tools. The beauty lies in the customization options available — you can adapt these tools to align with your specific requirements. Looking ahead, we’ll continue exploring emerging tools and plugins within the frontend linting ecosystem to reinforce and fortify our existing setup.
