How does yarn work when it encounters ^ (caret)? - javascript

How does yarn work when it encounter a ^ (caret) in package.json dependencies?
Let's say I have react: ^16.0.0 and when I yarn install, it will create a lock on that version (16.0.0).
Now sometime later when react 16.1.0 is released, and I yarn install again with the lock file, will yarn upgrade it to that version or follow what is in the lock file which is 16.0.0?
Thanks.

yarn install will install the exact version in the lockfile. That's the great benefit of a lockfile, everyone working on your project gets the exact same version of the package regardless of when the do yarn install. (e.g. I do yarn install today, when 16.0.0 is the current version, but you do yarn install tomorrow when 16.1.0 is the current version. We'll still both get 16.0.0 because that's what our lockfile says we should get. Our development environments are exactly the same, which is what we want. Likewise if we deploy in 2 weeks when 16.2.0 is the current version, 16.0.0 will get deployed; thus our dev and prod environments are exactly the same, too)
If 16.1.0 is released and you want to update your project to use it, use yarn upgrade. Note that you can upgrade all of your packages, or just one specific package, as well as update to the latest version of a package or a specific version of a package. https://yarnpkg.com/lang/en/docs/cli/upgrade/
Version Control Your package.json and yarn.lock
By adding these two files to version control, you'll easily be able to revert your project to a specific point in time in regards to your packages.

The selected answer is wrong.
caret means following
^3.1.4 will allow a version range from >=3.1.4 <4.0.0

Related

Prevent building package-lock.json frequently

I have a package.json file where I have dependencies fixed to a particular version:
I had run npm install few days back and it generated the package-lock.json file. In the package-lock.json file, I can see that the exact version of eslint, i.e. v8.23.1, is installed but the sub-dependencies have a caret sign meaning it'll install the latest major/minor versions, e.g. #eslint/eslintrc= "^1.3.2":
After pushing my code, when the Jenkins build runs, it fails saying:
This is because a new version of #eslint/eslintrc is available and my package-lock.json has mapping of v1.3.2. I have two options in mind:
Update package-lock.json every time a sub-dependency gets upgraded but I'll have to do it quite frequently.
Lock dependencies using overrides field in package.json but this will also have to be updated frequently.
I want to freeze the dependencies (which I already did as seen in package.json) and also the sub-dependecies, until I decide to update them manually.
What should be done in this case?
My Node version is v16.15.0 and NPM version is v8.5.5.
The issue was with the node version. Earlier env.NODE_VERSION = '16 --lts' was being used. After setting it to v16.15.0, it worked fine. Thanks, #jonrsharpe :)

How to upgrade package to latest version using yarn?

I would like to upgrade eslint package to latest version.
yarn upgrade eslint --latest do nothing.
How can I update to latest version via yarn?
Recipe of my recent technique.
Some time ago command below started failing to work
yarn upgrade somePackage -- latest
It's started to has side effects like updating other packages as babel, typescript etc. I don't see any comments about this behavior in official documentation. Going to codebase of yarn is a bit overhead in order to solve so "basic" task
Currently in order to update single package i use
yarn add somePackage
In order to update to latest i use
yarn add somePackage#latest
So, in your case i recommend you to try
yarn add eslint#latest
Please, let me know if it works or not )

What happens when there are multiple versions available in organisation npm

I am fairly new to versioning a library, I wanted to get a clarity on my concern and please explain how does npm work.
I am trying to build a library and publish it to my organization npm registry. Now I have an alpha release which is already available in nexus and I did an npm install and the library works fine.
Now I when I create a stable release and make the library available for my organisation to use, when this happens the version tag will be updated to v1.0.0 and when I do an npm install the latest stable version will be available.
Post this, if I create further more alpha builds the version now has an alpha build tag appended to the version. Now when I do an npm install in a fresh project setup which version will I get:
stable version
new alpha version
I am a new to this, if anyone can explain how npm install will work and what version will I get that will be super helpful.
Thanks
What npm i will do for you, depends on what you stated in package.json.
{
"dependencies":{
"foo":"1.0.0", //match version exactly
"baz":">1.0.2", //must be greater than version
"elf":"~1.2.3", //everything from 1.2.3 to <1.3.0
"thr":"^1.2.3", //from 1.2.3 to <2.0.0
}
}
More details here
If you want to know the exact version of the package installed after npm i you could look it up in package-lock.json

When to use Yarn over NPM? What are the differences?

What are the differences between Yarn and NPM?
At the time of writing this question I can only find some articles on the Internet showing what's the Yarn equvalent of an NPM command like this.
Do they have the same functionalities (I know Yarn does local caching and looks like you only need to download a package once) but other than this is there any benefits for moving from NPM to Yarn?
UPDATE: March 2018 (bit late...)
Since version 5, npm
generates a 'lockfile' called package-lock.json that fixes your entire dependency tree much the same way the yarn (or any other) locking mechanism does,
A tool has been made
--save is now implied for npm i
Better network and cache usage
npm 5.7.0 further introduced the npm ci command to install dependencies more quickly in a continuous integration environment by only installing packages found in the package-lock.json (reporting an error if the package-lock.json and package.json are not synchronized).
Personally, I still use npm.
Original
I am loathe to quote directly from docs, but they do a great job of explaining why, concisely enough that I don't see how to further summarize the ideas.
Largely:
You always know you're getting the same thing on every development
machine
It paralellizes operations that npm does not, and
It makes more efficient use of the network.
It may make more efficient use of other system resources (such as RAM) as well.
What are people's production experiences with it? Who knows, it's an infant to the general public.
TL;DR from Yehuda Katz:
From the get-go, the Yarn lockfile guarantees that repeatedly running
yarn on the same repository results in the same packages.
Second, Yarn attempts to have good performance, with a cold cache, but
especially with a warm cache.
Finally, Yarn makes security a core value.
Nice blog post
“NPM vs Yarn Cheat Sheet” by Gant Laborde
Slightly longer version from the project:
Fast: Yarn caches every package it downloads so it never needs to
again. It also parallelizes operations to maximize resource
utilization so install times are faster than ever.
Reliable: Using a detailed, but concise, lockfile format, and a
deterministic algorithm for installs, Yarn is able to guarantee that
an install that worked on one system will work exactly the same way on
any other system.
Secure: Yarn uses checksums to verify the integrity of every installed
package before its code is executed.
And from the README.md:
Offline Mode: If you've installed a package before, you can install it again without any internet connection.
Deterministic: The same dependencies will be installed the same exact way across every machine regardless of install order.
Network Performance: Yarn efficiently queues up requests and avoids request waterfalls in order to maximize network utilization.
Multiple Registries: Install any package from either npm or Bower and keep your package workflow the same.
Network Resilience: A single request failing won't cause an install to fail. Requests are retried upon failure.
Flat Mode: Resolve mismatching versions of dependencies to a single version to avoid creating duplicates.
More emojis. 🐈
What is PNPM?
pnpm uses hard links and symlinks to save one version of a module only ever once on a disk. When using npm or Yarn for example, if you have 100 projects using the same version of lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be saved in a single place on the disk and a hard link will put it into the node_modules where it should be installed.
As a result, you save gigabytes of space on your disk and you have a lot faster installations! If you'd like more details about the unique node_modules structure that pnpm creates and why it works fine with the Node.js ecosystem, read this small article: Why should we use pnpm?
How to install PNPM?
npm install -g pnpm
How to install npm package using PNPM?
pnpm install -g typescript // or your desired package
Benefits of PNPM over Yarn and NPM
Here is progress-bar showing installation time taken by NPM, YARN and PNPM (shorter-bar is better)
Click for Complete check Benchmark
for more details, visit https://www.npmjs.com/package/pnpm
Trying to give a better overview for beginners.
npm has been historically (2010) the most popular package manager for JavaScript. If you want to use it for managing the dependencies of your project, you can type the following command:
npm init
This will generate a package.json file. It contains all the dependencies of the project.
Then
npm install
would create a directory node_modules and download the dependencies (that you added to the package.json file) inside it.
It will also create a package-lock.json file. This file is used to describe the tree of dependecies that was generated. It allows developpers to install exectly the same dependencies. For example, you could imagine a developper upgrading a dependency to v2 and then v3 while another one directly upgrading to v3.
npm installs dependencies in a non-deterministically way meaning the two developper could have a different node_modules directory resulting into different behaviours. **npm has suffered from bad reputation as for example
in February 2018: an issue was discovered in version 5.7.0 in which running sudo npm on Linux systems would change the ownership of system files, permanently breaking the operating system.
To resolve those problems and others, Facebook introduced a new package manager (2016): Yarn a faster, more securely, and more reliably package manager for JavaScript.
You can add Yarn to a project by typing:
yarn init
This will create a package.json file. Then, install the dependencies with:
yarn install
A folder node_modules will be generated. Yarn will also generate a file called yarn.lock. This file serve the same purpose as the package-lock.json but is instead constructed using a deterministic and reliable algorithm thus leading to consistant builds.
If you started a project with npm, you can actually migrate to Yarn easily. yarn will consume the same package.json. See Migrating from npm for more details.
However, npm has been improved with each new releases and some projects still uses npm over yarn.
The answer by #msanford covers almost everything, however, I'm missing the security (OWASP's Known Vulnerabilities) part.
Yarn
You can check them using yarn audit, however, you cannot fix them. This is still an open issue on a GitHub (https://github.com/yarnpkg/yarn/issues/7075).
npm
You can use npm audit fix, so some of them you can fix by yourself.
Both of them, i.e. npm audit & yarn audit have their own Continuous Integration tools. These are respectively https://github.com/IBM/audit-ci (used, works great!) and https://yarnpkg.com/package/audit-ci (haven't used).
npm:
The package manager for JavaScript. npm is the command-line
interface to the npm ecosystem. It is battle-tested, surprisingly
flexible, and used by hundreds of thousands of JavaScript developers
every day.
NPM generates a correct lock file whereas a Yarn lock file could be
corrupt in some cases and has to be fixed with yarn-tools
Yarn:
A new package manager for JavaScript. Yarn caches every package it
downloads so it never needs to again. It also parallelizes
operations to maximize resource utilization so install times are
faster than ever.
Yarn doesn't support login with a password (while NPM does)
When you install a package using Yarn (using yarn add packagename), it places the package on your disk. During the next install, this package will be used instead of sending an HTTP request to get the tarball from the registry.
Yarn comes with a handy license checker, which can become really powerful in case you have to check the licenses of all the modules you depend on.
If you are working on proprietary software, it does not really matter which one you use. With npm, you can use npm-shrinkwrap.js, while you can use yarn.lock with Yarn.
For more information please read the following blog
https://blog.risingstack.com/yarn-vs-npm-node-js-package-managers/
Yarn
Advantages::
Supports features like parallel installation and
Zero-Install results in better performance
More secure
Large active user community
Disadvantages::
Doesn’t work with older versions of Node.js (lower than version 5)
Problems with installing native modules
NPM
Advantages::
Ease of use, especially for developers working with older
versions.
Optimized local package installation to save hard drive space.
Disadvantages::
Security vulnerabilities are still there
Conclusion:
Is Yarn better than NPM?
In terms of speed and performance Yarn is better than NPM because it performs the parallel installation. Yarn is still more secure than NPM. However, Yarn uses more disk space than NPM.

How to fix npm peer dependency issue?

I have a package.json that has the following modules that are conflicting:
react-router which needs react 0.13.x
redbox-react which needs react#>=0.13.2 || ^0.14.0-rc1
I just did an npm install react and it installed react#0.14
I am trying to install react-bootstrap which needs react#>=0.14.0.
I have been a few solutions:
delete node_modules from all the node_modules of dependencies every time I update
delete and reinstall all modules every time you face an issue
upgrade to npm 3.x which is still pre-release and
What is a good way of fixing these issues without having to do 1 or 2 which is npm version agnostic.
P.S.: All the modules referred to here have been installed locally.
Ensure you have the latest version of react-router (currently 1.0.0-rc3).
The react module is only listed as a dev dependency, and the requested version is 0.14.0 so there shouldn't be any issues.

Categories

Resources