Skip to content

Commit

Permalink
Moves files around (#56)
Browse files Browse the repository at this point in the history
  • Loading branch information
arcanis authored and bestander committed Apr 21, 2017
1 parent 44f84bb commit 58a403f
Show file tree
Hide file tree
Showing 8 changed files with 41 additions and 41 deletions.
File renamed without changes.
Original file line number Diff line number Diff line change
@@ -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...

Expand All @@ -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
-                         **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:
Expand All @@ -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`)
4 changes: 2 additions & 2 deletions text/0000-license-check.md → accepted/0000-license-check.md
Original file line number Diff line number Diff line change
@@ -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

Expand Down
Original file line number Diff line number Diff line change
@@ -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

Expand Down Expand Up @@ -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.
File renamed without changes.
4 changes: 2 additions & 2 deletions text/0000-yarn-knit.md → accepted/0000-yarn-knit.md
Original file line number Diff line number Diff line change
@@ -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

Expand Down
Original file line number Diff line number Diff line change
@@ -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

Expand Down
Original file line number Diff line number Diff line change
@@ -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

Expand All @@ -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).
Expand Down

0 comments on commit 58a403f

Please sign in to comment.