<figcaption>Snippet of some random lock file</figcaption>
**Lockfiles** on node package manager (npm) clients are not a new topic, yarn broke the node package managers world with a term called [**determinism**](https://yarnpkg.com/blog/2017/05/31/determinism/) providing a new file generated after install called yarn.lock to pin and freeze dependencies with the objective to avoid inconstancies across multiple installations.
If you are using a private registry as [Verdaccio](https://verdaccio.org/), it might be a concern committing the lock file in the repo using the private or local domain as registry URL and then someone else due his environment is not able to fetch the tarballs defined in the lock file.
This is merely an issue that all package managers have to resolve, nowadays is not hard to see companies using their own registry to host private packages or using the **Verdaccio** the power feature [uplinks](https://verdaccio.org/docs/en/uplinks) to resolve dependencies from more than one registry using one single endpoint.
The snippet above is just a small part of this huge file which nobody dares to deal when conflicts arise. However, I just want you to focus on a field called **resolved**.
Let’s imagine you are using **Verdaccio** and **yarn** for local purposes and your registry configuration points to.
```
yarn config set registry http://localhost:4873/
```
After running an installation, yarn install, a lock file is generated and each dependency will have a field called resolved that points exactly the URI where tarball should be downloaded in a future install. That meaning the package manager will rely on such URI no matter what.
_In the case of pnpm the lock file looks a bit different, we will see that in detail later on this article._
Let’s imagine you that might want to change your domain where your registry is hosted and the resolved field still points to the previous location and your package manager won’t be able to resolve the project dependencies anymore.
**A usual solution is to delete the whole lock file and generate a new one** , but, this is not practical for large teams since will drive you to conflicts between branch hard to solve.
So, _How can I use a private registry avoiding the__resolved field issue?_. All clients handle this issue in a different way, let’s see how they do it.
npm uses a JSON as a format for the lock file. The good news is since **npm@5.0.0** [ignores the resolved field](http://blog.npmjs.org/post/161081169345/v500) on package-lock.json file and basically fallback to the one defined in the .npmrc or via --registry argument using the CLI in case is exist, otherwise, it will use the defined in the resolved field.
Nowadays you can use the npm cli with lock file safely with Verdaccio independently the URL where tarball was served. But, I’d recommend to share a local .npmrc file with the registry set by default locally or notify your team about it.
If you are using Yarn the story is a bit different. Until the version 1.9.4, it tries to resolve what lock file defines as a first option.
There are some references on PR, RFCs or tickets opened were they discuss how to address this problem properly and if you are willing to dive into this topic allow me to share the most interesting threads you might follow:
- Replace resolved field by hash [https://github.com/yarnpkg/rfcs/pull/64#issuecomment-414649518](https://github.com/yarnpkg/rfcs/pull/64#issuecomment-414649518)
- yarn.lock should not include base domain registry [https://github.com/yarnpkg/yarn/issues/3330](https://github.com/yarnpkg/yarn/issues/3330)
- Remove hostname from the lock files [https://github.com/yarnpkg/yarn/issues/5892](https://github.com/yarnpkg/yarn/issues/5892)
> TDLR; Yarn 2.0 [has planned to solve this issue](https://github.com/yarnpkg/yarn/projects/4#card-10080906) in the next major version, to this day sill [discussing what approach to take](https://github.com/yarnpkg/rfcs/pull/64#issuecomment-414163196).
[**pnpm**](https://pnpm.js.org/) follows the same approach as other package managers generating a lock file but, in this case, the file is being called shrinkwrap.yaml that is based in **yaml format.**
The example above is just a small snippet of how this long file looks like and you might observe that there is a field called [registry](https://github.com/pnpm/spec/blob/master/shrinkwrap/3.8.md#registry) added at the bottom of the lock file which [was introduced to reduce the file size of the lock file](https://github.com/pnpm/pnpm/issues/1072), in some scenarios pnpm decides to set [the domain is part of the tarball field](https://github.com/josephschmitt/pnpm-406-npmE).
**pnpm** will try to fetch dependencies using the registry defined within the lockfile as yarn **does**. However, as a workaround, if the domain changes you must update the registry field manually, it’s not hard to do but, is better than nothing.
pnpm has already opened a ticket to drive this issue, I’ll let below the link to it.
[Remove the "registry" field from "shrinkwrap.yaml" · Issue #1353 · pnpm/pnpm](https://github.com/pnpm/pnpm/issues/1353)
> It does exist any support for at the time of this writing.
In my opinion, this is just a workaround, which depends on the number or scopes you handle to decide whether or not worth it. Furthermore, the package manager will bypass those packages that do not match with the scope and won’t be resolved by your private registry.
**package managers** are working to solve this issues with backward compatibility and with good performance.
For now, the best solution if you share this concern is **using npm until the other clients decide what to do** or **following the recommendations above for each client**.
