Configuring ESLint and Prettier for WordPress React Plugins

Previously in this course, we covered the Introduction to @wordpress/scripts to handle our build process. Now that we have a functional build pipeline, we need to ensure the code we're shipping meets professional standards.

Manual code reviews are slow and error-prone. By integrating ESLint and Prettier, we automate Code Quality, allowing our tools to catch common bugs and formatting inconsistencies before we even run our code.

Why ESLint and Prettier?

In a professional WordPress environment, consistency is king. ESLint focuses on logic and syntax—it catches undefined variables, unreachable code, and misuse of React hooks. Prettier, on the other hand, focuses on style—line breaks, indentation, and semicolon placement.

When used together, they eliminate "nitpicking" during code reviews. You spend less time worrying about tabs versus spaces and more time building features. Since we are using @wordpress/scripts, we already have the foundation for these tools.

Configuring ESLint

The @wordpress/scripts package comes with a pre-configured ESLint setup designed for WordPress development. However, we need to extend it for our specific needs.

1. Create a .eslintrc.json file in your plugin root.
2. Extend the WordPress configuration.

JSON
{
  "extends": [
    "plugin:@wordpress/eslint-plugin/recommended"
  ],
  "rules": {
    "no-console": "warn",
    "react/react-in-jsx-scope": "off"
  }
}

By extending plugin:@wordpress/eslint-plugin/recommended, you inherit rules that enforce WordPress coding standards for JavaScript. I've added no-console: "warn" because while we want to avoid console.log in production, they are often useful during development.

Implementing Prettier

Prettier ensures your code looks identical regardless of who wrote it. To implement it:

1. Install the Prettier package via npm: npm install --save-dev prettier
2. Create a .prettierrc file in your root directory:

JSON
{
  "singleQuote": true,
  "trailingComma": "es5",
  "printWidth": 80,
  "tabWidth": 2,
  "semi": true
}

This configuration ensures your code adheres to common modern JS standards. To make this work seamlessly with your editor, I highly recommend installing the Prettier extension for VS Code and enabling "Format on Save."

Resolving Linting Errors

Let’s advance our Knowledge Base plugin project. Suppose you have a component Dashboard.js with some messy code. Run the following command in your terminal:

npm run lint

If ESLint reports errors, you have two choices: fix them manually, or let the tool help. You can update your package.json scripts to include an auto-fixer:

JSON
"scripts": {
  "lint:js": "eslint .",
  "lint:js:fix": "eslint . --fix"
}

Running npm run lint:js:fix will automatically resolve many issues, such as missing semicolons or incorrect indentation, saving you significant manual effort.

Hands-on Exercise

1. Add the .eslintrc.json and .prettierrc files to your plugin folder as shown above.
2. Run npm run lint:js and identify at least three errors in your existing src/ folder.
3. Use the --fix command to resolve them.
4. If errors remain that cannot be auto-fixed (like missing dependencies in a useEffect hook), manually correct them to meet the WordPress standard.

Common Pitfalls

• Ignoring the node_modules folder: Always ensure your .eslintignore file (or the ignore patterns in your config) excludes node_modules and your build/ directory. Linting third-party code is a waste of resources and will result in thousands of false positives.
• Conflicting Rules: If you install both ESLint and Prettier, they might fight over formatting rules (like indentation). Use eslint-config-prettier to disable ESLint rules that might conflict with Prettier.
• Over-customization: Stick to the WordPress recommended rules as much as possible. WordPress has a specific ecosystem; fighting the standards usually results in cleaner, more maintainable code when collaborating with other developers.

Recap

We have successfully integrated automated tooling into our workflow. By configuring ESLint and Prettier, we ensure that our codebase remains consistent, readable, and free of common syntax errors. This is the first step toward Refactoring for Clean Code: Improving React Maintainability as our project grows in complexity.

Up next: We will explore how to pass API base URLs and nonces from PHP to our JavaScript environment, ensuring our React components can securely communicate with the REST API.