Remove hostnames from the lockfiles

We want to remove hostnames from the lockfiles:

wrappy@1:
  version "1.0.2"
  resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"

Would become:

wrappy@1:
  version "1.0.2"
  resolved "/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"

This will allow us to switch the default registry more easily if we need to (for example if we want to deprecate our mirror, or if npm suddenly disappear from the surface of the earth), and will also make it easier for the users to switch from a registry to another.

Author: Fantashit

7 thoughts on “Remove hostnames from the lockfiles

  1. What about custom registries/repositories? If a project has a mix of different registries (eg. some from regular public npm, some from a private internal server), how would it know which is which? Particularly since there could be overlap in package names.

  2. @Daniel15 I think in this case it is recommended to keep the packages coming from a private internal server behind a specific scope, so that you can use scope-specific registry urls.

  3. Adding a datapoint here for @arcanis.

    At least for VSTS/TFS, this pattern seems to work.

    My yarn.lock matches the pattern for upstream packages:

    typescript@~2.8.3:
      version "2.8.3"
      resolved "<INTERNAL_REGISTRY>/typescript/-/typescript-2.8.3.tgz#5d817f9b6f31bb871835f4edf0089f21abe6c170"
    

    Be sure to keep scoped packages in mind – there is an extra segment:

    "@types/estree@0.0.38":
      version "0.0.38"
      resolved "<INTERNAL_REGISTRY>/@types/estree/-/estree-0.0.38.tgz#c1be40aa933723c608820a99a373a16d215a1ca2"
    
  4. Unfortunately we discovered that some registries follow entirely different rules (a surprising one being … NPM Enterprise …), so we won’t be able to just trim the hostname 😞

    Maybe we’ll end up having a whitelist of domain names that can work this way … but it’s annoying.

  5. Currently, it’s something similar to this (cf pnpm/pnpm#867):

    https://npm-registry.compass.com/p/pnpm/_attachments/pnpm-1.9.0.tgz
    

    No idea why they chose to break their convention.

  6. What about a compromise to this?

    Allowing for the --registry CLI argument when running both the yarn and yarn add command might be a helpful compromise to resolve this issue.

    e.g.,

    yarn --registry=http://registry.npm.taobao.org

    This would allow the user to specify the registry to be used during the installation.

    Another might be to trim the hostname if it matches the standard path structure, and leave it in if the URL differs. This would prevent the need for a whitelist, and instead only a simple regexp or simple parser, but allow for using the registry in the user’s configuration as necessary for conforming registries.

    The interim solution will be to use sed to point to a different registry during our CI builds, but this is obviously not a desired solution.

    sed -i 's#http://private-registry/repository/npm#https://registry.yarnpkg.com#' yarn.lock

    (from @victornoel in #2566 )

    (cc @arcanis @BYK @doxiaodong @victornoel )

  7. I (Redhat productization team) recently created a new npm library called lock-treatment-tool https://www.npmjs.com/package/lock-treatment-tool in order to treat lock files before initialising or installing the npm project. It will treat either package-lock.json/yarn.lock files, remove/replace the registries and integrity hash and then you can use your own registries.
    I hope this helps you.

Comments are closed.