Skip to content

Latest commit

 

History

History
97 lines (62 loc) · 3.66 KB

README.md

File metadata and controls

97 lines (62 loc) · 3.66 KB
Raw

Add resolveRelativeToConfigFile setting

Summary

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 resolveRelativeToConfigFile option would be designated as experimental, with the intent to remove it when/if the ideal solution finally ships.

Motivation

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.

Detailed Design

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.

Documentation

The PR will include documentation for the new option.

Drawbacks

The resolveRelativeToConfigFile feature does not consider all possible design considerations, such as conflicts between plugins. The PR also assumes that resolveRelativeToConfigFile is not set back to false after it has been set to true. Once it is enabled, it affects all subsequent module resolutions.

This is acceptable because it's a temporary workaround. It's not meant to be an ideal design.

Backwards Compatibility Analysis

No impact, because the option is off by default.

Alternatives

If RFC #14 can be completed and implemented within a reasonable timeframe, then this workaround would not be needed.

Open Questions

Since a PR has already been created, please provide feedback on the implementation details.

Help Needed

None.

Frequently Asked Questions

In order to modify one line of logic, do we really need to wait an entire month for the RFC process?

Yes, the ESLint maintainers have requested this.

Why should we accept a solution with known limitations?

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.

Why can't everyone just use a monkey patch then?

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.

Related Discussions

None.