yarn.lock should not include base registry(`http://registry.npmjs.org`)
Do you want to request a feature or report a bug?
feature
What is the current behavior?
yarn.lock include registry
If the current behavior is a bug, please provide the steps to reproduce.
What is the expected behavior?
[email protected]:
version "4.17.4"
resolved "http://registry.npm.taobao.org/lodash/download/lodash-4.17.4.tgz#78203a4d1c328ae1d86dca6460e369b57f4055ae"
should be
...
resolved "/lodash/download/lodash-4.17.4.tgz#78203a4d1c328ae1d86dca6460e369b57f4055ae"
...
Reason
Most developers in china will use --registry=https://registry.npm.taobao.org
, and then, yarn.lock will be
...
resolved "http://registry.npm.taobao.org/lodash/download/lodash-4.17.4.tgz#78203a4d1c328ae1d86dca6460e369b57f4055ae"
...
But for travis-ci, circleci, it seem to be slowly.
So, I think the regiistry should not be in yarn.lock
doxiaodong
All 29 comments
Yeah, that sounds like a useful feature.
@arcanis what do you think?
bestander
on 5 May 2017
Yup, completely agree. Ideally, I think the resolved field should be removed (because we don't care where the tarball come from, as long as it has the right hash), and replaced by a single hash field. The url can then be reconstructed at runtime when reading the lockfile.
arcanis
on 5 May 2017
@doxiaodong want to send an RFC?
We'll need to discuss backwards compatibility, this feature being an opt-in, defaults etc
bestander
on 5 May 2017
@bestander ， any template here? I don't know what and how to do that.
doxiaodong
on 7 May 2017
Sure, here are a couple of good examples https://github.com/yarnpkg/rfcs/pull/40/files https://github.com/yarnpkg/rfcs/pull/34/files
bestander
on 8 May 2017
I have sent a pr https://github.com/yarnpkg/rfcs/pull/64
doxiaodong
on 9 May 2017
+1 for this. In our case (which I think is shared by many) we have one registry in our local dev environment, and another in our CI environment. Currently, tracking the lock file with git causes it to contain references to the dev registry which in turn leads to builds in CI failing. The only solution we have found so far is to not track the lock file at all, which incurs a performance hit during builds.
csvan
on 9 Jun 2017
+1 for this. We use a local registry and would like it to ignore the one in the yarn.lock in favor of our local.
ckannon
on 22 Aug 2017
+1 for this. In our situation we are using jenkins and sinopia in a kubernetes environment. In the kubernetes network sinopia has a different url to the external network url. It would be handy if we could switch between the 2 easily as it might be faster to use the internal kubernetes network url, while allowing developers to use the external registry url as they wont have access to the internal url
el-davo
on 28 Aug 2017
This would be nice to have. We have a mirror used outside our Build Environment that has one URL. Inside the Build Environment it has a different URL, and the original registry used to generate the lock file is not available.
We've noticed that passing the --registry flag doesn't overwrite from where the packages are fetched. Would be nice to have the lock file be registry agnostic
vernak2539
on 7 Sep 2017
Suggest a simple backwards compatible RFC and send a PR, we'll get it sorted then.
Discussion in https://github.com/yarnpkg/rfcs/pull/64 got derailed and suggests bigger changes than the team is eager to take.
bestander
on 7 Sep 2017
@bestander I wrote one here. Not sure if it's enough, but it's a start
vernak2539
on 26 Sep 2017
I would say remove concepts of urls/paths all together, and only list the name, version and hash.
It's easy to rebuild the url at download time instead, and opens potential for alternate url formats too.
aikar
on 2 Nov 2017
@bestander when you say backwards compat RFC, do you mean newer yarn can still load older yarnrc, or that older yarns should still be able to load the newer yarnrc?
aikar
on 2 Nov 2017
@aikar, conceptually I agree.
Although a major change in yarn.lock would need a detailed RFC with consideration of how breaking the change will be.
When I talk about backwards compatibility I mean that yarn.lock generated by a previous version of Yarn won't be compatible by the next version that strips the URLs and vice versa.
We'll need to think through how teams with people using multiple versions of Yarn can work.
It is doable but requires a responsible approach.
So far I am fine to settle on a minimal change to unblock people using npm mirrors.
bestander
on 2 Nov 2017
Met this question today ToT
Maxxxz
on 28 Nov 2017
This has sadly become a blocker for us. Npm works correctly using an integrity field in its lock file (in addition to a resolved field similar to yarn). Here's a solution that also preserves yarn backcompat: Introduce a _new_ field called hash that's a sibling of resolved. Latest yarn would add this field wherever it's missing for each package entry in the lock file, when yarn install is run. When resolving a package, if hash is missing in any entry in the lock file, yarn falls back to the resolved field, which will keep backcompat with old lock files. Thoughts?
ashwinr
on 5 Dec 2017
Here is the RFC we have agreed on, it should solve the title issue and is waiting for a champion to implement it: https://github.com/yarnpkg/rfcs/pull/84/files.
It is quite easy to implement it so please go ahead and send a PR.
As for talks about integrity fields we have one here: https://github.com/yarnpkg/yarn/issues/816
bestander
on 7 Dec 2017
I hope this can be done soon. This is really annoying.
crazyyi
on 13 Feb 2018
Has there been any progress on this? Not being able to utilize a proxy or mirror without circumventing the source controlled yarn.lock is really frustrating. Especially when issues like this contribute:
https://status.npmjs.org/incidents/vrg1s7lbg887
An issue with all logged-out site users being put into the same rate-limiting bucket has been fixed.
https://status.npmjs.org/incidents/rmv88ktdgkkr
Some users are reporting timeouts on their package installations. We're currently investigating this.
LinkMJB
on 17 May 2018
This is absolutely needed
terion-name
on 22 May 2018
Here's a quick workaround I slapped together to circumvent this behavior until a REAL patch is implemented. You should be able to execute this as a pre-step in CI jobs to update every instance of yarn.lock to use what was established as the registry in the .yarnrc:
find . -name yarn.lock -exec sed -i "s#https://registry.yarnpkg.com#`awk '$1 == "registry" { gsub(/"/,""); print $NF}' /root/.yarnrc`#g" {} \;
Wow, that was impeccable timing 🤣
LinkMJB
on 26 May 2018
Opened a new issue at #5892 to put this feature request inside the v2 high level goals 🙂
arcanis
on 26 May 2018
@arcanis shall we close this one in favor of #5892?
BYK
on 26 May 2018
So this feature still under development?
It is really important for deploy in production environment when company has own internal registry.
lcw0622
on 6 Dec 2018
Deploying website to now.sh always fail, and I can not even use YARN_REGISTRY="https://registry.yarnpkg.com" to override yarn.lock!
linonetwo
on 24 Jan 2019
you are right
coppyC
on 7 Mar 2019
Closing this issue; we already have #5892.
This will be part of the v2, but probably not the v1.
arcanis
on 7 Mar 2019
Related issues
sanex3339
·
3Comments
AzGoalie
·
3Comments
chiedo
·
3Comments
sebmck
·
3Comments
danez
·
3Comments
Most helpful comment
I hope this can be done soon. This is really annoying.