ESLint Shared Configuration

Recently, I migrated multiple web projects from TSLint to ESLint. The next issue was sharing ESLint configurations, and naturally, the solution is still npm package management

Package Project Structure

├── CHANGELOG.md
├── README.md
├── commitlint.config.js
├── index.js // 规则配置
├── package.json
└── yarn.lock

For specific content, click here

Key Points

1. Package version management still uses standard-version
2. The files field in package.json restricts published files to only index.js. Of course, package.json, README.md, and CHANGELOG.md are defaults, so these three can be omitted.
3. Shared configuration doesn’t just share Rules, but also plugins. This way, actual web projects only need to inherit the package’s plugin configuration to get all configuration items completely, so multiple projects’ ESLint configurations have almost nothing left.
4. Here, I published the package to the NPM public repository. Since package names are easily duplicated, I added scope configuration, which is stacker here.

Publishing

# Login
$ npm adduser

## Publish
$ npm publish --access=public

Key Points

1. Adding access to the publish command is because I added scope, and this defaults to private package publishing, so it needs to be specified explicitly, otherwise it will prompt no permission. Of course, if you need to publish a private package, this isn’t necessary.
2. If you get a 403 error, one reason is not being logged in, another reason is that the scope is already registered, so you don’t have permission.

Final Thoughts

1. TSLint will be in its final year this year and will exit the historical stage. You can search for the reasons on my blog
2. The purpose of ESLint shared configuration is to unify the code style of multiple projects. If sharing isn’t implemented, we have to copy and paste to control each project manually, which often results in omissions. Over time, multiple web projects develop many style divergences, and serious cases even have bugs, so it’s not a good approach. Now using public packages can quickly unify things. If custom rules are needed, they can also be implemented in the package, and projects only need to upgrade the package to apply them quickly, which is still very convenient.