Skip to content

Commit 0461f38

Browse files
vernak2539bestander
authored andcommitted
add rfc about registry url in lock file (#84)
* add rfc about registry url in lock file * Update 0000-registry-url-in-lock-file.md * update registry url in lock file 'detailed design' * update download from different registry rfc
1 parent d0660f7 commit 0461f38

File tree

1 file changed

+102
-0
lines changed

1 file changed

+102
-0
lines changed
Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
- Start Date: 2017-09-21
2+
- RFC PR:
3+
- Yarn Issue:
4+
5+
# Summary
6+
7+
The yarn.lock file includes information about the registry that it was generated against. It would
8+
be nice if there was no registry information associated with the lock file
9+
10+
# Motivation
11+
12+
We currently have two internal registries/mirrors. We generate the lock file against one we have in
13+
our development environment. When our code is deployed to our build/testing environment, we
14+
no longer have access to the original registry that was used to generate the lock file. This causes
15+
our download to error as yarn cannot retrieve the packages.
16+
17+
The expected output is for yarn to recognise the registry URL supplied (via either cli flag or
18+
`.yarnrc` or `.npmrc`) and download from that if the registry used in the lock file is not available.
19+
20+
The cli flag would be `override-registry`, to which an object can be passed to transform the registry requests.
21+
22+
The entry in the `.yarnrc` or `.npmrc` would also be `override-registry`
23+
24+
See "Detailed Design" for values it would receive.
25+
26+
### Example yarn entries
27+
28+
**Development Environment yarn.lock**
29+
```
30+
ansi-regex@^2.0.0:
31+
version "2.1.1"
32+
resolved "https://mydev.registry.com/ansi-regex/-/ansi-regex-2.1.1.tgz#c3b33ab5ee360d86e0e628f0468ae7ef27d654df"
33+
34+
ansi-styles@^2.2.1:
35+
version "2.2.1"
36+
resolved "https://mydev.registry.com/ansi-styles/-/ansi-styles-2.2.1.tgz#b432dd3358b634cf75e1e4664368240533c1ddbe"
37+
```
38+
39+
**Build Environment yarn.lock**
40+
```
41+
ansi-regex@^2.0.0:
42+
version "2.1.1"
43+
resolved "https://mybuild.registry.com/ansi-regex/-/ansi-regex-2.1.1.tgz#c3b33ab5ee360d86e0e628f0468ae7ef27d654df"
44+
45+
ansi-styles@^2.2.1:
46+
version "2.2.1"
47+
resolved "https://mybuild.registry.com/ansi-styles/-/ansi-styles-2.2.1.tgz#b432dd3358b634cf75e1e4664368240533c1ddbe"
48+
```
49+
50+
# Detailed design
51+
52+
As a dev that generated their lock file against REGISTRY_A
53+
I would like to pass a cli flag designating REGISTRY_B
54+
And I would like yarn to download my dependencies from REGISTRY_B
55+
56+
As a dev that generated their lock file against REGISTRY_A
57+
I would like to designate an alternate registry URL in my `.yarnrc` or `.npmrc` (REGISTRY_B)
58+
And I would like yarn to download my dependencies from the alternate URL (REGISTRY_B)
59+
60+
Based on feedback received, we shouldn't be modifying the yarn.lock file. Developers can provide
61+
an `override-registry` option in either the cli or the `.yarnrc` or `.npmrc`
62+
63+
Example object would be `{"<generated-registry-entry>": "<registry-to-request-from>"}`
64+
65+
**Examples based on above [yarn entries](#example-yarn-entries)**
66+
67+
```
68+
// cli
69+
yarn --override-registry={"mydev.registry.com": "mybuild.registry.com"}
70+
```
71+
72+
```
73+
// .npmrc or .yarnrc
74+
override-registry={"mydev.registry.com": "mybuild.registry.com"}
75+
```
76+
77+
Using the example above, when this override is provided, the packages would get downloaded from "mybuild.registry.com"
78+
79+
# How We Teach This
80+
81+
This would largely be in the internal workings, and wouldn't require teaching. npm 5 does this
82+
already, so it would be inherent.
83+
84+
> If you generated your package lock against registry A, and you switch to registry B, npm will now try to install the packages from registry B, instead of A. If you want to use different registries for different packages, use scope-specific registries (npm config set @myscope:registry=https://myownregist.ry/packages/). Different registries for different unscoped packages are not supported anymore.
85+
86+
http://blog.npmjs.org/post/161081169345/v500
87+
88+
# Drawbacks
89+
90+
I don't see any drawbacks in implementing this feature as it would keep track with npm
91+
92+
# Alternatives
93+
94+
Only workaround is to modify the yarn.lock file and replace all references to the registries with
95+
the desired registry.
96+
97+
It seems that there are already many issues around this, so it seems there is a need.
98+
99+
# Unresolved questions
100+
101+
Optional, but suggested for first drafts. What parts of the design are still
102+
TBD?

0 commit comments

Comments
 (0)