Moves files around (#56)

arcanis · bestander · commit 58a403f90302 · 2017-04-20T19:20:36.000-07:00
diff --git a/accepted/.keep b/accepted/.keep
diff --git a/accepted/0000-idempotent-install.md b/accepted/0000-idempotent-install.md
@@ -1,20 +1,20 @@
 - Start Date: 2016-12-13
-- RFC PR: (leave this empty)
-- Yarn Issue: (leave this empty)
-
-# Summary
+- RFC PR: https://github.com/yarnpkg/rfcs/pull/37
+- Yarn Issue: https://github.com/yarnpkg/yarn/issues/2241
+
+# Summary
 
 `yarn install` should be idempotent.
 
-Ideally, the result of `yarn install` would not be statefully dependent on the contents of an existing `node_modules`, and would ensure the resulting `node_modules` is identical regardless of whether there is an existing `node_modules` or not. This seems very inline with the spirit of yarn's goal of deterministic builds (same `node_modules` independent of whether `node_modules` exists or the version of node that generated it).
-
-# Motivation
-
+Ideally, the result of `yarn install` would not be statefully dependent on the contents of an existing `node_modules`, and would ensure the resulting `node_modules` is identical regardless of whether there is an existing `node_modules` or not. This seems very inline with the spirit of yarn's goal of deterministic builds (same `node_modules` independent of whether `node_modules` exists or the version of node that generated it).
+
+# Motivation
+
 Presently, a major headache with `npm` / binary `node_modules` (e.g., `heapdump`) is the need to manually run `npm rebuild` when upgrading node. Communicating this preemptively to developers prior to an upgrade is logistically very manual, leading to "Why is this broken for me?" when errors are not obvious (e.g., `Error: Cannot find module '../build/Debug/addon'`).
 
-Since `yarn install` is near instant when dependencies are unchanged, having developers run `yarn install` after a `git pull` is no big deal. However, having developers regularly run `yarn install --force` with many dependencies is a non-starter (1s vs 100s).
-
-# Detailed design
+Since `yarn install` is near instant when dependencies are unchanged, having developers run `yarn install` after a `git pull` is no big deal. However, having developers regularly run `yarn install --force` with many dependencies is a non-starter (1s vs 100s).
+
+# Detailed design
 
 Assuming both a `package.json` and `yarn.lock` in the project's root...
 
@@ -27,27 +27,27 @@ Assuming both a `package.json` and `yarn.lock` in the project's root...
 **Path B: (`node_modules` installed w/ node@X, node@Y)**
 
 - **Current, non-ideal**: `yarn install` => binaries for node@X
-- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**Ideal**: `yarn install` => binaries for **node@Y**
-
-
-# How We Teach This
-
+- **Ideal**: `yarn install` => binaries for **node@Y**
+
+
+# How We Teach This
+
 *What names and terminology work best for these concepts and why?*
 
  "`node_modules`" for node context, "rebuild" & "build" for npm legacy; "idempotent" for technical accuracy; "install" & "force" for yarn context (i.e., `yarn install`).
 
 *How is this idea best presented?*
 
 As a continuation of existing Yarn patterns: "deterministic builds".
-
+
 *Would the acceptance of this proposal mean the Yarn documentation must be re-organized or altered?*
 
 No.
 
 *Does it change how Yarn is taught to new users at any level?*
 
-Yes. This will all but eliminate the need to explain why rebuilds are needed after an upgrade.
-
+Yes. This will all but eliminate the need to explain why rebuilds are needed after an upgrade.
+
 *How should this feature be introduced and taught to existing Yarn users?*
 
 By assuring users:
@@ -58,11 +58,11 @@ No need to caveat ^ this with:
 
 > Unless you upgraded node, then you need rebuild your binary modules with `yarn install --force`,
 but don't worry about it reinstalling all your modules, even the non-binary ones.
-
-# Drawbacks
-
-Complexity of detection / knowing when to rebuild.
-
-# Alternatives
-
+
+# Drawbacks
+
+Complexity of detection / knowing when to rebuild.
+
+# Alternatives
+
 Use a flag: `yarn install --check-rebuild` and/or support it in `.yarnrc` (`install-check-rebuild true`)
diff --git a/accepted/0000-license-check.md b/accepted/0000-license-check.md
@@ -1,6 +1,6 @@
 - Start Date: 2016-10-12
-- RFC PR: (leave this empty)
-- Yarn Issue: (leave this empty)
+- RFC PR: https://github.com/yarnpkg/rfcs/pull/7
+- Yarn Issue: https://github.com/yarnpkg/yarn/issues/904
 
 # Summary
 
diff --git a/accepted/0000-publish-config.md b/accepted/0000-publish-config.md
@@ -1,6 +1,5 @@
 - Start Date: (1-10-17)
-- RFC PR: (leave this empty)
-- Yarn Issue: (leave this empty)
+- RFC PR: https://github.com/yarnpkg/rfcs/pull/40
 
 # Summary
 
@@ -40,14 +39,14 @@ as well.
 # Drawbacks
 
 As with any new code, it's new code. Adding it expands the amount of functionality
-that yarn now supports. That's the largest drawback I can think of. 
+that yarn now supports. That's the largest drawback I can think of.
 
 # Alternatives
 
 I considered a --registry flag for the yarn publish command. This would likely accomplish the
-same functionality but is prone to error as most hand typed things are. 
+same functionality but is prone to error as most hand typed things are.
 
 # Unresolved questions
 
 I'm a relative newbie to yarn, so my design might be too simplistic or not accounting
-for things I just don't know about. 
+for things I just don't know about.
diff --git a/accepted/0000-show-updated-packages-only.md b/accepted/0000-show-updated-packages-only.md
diff --git a/accepted/0000-yarn-knit.md b/accepted/0000-yarn-knit.md
@@ -1,6 +1,6 @@
 - Start Date: 2017-01-13
-- RFC PR: (leave this empty)
-- Yarn Issue: (leave this empty)
+- RFC PR: https://github.com/yarnpkg/rfcs/pull/41
+- Yarn Issue: https://github.com/yarnpkg/yarn/issues/1213
 
 # Summary
 
diff --git a/implemented/0000-offline-mirror-pruning.md b/implemented/0000-offline-mirror-pruning.md
@@ -1,6 +1,7 @@
 - Start Date: 2017-02-11
-- RFC PR: (leave this empty)
-- Yarn Issue: (leave this empty)
+- RFC PR: https://github.com/yarnpkg/rfcs/pull/49
+- Yarn Issue: https://github.com/yarnpkg/yarn/issues/2109
+- Implementation: https://github.com/yarnpkg/yarn/pull/2836
 
 # Summary
 
diff --git a/implemented/0000-offline-resolution-field.md b/implemented/0000-offline-resolution-field.md
@@ -1,6 +1,6 @@
-- Start Date: (fill me in with today's date, YYYY-MM-DD)
-- RFC PR: (leave this empty)
-- Yarn Issue: (leave this empty)
+- Start Date: 28 Feb 2017
+- RFC PR: https://github.com/yarnpkg/rfcs/pull/51
+- Implementation: https://github.com/yarnpkg/yarn/pull/2970
 
 # Summary
 
@@ -15,7 +15,7 @@ Tentative implementation: https://github.com/yarnpkg/yarn/pull/2970/
 Yarn currently has two different type of values for the lockfile `resolved` fields:
 
   - When online, they're in the form `${source}/${name}-${version}.tar.gz#${hash}`
-  
+
   - But when offline, they're instead `${name}-${version}.tar.gz#${hash}`
 
 The current reasoning (or at least side effect) seems to be that it allows the fetch process to refuse installing things from the network when running under the `--offline` switch (and to always fetch things from the network otherwise instead of looking into the offline mirror). Unfortunately, such a separation also makes it harder to switch between working with a remote registry and an offline repository (for example, dev environments might not need the offline repository, but under the current design they can't do without).
