Rewrite the registry-url-in-lock-file RFC
#99
Conversation
The `registry-url-in-lock-file` RFC was a proposal for allowing users to more easily switch between registries. The current problem with switching registries is that Yarn tries to use the cached tarball URL in the `resolved` field of the lockfile instead of the current registry when installing. The original proposal was to remove the registry from the lockfile. This would force Yarn to use the current registry. Later in the discussion it was also proposed to follow the behavior of `npm@5` and just ignore the `resolved` field. Both of these solutions seemed to have the support of everyone involved in the discussion, but the concern of this being a breaking change was raised. So instead, a third proposal for an additional configuration field was what ended up being merged. Circumstances have changed, and a major version bump is likely in the near future. Given that we can now make a breaking change, I am proposing that we rewrite this RFC to more closely match its original intention. This rewrite proposes that we solve the problem by adopting the same behavior as `npm@5`. I have also updated the title of the RFC to better match the proposal.
Gudahtt
force-pushed
the
update-registry-lockfile-RFC
branch
from
114089d
to
dfa7d49
Compare
|
|
||
| # Motivation | ||
|
|
||
| We currently have two internal registries/mirrors. We generate the lock file against one we have in |
There was a problem hiding this comment.
I did make an attempt at including this use case, but I didn't understand it well enough to explain it.
The use cases I did include should suffice hopefully. But if someone would like to attempt incorporating this use case again, edits are welcome.
There was a problem hiding this comment.
I think this use case is largely solved by one of those two options:
- Users could simply have a CI build step where they copy
.yarnrc.ciinto.yarnrc, or - Users could call Yarn with the
--use-yarnrc .yarnrc.ciflag
This would let them define the registries they want to use on CI without too much hassle.
Gudahtt
changed the title
registry-url-in-lock-file RFCregistry-url-in-lock-file RFC
Gudahtt
changed the title
registry-url-in-lock-file RFCregistry-url-in-lock-file RFC
|
|
||
| ### Can non-scoped packages use alternate registries? | ||
|
|
||
| No, non-scoped packages would all use the same registry. This restriction simplifies the configuration, and keeps us in line with `npm`. |
There was a problem hiding this comment.
Well, they can use alternate registries, but on a "all or nothing basis". The technical answer is "yes" but your explanation is good 😛
There was a problem hiding this comment.
Ah... right 😛 I shall edit this to make that more clear.
|
|
||
| ### What about the `resolved` field in the lockfile? | ||
|
|
||
| The `resolved` field will not be used to determine which registry is used. Changes to to the `resolved` field, such as removing the registry, are outside the scope of this RFC. |
There was a problem hiding this comment.
Not that much - do you see a drawback removing it from the lockfile? Leaving it there seems confusing, since the lockfile would then contain "useless" data.
There was a problem hiding this comment.
I elaborated on this in a comment on the other PR.
But even if we do remove it, it had been my intention to submit a separate RFC for that step. They are definitely related, but the proposal in this RFC doesn't depend on changing the lockfile format. Because of that, I thought it might be helpful to separate the two ideas. Also it seemed like @bestander was asking for the original proposal to be split back in 2017, so I thought he might prefer it this way 😛 .
I am open to adding that to this RFC though, if that is preferred.
There was a problem hiding this comment.
@Gudahtt thank you for driving this work forward.
This RFC will help our organization work around the consequences of hard-coded registry URLs in the lock file.
|
|
||
| # Motivation | ||
|
|
||
| We currently have two internal registries/mirrors. We generate the lock file against one we have in |
There was a problem hiding this comment.
I think this use case is largely solved by one of those two options:
- Users could simply have a CI build step where they copy
.yarnrc.ciinto.yarnrc, or - Users could call Yarn with the
--use-yarnrc .yarnrc.ciflag
This would let them define the registries they want to use on CI without too much hassle.
|
@Gudahtt PR coming? ;) |
|
Sure! I'll start work on it this weekend. |
The
registry-url-in-lock-fileRFC was a proposal for allowing users to more easily switch between registries. The current problem with switching registries is that Yarn tries to use the cached tarball URL in theresolvedfield of the lockfile instead of the current registry when installing.The original proposal was to remove the registry from the lockfile. This would force Yarn to use the current registry. Later in the discussion it was also proposed to follow the behavior of
npm@5and just ignore theresolvedfield.Both of these solutions seemed to have the support of everyone involved in the discussion, but the concern of this being a breaking change was raised. So instead, a third proposal for an additional configuration field was what ended up being merged.
Circumstances have changed, and a major version bump is likely in the near future. Given that we can now make a breaking change, I am proposing that we rewrite this RFC to more closely match its original intention. This rewrite proposes that we solve the problem by adopting the same behavior as
npm@5.I have also updated the title of the RFC to better describe the proposal.