Just tried out Yarn and indeed it's mega-fast. After running yarn in the console with a loaded package.json, it installed everything. I then ran npm dedupe expecting nothing much to happen since Yarn is so optimized, but it removed a ton of stuff. Is there some Yarn equivalent to npm dedupe?
Addition:
As noted in my comment below, I thought perhaps yarn install --flat might be an npm dedupe equivalent as the Yarn documentation describes it as "installing one and only one version of a package". So I played around with --flat and there's a couple things to note:
It will prompt you to choose what version of a package to install when the tree results in requests for more than one version. I could imagine this being one hell of a task for larger projects. I just picked the latest version for each package I was prompted for and as you can imagine, trying to run the app resulted in cannot find module errors.
I ran npm dedupe after doing a yarn install --flat and it still resulted in a ton of removals. This was a surprise to me.
So I'm taking it that npm dedupe is doing some other magic under the hood and I'm just naive about processes that I need not be concerned with. Perhaps it's just best to leave the tree alone and forget about --flat and dedupe altogether.
It seems like even now Yarn doesn't do the greatest job of minimizing duplicate dependencies. Running yarn --flat forces there to be only one version of a dependency even when they may not be compatible, so that's not ideal. You can use the yarn-deduplicate package to minimize the number of duplicates, while still allowing some in cases where there are not overlapping requirements. yarn-deduplicate also has a --fail option which will return a non-zero (failing) status. This can be useful to run on CI to ensure that anybody who modifies dependencies doesn't introduce new duplicates.
Quoted from the Yarn docs:
The dedupe command isn’t necessary. yarn install will already dedupe.
https://yarnpkg.com/lang/en/docs/cli/dedupe/
Related
Everytime I do npm install after cloning a github project OR install packages on my local system for my practice projects, there are always around 20+ vulnerabilities.
But the guys in youtube tutorials always have 0 vulnerabilities.
I even reinstalled npm but it didn't change anything
If you are following an old video, you are likely installing old packages. Therefore it's pretty common to have vulnerabilities.
If you want the warnings to disappear, you can try to remove #version in your packages inside package.json and then run npm i again. Or, as bogdanoff says, run npm update instead.
But be careful: packages may behave differently from the video when updated.
I'm poking around in npm at the moment. I am trying to see what sort of security risks there are to developers using npm.
The main sort of attack I'm interested in are supply chain attacks where either a developer or a build system (which we can consider just another developer) get something they don't expect.
I have unexpected - at least for me - behaviour when I do the following:
npm init
npm install xxx - doesn't matter what xxx is
Edit the package-lock.json file and alter the integrity - e.g. change one char
rm -rf node_modules
npm install
EXPECT
Some sort of complaint that the installed package's hash doesn't match
ACTUAL
package-lock.json just gets updated
Am I being dense here? I'm expecting the integrity field to cause npm to somehow spot when something unexpected is installed. Why does it just get updated?
I tested with both npm#7 and npm#6 and got an EINTEGRITY error both times. I installed Node.js 10.x and tested with npm#5 and again got EINTEGRITY. Prior to npm#5, there was no package-lock.json file supported.
I can think of two scenarios (other than "I forgot to save my changes in package-lock.json" and stuff like that) that might explain what you are seeing.
First, perhaps you are accidentally removing package-lock.json when removing node_modules? I mean, I remove both together so often that there's a potential muscle memory issue for me. Maybe you have the same?
The only other thing I can come up with is if you initially installed using a version of npm that supports package-lock.json but then after editing package-lock.json, you re-installed using a version prior to the introduction of the package-lock.json feature. That seems unlikely, but is possible if you are using different interactive shells for the installs and using nvm. Open two terminals, change the version of node and npm in one terminal, and then use both terminals--you are now using different versions in the two terminals.
I can see create-react-app has added installation with npx. So it made me curious to check which one is better npm, npx or yarn. Which one is better and which is better to use and why?
I don't see why this got negative votes, not everyone comes with inbuilt knowledge on this stuff right ? and this is the place to ask 😅
npm: installation of packages (libraries), i.e. pieces of functionality to help you build your own applications.
npx: npx is a tool to execute packages without installing the packages.
yarn: also installation of packages. yarn is a replacement for npm that sits on top of the same packages repository.
npx isn't the same as the other two, it is a feature of npm to run packages without installing. As for which one is better between npm and yarn, there isn't a clear "winner" (general rule to apply in life too). I personally prefer yarn since in my experience it was faster and less verbose, another positive was it had a lockfile but now npm has one too (and I hear new versions are faster as well).
tl;dr: Either is fine really.
You can compare the feature of npm and yarn. yarn is faster than npm because it is doing parallel installation and npm is doing serial installation of modules. Previous version of npm does not have lockfile now both npm and yarn have lock file. Both are build on the top of same repository.
npx is totally different from npm and yarn. It is a tool to execute packages without installing it.
So I will suggest yarn if you want to decrease the build time of the application.
I was reading about the Yarn and its difference to NPM from the link - https://medium.com/#nikjohn/facebooks-yarn-vs-npm-is-yarn-really-better-1890b3ea6515
but I didn't understand the following points about yarn -
Yarn uses checksums to verify the integrity of every installed package before executing code.
(so the NPM doesn't check like this?)
Concise lockfile format, and a deterministic algorithm for installs. This means that Yarn is able to guarantee that an install that worked on one system will work exactly the same way on any other system. Isn’t that what you always wanted?
Yarn installed the dependencies using parallel approach, That's why it is faster package download manager than NPM. (but how?)
Can someone please clarify the above points?
I have a project with a package.json file and an install bash script that, among other steps, runs npm install.
I'm thinking of updating the script so that it runs yarn install if yarn is available (to take advantage of yarn's caching, lockfile, etc), and falls back to npm install otherwise. As far as I can tell, all the packages seem to install and work ok either way.
Are yarn and npm interchangeable enough for this to be a viable approach, though? Or are there potential issues that this could lead to? Are we meant to just pick one, or is yarn interchangeable with npm in practice?
(nb. I've read this closely related question, but I'm asking this as a separate question because it's about explicitly supporting both yarn and npm install processes in a project)
Yarn and npm (version >=3.0.0) should be relatively compatible, especially moving from npm to Yarn, because compatibility is one of the stated goals of Yarn. As stated in Migrating from npm:
Yarn can consume the same package.json format as npm, and can install any package from the npm registry.
So, in theory, any package.json that is valid for npm should also work equally well for Yarn. Note that I say that npm v2 is probably less compatible - this is because npm migrated from a nested node_modules structure to a flat layout (which is what Yarn uses). That said, Yarn and npm v3 should produce very similar layouts, because, as stated in the issue I linked:
To a first approximation we should try to be very compatible with the node_modules layout for people who need that compatibility, because it'll be the most likely way to avoid long-tail compatibility problems.
However, you will not be able to take advantage of the Yarn.lock generated by Yarn, because (as the name suggests) it's only supported by Yarn, and npm shrinkwrap is not compatible.
Also, as noted by #RyanZim, older versions of Yarn don't support pre- and post-install hooks, but versions later than v0.16.1 do. If you rely on these hooks, you will need to specify to users that versions greater than v0.16.1 are required.
In summary, as long as you encounter no bugs and only use features that are shared by both package managers, you should have no issues whatsoever.