yarn.lock should not include base registry(`http://registry.npmjs.org`)

[doxiaodong]

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?

lodash@4.17.4:
  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

[bestander]

Yeah, that sounds like a useful feature.
@arcanis what do you think?

[arcanis]

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.

[bestander]

@doxiaodong want to send an RFC?

We'll need to discuss backwards compatibility, this feature being an opt-in, defaults etc

[doxiaodong]

@bestander ， any template here? I don't know what and how to do that.

[bestander]

Sure, here are a couple of good examples https://github.com/yarnpkg/rfcs/pull/40/files https://github.com/yarnpkg/rfcs/pull/34/files

[doxiaodong]

I have sent a pr yarnpkg/rfcs#64

[csvan]

+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.

[yardik]

+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.