You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
69 lines
3.3 KiB
69 lines
3.3 KiB
2 years ago
|
# @rushstack/eslint-patch
|
||
|
|
||
|
A patch that improves how ESLint loads plugins when working in a monorepo with a reusable toolchain
|
||
|
|
||
|
|
||
|
## What it does
|
||
|
|
||
|
This patch is a workaround for a longstanding [ESLint feature request](https://github.com/eslint/eslint/issues/3458)
|
||
|
that would allow a shared ESLint config to bring along its own plugins, rather than imposing peer dependencies
|
||
|
on every consumer of the config. In a monorepo scenario, this enables your lint setup to be consolidated in a
|
||
|
single NPM package. Doing so greatly reduces the copy+pasting and version management for all the other projects
|
||
|
that use your standard lint rule set, but don't want to be bothered with the details.
|
||
|
|
||
|
ESLint provides partial solutions such as the `--resolve-plugins-relative-to` CLI option, however they are
|
||
|
awkward to use. For example, the VS Code extension for ESLint must be manually configured with this CLI option.
|
||
|
If some developers use other editors such as WebStorm, a different manual configuration is needed.
|
||
|
Also, the `--resolve-plugins-relative-to` parameter does not support multiple paths, for example if a config package
|
||
|
builds upon another package that also provides plugins. See
|
||
|
[this discussion](https://github.com/eslint/eslint/issues/3458#issuecomment-516666620)
|
||
|
for additional technical background.
|
||
|
|
||
|
|
||
|
## Why it's a patch
|
||
|
|
||
|
ESLint's long awaited module resolver overhaul still has not materialized as of ESLint 8. As a stopgap,
|
||
|
we created a small **.eslintrc.js** patch that solves the problem adequately for most real world scenarios.
|
||
|
This patch was proposed as an ESLint feature with [PR 12460](https://github.com/eslint/eslint/pull/12460), however
|
||
|
the maintainers were not able to accept it unless it is reworked into a fully correct design. Such a requirement
|
||
|
would impose the same hurdles as the original GitHub issue; thus, it seems best to stay with the patch approach.
|
||
|
|
||
|
Since the patch is now in wide use, we've converted it into a proper NPM package to simplify maintenance.
|
||
|
|
||
|
|
||
|
## How to use it
|
||
|
|
||
|
Add a `require()` call to the to top of the **.eslintrc.js** file for each project that depends on your shared
|
||
|
ESLint config, for example:
|
||
|
|
||
|
**.eslintrc.js**
|
||
|
```ts
|
||
|
require("@rushstack/eslint-patch/modern-module-resolution");
|
||
|
|
||
|
// Add your "extends" boilerplate here, for example:
|
||
|
module.exports = {
|
||
|
extends: ['@your-company/eslint-config'],
|
||
|
parserOptions: { tsconfigRootDir: __dirname }
|
||
|
};
|
||
|
```
|
||
|
|
||
|
With this change, the local project no longer needs any ESLint plugins in its **package.json** file.
|
||
|
Instead, the hypothetical `@your-company/eslint-config` NPM package would declare the plugins as its
|
||
|
own dependencies.
|
||
|
|
||
|
This patch works by modifying the ESLint engine so that its module resolver will load relative to the folder of
|
||
|
the referencing config file, rather than the project folder. The patch is compatible with ESLint 6, 7, and 8.
|
||
|
It also works with any editor extensions that load ESLint as a library.
|
||
|
|
||
|
For an even leaner setup, `@your-company/eslint-config` can provide the patch as its own dependency. See
|
||
|
[@rushstack/eslint-config](https://www.npmjs.com/package/@rushstack/eslint-config) for a real world example
|
||
|
and recommended approach.
|
||
|
|
||
|
|
||
|
## Links
|
||
|
|
||
|
- [CHANGELOG.md](https://github.com/microsoft/rushstack/blob/main/eslint/eslint-patch/CHANGELOG.md) - Find
|
||
|
out what's new in the latest version
|
||
|
|
||
|
`@rushstack/eslint-patch` is part of the [Rush Stack](https://rushstack.io/) family of projects.
|