diff --git a/accepted/0000-registry-url-in-lock-file.md b/accepted/0000-registry-url-in-lock-file.md deleted file mode 100644 index 3cd21cd..0000000 --- a/accepted/0000-registry-url-in-lock-file.md +++ /dev/null @@ -1,102 +0,0 @@ -- Start Date: 2017-09-21 -- RFC PR: -- Yarn Issue: - -# Summary - -The yarn.lock file includes information about the registry that it was generated against. It would -be nice if there was no registry information associated with the lock file - -# Motivation - -We currently have two internal registries/mirrors. We generate the lock file against one we have in -our development environment. When our code is deployed to our build/testing environment, we -no longer have access to the original registry that was used to generate the lock file. This causes -our download to error as yarn cannot retrieve the packages. - -The expected output is for yarn to recognise the registry URL supplied (via either cli flag or -`.yarnrc` or `.npmrc`) and download from that if the registry used in the lock file is not available. - -The cli flag would be `override-registry`, to which an object can be passed to transform the registry requests. - -The entry in the `.yarnrc` or `.npmrc` would also be `override-registry` - -See "Detailed Design" for values it would receive. - -### Example yarn entries - -**Development Environment yarn.lock** -``` -ansi-regex@^2.0.0: - version "2.1.1" - resolved "https://mydev.registry.com/ansi-regex/-/ansi-regex-2.1.1.tgz#c3b33ab5ee360d86e0e628f0468ae7ef27d654df" - -ansi-styles@^2.2.1: - version "2.2.1" - resolved "https://mydev.registry.com/ansi-styles/-/ansi-styles-2.2.1.tgz#b432dd3358b634cf75e1e4664368240533c1ddbe" -``` - -**Build Environment yarn.lock** -``` -ansi-regex@^2.0.0: - version "2.1.1" - resolved "https://mybuild.registry.com/ansi-regex/-/ansi-regex-2.1.1.tgz#c3b33ab5ee360d86e0e628f0468ae7ef27d654df" - -ansi-styles@^2.2.1: - version "2.2.1" - resolved "https://mybuild.registry.com/ansi-styles/-/ansi-styles-2.2.1.tgz#b432dd3358b634cf75e1e4664368240533c1ddbe" -``` - -# Detailed design - -As a dev that generated their lock file against REGISTRY_A -I would like to pass a cli flag designating REGISTRY_B -And I would like yarn to download my dependencies from REGISTRY_B - -As a dev that generated their lock file against REGISTRY_A -I would like to designate an alternate registry URL in my `.yarnrc` or `.npmrc` (REGISTRY_B) -And I would like yarn to download my dependencies from the alternate URL (REGISTRY_B) - -Based on feedback received, we shouldn't be modifying the yarn.lock file. Developers can provide -an `override-registry` option in either the cli or the `.yarnrc` or `.npmrc` - -Example object would be `{"": ""}` - -**Examples based on above [yarn entries](#example-yarn-entries)** - -``` -// cli -yarn --override-registry={"mydev.registry.com": "mybuild.registry.com"} -``` - -``` -// .npmrc or .yarnrc -override-registry={"mydev.registry.com": "mybuild.registry.com"} -``` - -Using the example above, when this override is provided, the packages would get downloaded from "mybuild.registry.com" - -# How We Teach This - -This would largely be in the internal workings, and wouldn't require teaching. npm 5 does this -already, so it would be inherent. - -> 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. - -http://blog.npmjs.org/post/161081169345/v500 - -# Drawbacks - -I don't see any drawbacks in implementing this feature as it would keep track with npm - -# Alternatives - -Only workaround is to modify the yarn.lock file and replace all references to the registries with -the desired registry. - -It seems that there are already many issues around this, so it seems there is a need. - -# Unresolved questions - -Optional, but suggested for first drafts. What parts of the design are still -TBD? diff --git a/accepted/0000-switching-registries.md b/accepted/0000-switching-registries.md new file mode 100644 index 0000000..3e563e7 --- /dev/null +++ b/accepted/0000-switching-registries.md @@ -0,0 +1,63 @@ +- Start Date: 2017-09-21 +- RFC PR: +- Yarn Issue: + +# Summary + +Yarn should always use the registry configured by the current user, falling back to the default registry otherwise. It should not use the registry specified in the `resolved` field of lockfile. + +# Motivation + +The default registry used by Yarn is `registry.yarnpkg.com`, but the use of alternate registries is possible through configuration or command-line flags. Using an alternate registry can be useful for a number of reasons; it can improve performance, facilitate serving private packages, and improve the reliability of build and test servers. However, many of these use cases are environment specific. These benefits cannot be realized without allowing the use of different registries in different environments. + +* Using a registry mirror that is closer to you can dramatically improve performance. Using a single registry mirror might work well for teams that work in the same office, but teams that span great distances will need to use different registry mirrors to see the same benefit. +* Build environments can benefit from using a dedicated registry. In addition to the performance benefits, it can also protect against outages that might affect the public registries. + +Currently, Yarn will only use the configured registry for newly installed packages. For packages that are listed in the lockfile already, Yarn will use the registry saved in the lockfile instead, ignoring the registry configuration of the current user. This effectively prevents switching registries between environments. + +# Detailed design + +Yarn should adopt the behavior `npm` introduced with `npm@5`, which is to always use the registry configured by the current user. This change was described in [this blog post](http://blog.npmjs.org/post/161081169345/v500): +>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. + +Yarn already supports switching to a different registry and scoped registries. The change would be to use them in all cases rather than just for new packages. + +### 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. + +### How do scoped registries work? + +Yarn supports configuring a registry for a specific scope (e.g. `yarn config set '@foo:registry' 'https://registry.foo.com'`). If a scoped registry has been configured, then this registry shall be used for **all** packages under that scope. Using different registries within a single scope is not supported. + +### Can I configure a specific non-scoped package use an alternate registry? + +No, non-scoped packages would all use the same registry. This restriction simplifies the configuration, and keeps us in line with `npm`. + +### Should the `resolved` field be used as a fallback? + +No, the user's configured registry should be used at all times. Falling back to `resolved` could hide problems (i.e. outdated or misconfigured mirrors) and negatively affect performance. It could also leak information to third parties about which packages are being used, which might be undesirable in certain environments. + +# How We Teach This + +We should improve the documentation for configuring Yarn, with a focus on the registry and scoped registry configuration. This change should also be featured prominently and explained in the release notes, and any blog post or announcement accompanying the version this ships in. This is a significant change, but it does bring it more in line with the behavior of `npm`, which many people are familiar with. + +Overall, the behavior of Yarn should be easier to understand after this change. The behavior will be more transparent and controllable by the user. + +# Drawbacks + +1. This would be a breaking change. +2. Alternate registries for non-scoped packages (or within scopes) would be impossible +While this was never supported officially, it was possible to do by directly editing the `yarn.lock` file. With this change, that would no longer be possible. + +# Alternatives + +1. Add additional configuration for overriding registries +We could preserve the existing behavior, but add additional configuration for overriding the registry. This `override-registry` would behave like `registry` configuration does in the main proposal. This would allow users to opt-in to the new behavior without making a breaking change. +While this would solve the problem, it would also make the configuration more confusing and difficult to teach. +2. Use the `registry` configuration only as a fallback to the `resolved` field +This could allow the install to succeed in cases where the `resolved` field has a registry that is inaccessible to the current user. However it would do nothing to address the use case where an alternate registry is used for performance reasons. + +# Unresolved questions + +* What is the performance impact of not using the cached tarball URL (`resolved`)?