From 293df670cb7b93626e656d042a2b19146ff42548 Mon Sep 17 00:00:00 2001
From: Pete Gonzalez <4673363+octogonz@users.noreply.github.com>
Date: Mon, 4 Nov 2019 21:30:45 -0800
Subject: [PATCH 1/4] Add template

---
 .../2019-workaround-for-issue-3458/README.md  | 103 ++++++++++++++++++
 1 file changed, 103 insertions(+)
 create mode 100644 designs/2019-workaround-for-issue-3458/README.md

diff --git a/designs/2019-workaround-for-issue-3458/README.md b/designs/2019-workaround-for-issue-3458/README.md
new file mode 100644
index 00000000..069fc321
--- /dev/null
+++ b/designs/2019-workaround-for-issue-3458/README.md
@@ -0,0 +1,103 @@
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: (leave this empty, to be filled in later)
+- Authors: (the names of everyone contributing to this RFC)
+
+# (RFC title goes here)
+
+## Summary
+
+<!-- One-paragraph explanation of the feature. -->
+
+## Motivation
+
+<!-- Why are we doing this? What use cases does it support? What is the expected
+outcome? -->
+
+## Detailed Design
+
+<!--
+   This is the bulk of the RFC.
+
+   Explain the design with enough detail that someone familiar with ESLint
+   can implement it by reading this document. Please get into specifics
+   of your approach, corner cases, and examples of how the change will be
+   used. Be sure to define any new terms in this section.
+-->
+
+## Documentation
+
+<!--
+    How will this RFC be documented? Does it need a formal announcement
+    on the ESLint blog to explain the motivation?
+-->
+
+## Drawbacks
+
+<!--
+    Why should we *not* do this? Consider why adding this into ESLint
+    might not benefit the project or the community. Attempt to think 
+    about any opposing viewpoints that reviewers might bring up. 
+
+    Any change has potential downsides, including increased maintenance
+    burden, incompatibility with other tools, breaking existing user
+    experience, etc. Try to identify as many potential problems with
+    implementing this RFC as possible.
+-->
+
+## Backwards Compatibility Analysis
+
+<!--
+    How does this change affect existing ESLint users? Will any behavior
+    change for them? If so, how are you going to minimize the disruption
+    to existing users?
+-->
+
+## Alternatives
+
+<!--
+    What other designs did you consider? Why did you decide against those?
+
+    This section should also include prior art, such as whether similar
+    projects have already implemented a similar feature.
+-->
+
+## Open Questions
+
+<!--
+    This section is optional, but is suggested for a first draft.
+
+    What parts of this proposal are you unclear about? What do you
+    need to know before you can finalize this RFC?
+
+    List the questions that you'd like reviewers to focus on. When
+    you've received the answers and updated the design to reflect them, 
+    you can remove this section.
+-->
+
+## Help Needed
+
+<!--
+    This section is optional.
+
+    Are you able to implement this RFC on your own? If not, what kind
+    of help would you need from the team?
+-->
+
+## Frequently Asked Questions
+
+<!--
+    This section is optional but suggested.
+
+    Try to anticipate points of clarification that might be needed by
+    the people reviewing this RFC. Include those questions and answers
+    in this section.
+-->
+
+## Related Discussions
+
+<!--
+    This section is optional but suggested.
+
+    If there is an issue, pull request, or other URL that provides useful
+    context for this proposal, please include those links here.
+-->

From 9cf0a4475d38563230f4d0bdac8f7bea08888a98 Mon Sep 17 00:00:00 2001
From: Pete Gonzalez <4673363+octogonz@users.noreply.github.com>
Date: Mon, 4 Nov 2019 22:07:30 -0800
Subject: [PATCH 2/4] Fill in template

---
 .../2019-workaround-for-issue-3458/README.md  | 122 ++++++++----------
 1 file changed, 57 insertions(+), 65 deletions(-)

diff --git a/designs/2019-workaround-for-issue-3458/README.md b/designs/2019-workaround-for-issue-3458/README.md
index 069fc321..aeaea06e 100644
--- a/designs/2019-workaround-for-issue-3458/README.md
+++ b/designs/2019-workaround-for-issue-3458/README.md
@@ -1,103 +1,95 @@
-- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- Start Date: 2019-11-04
 - RFC PR: (leave this empty, to be filled in later)
-- Authors: (the names of everyone contributing to this RFC)
+- Authors: Pete Gonzalez ([@octogonz](https://github.com/octogonz))
 
-# (RFC title goes here)
+# Add resolveRelativeToConfigFile setting
 
 ## Summary
 
-<!-- One-paragraph explanation of the feature. -->
+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, this RFC proposes
+a temporary workaround, that allows users opt-in to a resolution behavior that works well in practice (despite having
+some known limitations).  This feature would be designated as experimental, with the intent to remove it when/if
+the ideal solution finally ships.
 
 ## Motivation
 
-<!-- Why are we doing this? What use cases does it support? What is the expected
-outcome? -->
+For the more narrow (and perhaps more common) scenario tackled by this RFC, please refer to
+[this comment](https://github.com/eslint/eslint/issues/3458#issuecomment-516666620) from ESLint issue 3458.
+
+The more general set of requirements is already spelled out in RFC #14.
 
 ## Detailed Design
 
-<!--
-   This is the bulk of the RFC.
+Change [line 841 of config-array-factory.js](
+https://github.com/eslint/eslint/blob/586855060afb3201f4752be8820dc85703b523a6/lib/cli-engine/config-array-factory.js#L845)
+from this:
+
+```js
+        try {
+            filePath = ModuleResolver.resolve(request, relativeTo);
+        } catch (resolveError) {
+```
+
+...to this:
+
+```ts
+        try {
+            filePath = ModuleResolver.resolve(request, importerPath);
+        } catch (resolveError) {
+```
 
-   Explain the design with enough detail that someone familiar with ESLint
-   can implement it by reading this document. Please get into specifics
-   of your approach, corner cases, and examples of how the change will be
-   used. Be sure to define any new terms in this section.
--->
+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](https://github.com/eslint/eslint/pull/12460).
 
 ## Documentation
 
-<!--
-    How will this RFC be documented? Does it need a formal announcement
-    on the ESLint blog to explain the motivation?
--->
+The PR will include documentation for the new option.
 
 ## Drawbacks
 
-<!--
-    Why should we *not* do this? Consider why adding this into ESLint
-    might not benefit the project or the community. Attempt to think 
-    about any opposing viewpoints that reviewers might bring up. 
-
-    Any change has potential downsides, including increased maintenance
-    burden, incompatibility with other tools, breaking existing user
-    experience, etc. Try to identify as many potential problems with
-    implementing this RFC as possible.
--->
+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.
 
 ## Backwards Compatibility Analysis
 
-<!--
-    How does this change affect existing ESLint users? Will any behavior
-    change for them? If so, how are you going to minimize the disruption
-    to existing users?
--->
+No impact, because the option is off by default.
 
 ## Alternatives
 
-<!--
-    What other designs did you consider? Why did you decide against those?
-
-    This section should also include prior art, such as whether similar
-    projects have already implemented a similar feature.
--->
+If RFC #14 can be completed and implemented within a reasonable timeframe, then this workaround would not be needed.
 
 ## Open Questions
 
-<!--
-    This section is optional, but is suggested for a first draft.
+None.
 
-    What parts of this proposal are you unclear about? What do you
-    need to know before you can finalize this RFC?
+## Help Needed
 
-    List the questions that you'd like reviewers to focus on. When
-    you've received the answers and updated the design to reflect them, 
-    you can remove this section.
--->
+None.
 
-## Help Needed
+## Frequently Asked Questions
 
-<!--
-    This section is optional.
+### In order to modify one line of logic, do we really need to wait an entire month (21 + 7 days) for an "RFC"?
 
-    Are you able to implement this RFC on your own? If not, what kind
-    of help would you need from the team?
--->
+Yes, the ESLint maintainers have insisted on this formalism.
 
-## Frequently Asked Questions
+### Why should we accept a solution with known limitations?
 
-<!--
-    This section is optional but suggested.
+Back in July, the workaround was presented as a
+[monkey patch](https://github.com/eslint/eslint/issues/3458#issuecomment-516716165).
+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.
 
-    Try to anticipate points of clarification that might be needed by
-    the people reviewing this RFC. Include those questions and answers
-    in this section.
--->
+### Why can't everyone just use a monkey patch then?
 
-## Related Discussions
+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.
 
-<!--
-    This section is optional but suggested.
+## Related Discussions
 
-    If there is an issue, pull request, or other URL that provides useful
-    context for this proposal, please include those links here.
--->
+None.

From 3c458ecb58ef6fba8f99d6574bb883398527ac3b Mon Sep 17 00:00:00 2001
From: Pete Gonzalez <4673363+octogonz@users.noreply.github.com>
Date: Mon, 4 Nov 2019 22:15:16 -0800
Subject: [PATCH 3/4] Add PR number

---
 designs/2019-workaround-for-issue-3458/README.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/designs/2019-workaround-for-issue-3458/README.md b/designs/2019-workaround-for-issue-3458/README.md
index aeaea06e..a86909fa 100644
--- a/designs/2019-workaround-for-issue-3458/README.md
+++ b/designs/2019-workaround-for-issue-3458/README.md
@@ -1,17 +1,17 @@
 - Start Date: 2019-11-04
-- RFC PR: (leave this empty, to be filled in later)
+- RFC PR: https://github.com/eslint/rfcs/pull/46
 - Authors: Pete Gonzalez ([@octogonz](https://github.com/octogonz))
 
 # 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, this RFC proposes
-a temporary workaround, that allows users opt-in to a resolution behavior that works well in practice (despite having
-some known limitations).  This feature would be designated as experimental, with the intent to remove it when/if
-the ideal solution finally ships.
+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
 

From e45680a16d5fc13792cc3fe4a5a6481bde8f6d41 Mon Sep 17 00:00:00 2001
From: Pete Gonzalez <4673363+octogonz@users.noreply.github.com>
Date: Tue, 5 Nov 2019 16:31:44 -0800
Subject: [PATCH 4/4] Update "Drawbacks" based on discussion

---
 designs/2019-workaround-for-issue-3458/README.md | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/designs/2019-workaround-for-issue-3458/README.md b/designs/2019-workaround-for-issue-3458/README.md
index a86909fa..9270cd80 100644
--- a/designs/2019-workaround-for-issue-3458/README.md
+++ b/designs/2019-workaround-for-issue-3458/README.md
@@ -51,9 +51,11 @@ The PR will include documentation for the new option.
 
 ## Drawbacks
 
-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.
+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
 
@@ -65,7 +67,7 @@ If RFC #14 can be completed and implemented within a reasonable timeframe, then
 
 ## Open Questions
 
-None.
+Since a PR has already been created, please provide feedback on the implementation details.
 
 ## Help Needed
 
@@ -73,9 +75,9 @@ None.
 
 ## Frequently Asked Questions
 
-### In order to modify one line of logic, do we really need to wait an entire month (21 + 7 days) for an "RFC"?
+### 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 insisted on this formalism.
+Yes, the ESLint maintainers have requested this.
 
 ### Why should we accept a solution with known limitations?