@wordpress\/create-block<\/code>, so we will use it to create a template:<\/p>\n\n\n\nnpx @wordpress\/create-block gutenpride<\/code><\/pre>\n\n\n\nIf you open the directory called gutenpride<\/code>, it should consist of the following files:<\/p>\n\n\n\n![\"create-block](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/eslint-file-structure.png\")
<\/figure>\n\n\n\nEditorConfig<\/h2>\n\n\n\n
Looking at the file structure, we can see that there is a file called .editorconfig<\/code>. Before introducing ESLint, I would like to explain EditorConfig, which is another important setting for unifying coding style.<\/p>\n\n\n\nAs one reason for introducing EditorConfig, I would like to give the following example:<\/p>\n\n\n\n
\n- Multiple developers are involved in one plugin.<\/li>\n\n\n\n
- Developer A has set the indentation to two half-width spaces in the default settings of his code editor.<\/li>\n\n\n\n
- Developer B has set the indentation to tabs in the default settings of his code editor, with an indentation width of four characters.<\/li>\n<\/ul>\n\n\n\n
Suppose Developer A wrote the following code. Note that all the indentations are spaces.<\/p>\n\n\n\n![\"2\u30b9\u30da\u30fc\u30b9\u30a4\u30f3\u30c7\u30f3\u30c8\u3092\u6301\u3064\u30b3\u30fc\u30c9\"](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/eslint-space-indent-840x256.png\")
<\/figure>\n\n\n\nDeveloper B opens the file with this code in his or her code editor, removes the indentation of 34 lines, and then visually<\/em> rearranges the indentation so that it is correct.<\/p>\n\n\n\n![\"\u4e00\u90e8\u306b\u30bf\u30d6\u30a4\u30f3\u30c7\u30f3\u30c8\u3092\u6301\u3064\u30b3\u30fc\u30c9\"](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/eslint-tab-indent-840x201.png\")
<\/figure>\n\n\n\nHowever, if Developer A reopens the file, he or she sees that the indentation on line 34 is visually incorrect.<\/p>\n\n\n\n![\"\u4e00\u90e8\u306b\u30bf\u30d6\u30a4\u30f3\u30c7\u30f3\u30c8\u3092\u6301\u3064\u30b3\u30fc\u30c9\"](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/eslint-space-indent-with-tab-840x247.png\")
<\/figure>\n\n\n\nSome code editors may automatically detect the indentation of a file, but it is not guaranteed that the indentation will be visually consistent between all developers.<\/p>\n\n\n\n
One reason to introduce EditorConfig is to prevent such differences and unify coding style within a project.<\/p>\n\n\n\n
EditorConfig is supported by a large number of code editors. For some code editors, you may need to install a plugin. Check the following page to see if your code editor requires an additional plugin:<\/p>\n\n\n\n
\n- EditorConfig – No Plugin Necessary<\/a><\/li>\n\n\n\n
- EditorConfig – Download a Plugin<\/a><\/li>\n<\/ul>\n\n\n\n
EditorConfig for create-block<\/h3>\n\n\n\n
Now let’s take a look at the .editorconfig<\/code> settings created by create-block.<\/p>\n\n\n\n# This file is for unifying the coding style for different editors and IDEs\n# editorconfig.org\n\n# WordPress Coding Standards\n# https:\/\/make.wordpress.org\/core\/handbook\/coding-standards\/\n\nroot = true\n\n[*]\ncharset = utf-8\nend_of_line = lf\ninsert_final_newline = true\ntrim_trailing_whitespace = true\nindent_style = tab\n\n[*.{yml,yaml}]\nindent_style = space\nindent_size = 2<\/code><\/pre>\n\n\n\nLooking at the settings in this file, for example, we can see that the indentation rule mentioned above is set to “tab indent.” You can customize these rules to your liking, but the important thing is whether the coding style is consistent across the entire project based on the rules<\/strong>.<\/p>\n\n\n\nI strongly recommend that you define rules using EditorConfig before introducing ESLint.<\/p>\n\n\n\n
Check JavaScript Code with ESlint<\/h2>\n\n\n\n
Returning to the topic of ESLint, let’s say you update the Edit<\/code> component of a block to store the text the block displays in the my_variable<\/code> variable.<\/p>\n\n\n\nexport default function Edit() {\n\tconst my_variable = __( 'Gutenpride \u2013 hello from the editor!', 'gutenpride' );\n\treturn (\n\t\t<p { ...useBlockProps() }>\n\t\t\t{ my_variable }\n\t\t<\/p>\n\t);\n}<\/code><\/pre>\n\n\n\nIf you create a template block using create-block, a mechanism for analyzing such code using ESLint is included by default. Let’s try running the lint:js<\/code> script defined in the scripts<\/code> field of package.json<\/code>.<\/p>\n\n\n\nnpm run lint:js<\/code><\/pre>\n\n\n\nWhen you run this script, you should see an error similar to the following:<\/p>\n\n\n\n![\"lint:js](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/lint-error-840x184.png\")
<\/figure>\n\n\n\nThis error tells us that the code does not follow two rules:<\/p>\n\n\n\n
\n- The variable name
my_variable<\/code> is not in camel case<\/a><\/li>\n\n\n\n- Line breaks and indentation are not correct<\/li>\n<\/ul>\n\n\n\n
Fix Lint Errors Automatically<\/h3>\n\n\n\n
So, to fix these errors, do we have to fix them all manually and run lint:js<\/code> over and over again until the errors are fixed?<\/p>\n\n\n\nLike lint:js<\/code>, create-block has the format<\/code> script to fix these errors to some extent automatically.<\/p>\n\n\n\n$ npm run format\n\n> gutenpride@0.1.0 format\n> wp-scripts format\n\npackage-lock.json 129ms\npackage.json 1ms\nsrc\/block.json 5ms\nsrc\/edit.js 10ms\nsrc\/index.js 3ms\nsrc\/save.js 2ms\nsrc\/view.js 2ms<\/code><\/pre>\n\n\n\nWhen you run this command, one of the two errors that was warned about, “errors related to line breaks and indentation,” will be automatically corrected.<\/p>\n\n\n\n
export default function Edit() {\n\tconst my_variable = __(\n\t\t'Gutenpride \u2013 hello from the editor!',\n\t\t'gutenpride'\n\t);\n\treturn <p { ...useBlockProps() }>{ my_variable }<\/p>;\n}<\/code><\/pre>\n\n\n\nFix Lint Errors Manually<\/h3>\n\n\n\n
However, errors in variable names are not automatically fixed. The format<\/code> command does not automatically fix all errors, so you must manually fix any remaining errors. Change the variable name to camel case (myVariable<\/code>) as follows:<\/p>\n\n\n\nexport default function Edit() {\n\tconst myVariable = __(\n\t\t'Gutenpride \u2013 hello from the editor!',\n\t\t'gutenpride'\n\t);\n\treturn <p { ...useBlockProps() }>{ myVariable }<\/p>;\n}<\/code><\/pre>\n\n\n\nIf you run npm run lint:js<\/code> you should be able to confirm that all errors have been resolved.<\/p>\n\n\n\nWhere are These ESLint Rules Defined?<\/h3>\n\n\n\n
Why is my code being analyzed based on certain rules even though I haven’t defined any ESLint rules myself?<\/p>\n\n\n\n
When a file template is created with create-block, a library called @wordpress\/scripts<\/code> is installed by default, and ESLint rules are defined in a library that this library depends on. That library is @wordpress\/eslint-plugin<\/code>.<\/p>\n\n\n\nUsing the npm ls<\/code> command, you can see that @wordpress\/scripts<\/code> depends on @wordpress\/eslint-plugin<\/code>.<\/p>\n\n\n\n$ npm ls @wordpress\/eslint-plugin\ngutenpride@0.1.0 \/home\/username\/projects\/gutenpride\n\u2514\u2500\u252c @wordpress\/scripts@30.3.0\n \u2514\u2500\u2500 @wordpress\/eslint-plugin@21.3.0<\/code><\/pre>\n\n\n\nWhen you run lint:js<\/code>, that is, the wp-scripts lint-js<\/code> script, your code will be analyzed based on the rules defined in @wordpress\/eslint-plugin<\/code>.<\/p>\n\n\n\nYou can also see that ESLint itself exists as a dependency.<\/p>\n\n\n\n
$ npm ls eslint\ngutenpride@0.1.0 \/home\/username\/projects\/gutenpride\n\u2514\u2500\u252c @wordpress\/scripts@30.3.0\n \u251c\u2500\u252c @wordpress\/eslint-plugin@21.3.0\n \u2502 \u251c\u2500\u252c @babel\/eslint-parser@7.25.7\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c @typescript-eslint\/eslint-plugin@6.21.0\n \u2502 \u2502 \u251c\u2500\u252c @typescript-eslint\/type-utils@6.21.0\n \u2502 \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u2502 \u251c\u2500\u252c @typescript-eslint\/utils@6.21.0\n \u2502 \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c @typescript-eslint\/parser@6.21.0\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-config-prettier@8.10.0\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-import@2.31.0\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-jest@27.9.0\n \u2502 \u2502 \u251c\u2500\u252c @typescript-eslint\/utils@5.62.0\n \u2502 \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-jsdoc@46.10.1\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-jsx-a11y@6.10.1\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-playwright@0.15.3\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-prettier@5.2.1\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-react-hooks@4.6.2\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u251c\u2500\u252c eslint-plugin-react@7.37.2\n \u2502 \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2502 \u2514\u2500\u2500 eslint@8.57.1 deduped\n \u2514\u2500\u252c eslint@8.57.1\n \u2514\u2500\u252c @eslint-community\/eslint-utils@4.4.1\n \u2514\u2500\u2500 eslint@8.57.1 deduped<\/code><\/pre>\n\n\n\nExtend ESLint Rules<\/h2>\n\n\n\n
Of course, you can develop based only on these default rules. However, some developers may want to change some of the rules to suit their preferences or apply stricter rules.<\/p>\n\n\n\n
To change or extend these default rules, create a file called .eslintrc<\/code> in the root directory of your project and write the following code in it:<\/p>\n\n\n\n{\n\t\"extends\": [ \"plugin:@wordpress\/eslint-plugin\/recommended\" ]\n}<\/code><\/pre>\n\n\n\nWhen you run the lint:js<\/code> script, your code will be analyzed based on the rules defined here.<\/p>\n\n\n\nTweak Existing Rules<\/h3>\n\n\n\n
Try updating this file to change an existing rule.<\/p>\n\n\n\n
For example, say you wrote the following code to use an API prefixed with __experimental<\/code>.<\/p>\n\n\n\nNote: this is just an example; there is no library called @wordpress\/foo<\/code> and no API called __experimentalFeature<\/code>.<\/p>\n\n\n\nimport { __experimentalFeature } from '@wordpress\/foo';\n\nexport default function Edit() {\n\tconst myVariable = __(\n\t\t'Gutenpride \u2013 hello from the editor!',\n\t\t'gutenpride'\n\t);\n\treturn <p { ...useBlockProps() }>{ myVariable }<\/p>;\n}<\/code><\/pre>\n\n\n\nWhen you run lint:js<\/code> you will get the following two errors:<\/p>\n\n\n\n![\"lint:js](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/lint-error-experimental-feature-840x136.png\")
<\/figure>\n\n\n\nOf these two errors, pay attention to the error that says “Usage of __experimentalFeature<\/code> from @wordpress\/foo<\/code> is not allowed.” This rule is defined by default in @wordpress\/eslint-plugin<\/code>, and you can find more information about the rule in this README<\/a>.<\/p>\n\n\n\nTo disable this rule for the entire project, change the .eslintrc<\/code> file as follows:<\/p>\n\n\n\n{\n\t\"extends\": [ \"plugin:@wordpress\/eslint-plugin\/recommended\" ],\n\t\"rules\": {\n\t\t\"@wordpress\/no-unsafe-wp-apis\": \"off\"\n\t}\n}<\/code><\/pre>\n\n\n\nIf you run the lint:js<\/code> script again, you should see that the errors related to APIs with the __experimental<\/code> prefix disappear.<\/p>\n\n\n\nThis rule is also disabled in the Gutenberg project<\/a>.<\/p>\n\n\n\nAdd New Rules<\/h3>\n\n\n\n
I would like to introduce some rules that I personally recommend to improve the code quality and security of block development. These rules are not included in the default rules of @wordpress\/eslint-plugin<\/code>, so you need to add them explicitly.<\/p>\n\n\n\nreact\/jsx-boolean-value<\/a><\/h4>\n\n\n\nIn React, enforces rules when the value of a prop is a boolean<\/code> and true<\/code>.<\/p>\n\n\n\n{\n\t\"extends\": [ \"plugin:@wordpress\/eslint-plugin\/recommended\" ],\n\t\"rules\": {\n\t\t\"react\/jsx-boolean-value\": \"error\"\n\t}\n}<\/code><\/pre>\n\n\n\n\u2705 Do<\/p>\n\n\n\n
const Hello = <Hello myProp \/>;<\/code><\/pre>\n\n\n\n\u274c Don’t<\/p>\n\n\n\n
const Hello = <Hello myProp={ true } \/>;<\/code><\/pre>\n\n\n\n@wordpress\/i18n-text-domain<\/a><\/h4>\n\n\n\nThis forces you to add the correct text domain to your translation functions. Change the value of the allowedTextDomain<\/code> field to suit your project.<\/p>\n\n\n\n{\n\t\"extends\": [ \"plugin:@wordpress\/eslint-plugin\/recommended\" ],\n\t\"rules\": {\n\t\t\"@wordpress\/i18n-text-domain\": [\n\t\t\t\"error\",\n\t\t\t{\n\t\t\t\t\"allowedTextDomain\": \"gutenpride\"\n\t\t\t}\n\t\t]\n\t}\n}<\/code><\/pre>\n\n\n\n\u2705 Do<\/p>\n\n\n\n
export default function Edit() {\n\tconst myVariable = __(\n\t\t'Gutenpride \u2013 hello from the editor!',\n\t\t'gutenpride'\n\t);\n\treturn <p { ...useBlockProps() }>{ myVariable }<\/p>;\n}<\/code><\/pre>\n\n\n\n\u274c Don’t<\/p>\n\n\n\n
export default function Edit() {\n\tconst myVariable = __(\n\t\t'Gutenpride \u2013 hello from the editor!'\n\t);\n\treturn <p { ...useBlockProps() }>{ myVariable }<\/p>;\n}<\/code><\/pre>\n\n\n\n@wordpress\/dependency-group<\/a><\/h4>\n\n\n\nWhen you import code from another source, it forces you to group them properly and add comments.<\/p>\n\n\n\n
{\n\t\"extends\": [ \"plugin:@wordpress\/eslint-plugin\/recommended\" ],\n\t\"rules\": {\n\t\t\"@wordpress\/dependency-group\": \"error\"\n\t}\n}<\/code><\/pre>\n\n\n\n\u2705 Do<\/p>\n\n\n\n
\/*\n * External dependencies\n *\/\nimport { camelCase } from 'change-case';\n\n\/*\n * WordPress dependencies\n *\/\nimport { Component } from 'react';\n\n\/*\n * Internal dependencies\n *\/\nimport edit from '.\/edit';<\/code><\/pre>\n\n\n\n\u274c Don’t<\/p>\n\n\n\n
import { camelCase } from 'change-case';\nimport { Component } from 'react';\nimport edit from '.\/edit';<\/code><\/pre>\n\n\n\n.eslintrc with the Rules Applied So Far<\/h3>\n\n\n\n
With all the changed and new rules applied to your .eslintrc<\/code>, you should end up with something like this: Use this code as a guide to find the rules that best suit your project and preferences.<\/p>\n\n\n\n{\n\t\"extends\": [ \"plugin:@wordpress\/eslint-plugin\/recommended\" ],\n\t\"rules\": {\n\t\t\"@wordpress\/no-unsafe-wp-apis\": \"off\",\n\t\t\"react\/jsx-boolean-value\": \"error\",\n\t\t\"@wordpress\/i18n-text-domain\": [\n\t\t\t\"error\",\n\t\t\t{\n\t\t\t\t\"allowedTextDomain\": \"gutenpride\"\n\t\t\t}\n\t\t],\n\t\t\"@wordpress\/dependency-group\": \"error\"\n\t}\n}<\/code><\/pre>\n\n\n\nDetect Lint Rule Violations in the Code Editor<\/h2>\n\n\n\n
So far, we have fixed Lint errors and changed\/added rules. But does that mean we need to run the lint:js<\/code> or format<\/code> script every time we update our code to detect and fix these errors?<\/p>\n\n\n\nMany code editors automatically read the ESLint rules in your project and detect them as errors in the code editor, or automatically fix code that violates the rules when you save the file.<\/p>\n\n\n\n
Here, I’ll introduce the method I usually use in VSCode.<\/p>\n\n\n\n
First, install the ESLint extension<\/a> in VSCode and make sure ESLint is enabled in the user or workspace settings.<\/p>\n\n\n\n![\"\u30e6\u30fc\u30b6\u30fc\u8a2d\u5b9a\u3067\u6709\u52b9\u5316\u3055\u308c\u3066\u3044\u308b](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/eslint-extension-840x350.png\")
<\/figure>\n\n\n\nIf the ESLint extension is enabled and you have code that violates a rule, you should see a warning like this:<\/p>\n\n\n\n![\"ESLint](\"https:\/\/aki-hamano.blog\/wp-content\/uploads\/2024\/10\/vscode-eslint-error-840x266.png\")
<\/figure>\n\n\n\nDocuments<\/h2>\n\n\n\n\n- @wordpress\/scripts \u2013 Block Editor Handbook | Developer.WordPress.org<\/a><\/li>\n\n\n\n
- @wordpress\/eslint-plugin \u2013 Block Editor Handbook | Developer.WordPress.org<\/a><\/li>\n\n\n\n
- EditorConfig<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
In this article, I would like to explain how to introduce ESLint to improve the quality of JavaScript code and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_locale":"en_US","_original_post":"https:\/\/aki-hamano.blog\/?p=1187","footnotes":""},"categories":[21],"tags":[],"class_list":["post-1318","post","type-post","status-publish","format-standard","hentry","category-block-development","en-US"],"_links":{"self":[{"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/posts\/1318","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/comments?post=1318"}],"version-history":[{"count":35,"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/posts\/1318\/revisions"}],"predecessor-version":[{"id":1356,"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/posts\/1318\/revisions\/1356"}],"wp:attachment":[{"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/media?parent=1318"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/categories?post=1318"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aki-hamano.blog\/wp-json\/wp\/v2\/tags?post=1318"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}