Menu
We use Yarn to install dependencies. The yarn-lock file is in the repo. If Compared to composer for php, I would expect that when I run yarn install, that the dependencies are installed based on the lock-file, and the lock file does not change.
With composer install for php, you install always the same version for each package on any environment. I don't see why yarn does not work in a similar way.
I think that with yarn install the lock gets updated too often and the file loses its point since it actually does not lock versions. Or am I using the wrong commands?
985
To install dependencies, you have to run yarn install in the root of your directory to install all the dependencies for a project. The dependencies will be retrieved from the package. json file you pushed to version control, and will be stored in the yarn. lock file.
Run yarn install , or just yarn . The lock file is updated in its entirety on any change to dependencies, i.e. when you run a yarn command. From the Yarn docs: Your yarn.
Furthermore, both Yarn and npm provide an autogenerated lock file that has the entries of the exact versions of the dependencies used in the project. In Yarn, it is called yarn. lock while in npm, it is called package-lock.
lock is the main source of information about the current versions of dependencies in a project. Yarn uses that information to check if it needs to update anything – it compares dependency versions currently installed in a project (listed in yarn.
I think your best bet is using the --frozen-lockfile flag with yarn install.
If you need reproducible dependencies, which is usually the case with the continuous integration systems, you should pass --frozen-lockfile flag.
Also
Don’t generate a yarn.lock lockfile and fail if an update is needed.
If using yarn2 (aka yarn berry) this flag is renamed to --immutable as of v2.0.0.
From the docs...
If the
--immutableoption is set (defaults to true on CI sincev3.0.0), Yarn will abort with an error exit code if the lockfile was to be modified. For backward compatibility we offer an alias under the name of--frozen-lockfile, but it will be removed in a later release.
This way if someone tries to push changes to package.json, say upgrade react from ^16.8.0 to ^16.10.0, without updating the yarn.lock file. Then it will error out in the CI like below.
> yarn install --frozen-lockfile error Your lockfile needs to be updated, but yarn was run with `--frozen-lockfile`. To address your comment:
I think that with yarn install the lock gets updated too often and the file loses its point since it actually does not lock versions. Or am I using the wrong commands?
Yarn/npm is just doing what you tell it to. If you set the version in your package.json to "react": "16.8.0" it will never update the yarn.lock but when using any of the npm ranges like the Caret (i.e. "react": "^16.8.0"), yarn/npm will resolve to the highest/newest version that satisfies the range you specified. You have all the power!
I found a small edge case. If you are running yarn add in your ci, such as for a ci only dependency, it will update the lock file and do an install for all dependencies. For example....
# Add ci dep yarn add codecov # Install all deps from yarn.lock yarn install --frozen-lockfile This will not error like you might expect. Instead, add the --frozen-lockfile to yarn add command like this...
# Add ci dep yarn add codecov --frozen-lockfile # Install all deps from yarn.lock yarn install --frozen-lockfile If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
