Is there a way to achieve that using npm ? Currently I do this manually, would be nice to use similar approach as with npm install --save
I found some old discussion and commits but it seems it didn't make it:
https://github.com/npm/npm/pull/3994
As far as I can tell, you can't. Just install it as a regular dependency (production or otherwise, just like the package requiring the peer dependency is installed as).
Even if you manually add the entry to peerDependencies an npm audit is going to fail to recognize the package and tell you to install it.
This kind of stinks, I'm a big fan of the separation of concerns, and keeping a list of modules that only exist so they can be absorbed by other modules is crummy.
But, it is what it is and so long as you leverage the npm commands afforded to you, I guess it's manageable.
Since 'I don't know what npm version' you can use npm i --save-peer package_name command. Works on npm 8.1.0
Related
Say we publish an NPM package that ends up having a bug say it is version 1.0.056.
is there a way to tell NPM to blacklist it, meaning if users have this in package.json:
^1.0.05
that it would endeavor to only install 1.0.057 or 1.0.055?
The idea is when you patch the bug, if it doesn't impact any of the exposed API, then not much reason to make a big semver change? Or maybe on the other hand an important bugfix should call for a minor version change?
Obviously NPM doesn't encourage people to delete packages, we want immutability, but unless a user explicitly requests that version, I want NPM to avoid installing it at all costs?
npm deprecate covers a historical version when you discover problem later:
npm deprecate <pkg>[#<version>] <message>
This command will update the npm registry entry for a package, providing a deprecation warning to all who attempt to install it.
If it was only just published (72 hours) then there is also:
npm unpublish [<#scope>/]<pkg>[#<version>]
This removes a package version from the registry, deleting its entry and removing the tarball.
https://www.npmjs.com/policies/unpublish
https://docs.npmjs.com/cli/unpublish
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.
Is there a way to directly check a package.jsob for deprecated dependencies instead of finding it out during npm install? I.e. Just check and dont install.
Thanks
There is a way to make some pre-npm-install checking with npm-check utility. Install it globally and it will give you some information like
$ npm-check
webpack 😟 MISSING! Not installed.
😎 MAJOR UP Major update available. https://github.com/webpack/webpack
npm install --save-dev webpack#3.5.6 to go from 2.7.0 to 3.5.6
Also you may try npm-check-updates utility. I guess it's more useful (and it works faster). It gives an information not only for major versions:
$ ncu -l verbose --packageFile package.json
webpack ^2.6.1 → ^3.5.6
express ^4.14.0 → ^4.15.4
I was able to use the second utility only with --packageFile option.
As you can see, it does not deal with npm deprecation explicitly, but may help in case you don't want to make npm install.
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.
This might be a stupid question but I believe I should know this since I am just starting out in the web development field rather than just assuming. I normally see this
Install via npm or bower (recommended) or manually download the package
or something of that sorts. My Assumption is that the node_module and bower_component updates the packages automatically, however I am not sure.
Sometimes I install with npm or bower, or sometimes I just mannually download the package to which I have seen no difference. Could someone please tell me why it is important to install via npm or bower so I can know for sure what is going on.
Package managers allow you to keep third party code separate from your code and have consistent versions of that code. With npm or bower you can set out exactly what dependencies you project has, and what versions through a single file, without having to bloat your codebase with the dependencies themselves.
This means that anyone who wants to set up the project can just download the core code and run npm install or the equivalent command, and install all the dependencies at the latest supported version.