diff --git a/text/.keep b/accepted/.keep similarity index 100% rename from text/.keep rename to accepted/.keep diff --git a/text/0000-idempotent-install.md b/accepted/0000-idempotent-install.md similarity index 90% rename from text/0000-idempotent-install.md rename to accepted/0000-idempotent-install.md index e4f538b..47e11a0 100644 --- a/text/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,11 +27,11 @@ 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 --                         **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`). @@ -39,15 +39,15 @@ Assuming both a `package.json` and `yarn.lock` in the project's root... *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/text/0000-license-check.md b/accepted/0000-license-check.md similarity index 96% rename from text/0000-license-check.md rename to accepted/0000-license-check.md index 6504078..a6ec2ad 100644 --- a/text/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/text/0000-publish-config.md b/accepted/0000-publish-config.md similarity index 92% rename from text/0000-publish-config.md rename to accepted/0000-publish-config.md index 5425074..e9ec824 100644 --- a/text/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/0000-show-updated-packages-only.md b/accepted/0000-show-updated-packages-only.md similarity index 100% rename from 0000-show-updated-packages-only.md rename to accepted/0000-show-updated-packages-only.md diff --git a/text/0000-yarn-knit.md b/accepted/0000-yarn-knit.md similarity index 97% rename from text/0000-yarn-knit.md rename to accepted/0000-yarn-knit.md index 5919a28..3d77cef 100644 --- a/text/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/text/0000-offline-mirror-pruning.md b/implemented/0000-offline-mirror-pruning.md similarity index 92% rename from text/0000-offline-mirror-pruning.md rename to implemented/0000-offline-mirror-pruning.md index 44973fe..e08959b 100644 --- a/text/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/text/0000-offline-resolution-field.md b/implemented/0000-offline-resolution-field.md similarity index 93% rename from text/0000-offline-resolution-field.md rename to implemented/0000-offline-resolution-field.md index 629fd17..010dda5 100644 --- a/text/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).