RFC #14 proposes a way for a shared ESLint config package to supply its own plugin dependencies, rather than imposing that responsibility on every consumer of the package. But because that RFC seeks to design a comprehensive solution, its discussion has been open for a long time without encouraging progress. In the interim, RFC 46 proposes a temporary workaround. It will allow users to opt-in to a resolution behavior that works well in practice (despite having some known limitations). This this new would be designated as experimental, with the intent to remove it when/if the ideal solution finally ships.
For the more narrow (and perhaps more common) scenario tackled by this RFC, please refer to this comment from ESLint issue 3458.
The more general set of requirements is already spelled out in RFC #14.
Change line 841 of config-array-factory.js from this:
try {
filePath = ModuleResolver.resolve(request, relativeTo);
} catch (resolveError) {...to this:
try {
filePath = ModuleResolver.resolve(request, importerPath);
} catch (resolveError) {Gate this change behind a new option resolveRelativeToConfigFile in .eslintrc.js. It is an optional boolean
value that is false by default. Thus this behavior will be off by default.
A complete implementation is already provided in ESLint PR 12460.
The PR will include documentation for the new option.
The resolveRelativeToConfigFile feature does not consider all possible design considerations, such as naming
conflicts between plugins. The PR also assumes that resolveRelativeToConfigFile is assigned by the main project,
not by an extended config. This is okay, because it's a temporary workaround. It's not meant to be an ideal design.
No impact, because the option is off by default.
If RFC #14 can be completed and implemented within a reasonable timeframe, then this workaround would not be needed.
None.
None.
In order to modify one line of logic, do we really need to wait an entire month (21 + 7 days) for an "RFC"?
Yes, the ESLint maintainers have insisted on this formalism.
Back in July, the workaround was presented as a monkey patch. Several people are using it in large multi-project repos for serious shipping applications, and they've reported that it works correctly. Thus, it's "good enough" for many people who would be otherwise blocked.
Monkey patching is awkward and brittle. An .eslintrc.js file should not probe into the ESLint binary and overwrite its module objects at runtime. It may be acceptable for small projects, but at a large company, project admins would be rightly concerned about the supportability of such a solution.
None.