I want to install only the "devDependencies" listed in the package.json file using yarn. I use the command yarn install --production=false but it doesn't work.
Yarn doesn't support it currently (2022, v1.22). Actually neither does npm since v7. An argument against it is you most likely need the production deps to do development. For example, how you gonna test the build without the prod deps? Although seems plenty of people are asking for it - see above links.
The reverse (install only prod deps) is more common use case and is supported: yarn install --prod.
Related
I have been using NPM exclusively for my projects and was assigned another project that requires using Yarn. I need to have support for both and will frequently switch back and forth on projects.
Are there any known issues with installing yarn globally and still using NPM on other projects?
super awesome, there are no such conflicts using yarn and npm together.
because yarn and npm both have different installation directories.
for global packages, you can use both, but don't forget to stick to one. we use yarn for our production.
for non-global packages, it is beneficial to stick to what the project author uses.
it becomes difficult sometimes if you have yarn.lock and package.lock file together, because there is a risk of being out of sync. for example, someone updated one package using yarn, someone will not get that changes who use npm and so on.
Yarn and npm are interchangeable. As long as you use the same one each time, there is no difference between them. They have different install directories, which is why they can't be used together. Yarn will install a package, npm can't find it. npm will install a package, yarn can't find it.
it is a more beneficial and good habit to use one package for each project to make sure that all packages are installed correctly, Having half your packages installed with yarn will stop npm start from working; having half your packages installed with npm will stop yarn start from working.
also always use the same one for global too, it does not matter what you use yarn or npm. it does not matter to your global install.
So I'm in the process of publishing a package to npm. It is basically just a simple module that lets users make Ajax calls and can be configured in a few ways.
I have read that it is a good idea to test the install locally and tried that. I have packed the package via the "npm pack" command, change into another directory and then tried installing the packge via "npm install path-to-file-that-was-just-created.tgz".
So far everything works, I have a node_modules folder, that contains my bundled code.
However, is also has installed all the dependencies that I have listed as devDependencies in the package.json of my actual module, even though the only the bundled file is needed and no other depenedencies are defined.
I have tried updating the npm-shrinkwrap.json, and checked that every dependency has the dev property marked as true.
The goal is actually for the user to install this module and then have no dependencies installed, because they do not need babel or mocha, to run the module.
How can I exclude these from the packge?
Thanks!
https://docs.npmjs.com/cli/install
use the --production flag to avoid installing dev dependencies
For published modules, you don't need to do anything, when a user installs your library, only the non-dev dependencies will be installed
If you want your published module to have no dependencies but you still need to have some to build it you can also try to use this command before publishing:
npx json -f package.json -I -e "delete this.devDependencies"
This way only works in CI/CD.
Update: it turned out that npm pkg delete devDependencies does the same without any additional dependency
After running your install, you can prune dev dependencies by running this command:
npm prune --production
this will keep only production dependencies. Documentation from npm here:
If the --production flag is specified or the NODE_ENV environment
variable is set to production, this command will remove the packages
specified in your devDependencies
I work in a team of about 20 other developers. All of our projects utilize npm packages and currently all of our developers are running npm to manage those packages. I'm very curious about Yarn and have it currently installed on my machine. However I'm nervous to actually use it to install packages in case it screws up a project for other developers.
My question is can one developer utilize Yarn on a project while other devs are using npm in the same repo? From what I've read, Yarn uses the same package.json file to get its dependencies. We ignore the node_modules in our repo, however we use npm shrinkwrap to lock dependencies. I know Yarn has a Yarn.lock file and that is where my concern lies. Has anyone attempted to run Yarn independently from their team and what issues have you run into?
Yarn doesn't read npm-shrinkwrap.json. It generates its own yarn.lock. While only you use yarn, the project in your environment might have dependencies version different then that your teammates have. However it's safe to try yarn in your own environment since it doesn't overwrite shrinkwrap file and won't impact other developers.
In the blog post announcing yarn (an alternative npm client) they say, "The easiest way to get started is to run npm install -g yarn". But if you go to the "install yarn" page in their docs, "npm install yarn" isn't listed on any of the platform-specific installation pages, and it's only offered as the third of three options on the "Alternatives" page. Furthermore when you npm install yarn it prints a deprecation warning, "It is recommended to install Yarn using the native installation method for your environment." So my question is if npm install is the easiest installation method, why isn't it a recommended method in their docs? Are there disadvantages to installing yarn using npm?
Edit (2020/11/23):
Thanks to #Kissaki for providing an update on Yarn's advice in the comments.
As of Yarn 2.x, the Yarn team has altered their advice and now suggests installing the tool via npm. This advice centers around the advantages of locking the version of Yarn used on a per-project basis. This allows projects to be resilient to variations between versions of Yarn.
From the new Yarn "Installation" page:
Using a single package manager across your system has always been a
problem. To be stable, installs need to be run with the same package
manager version across environments, otherwise there's a risk we
introduce accidental breaking changes between versions - after all,
that's why the concept of lockfile was introduced in the first place!
And with Yarn being in a sense your very first project dependency, it
should make sense to "lock it" as well.
For this reason, Yarn 2 and later are meant to be managed on a
by-project basis.
This is similar to other methods of locking build tool versions on a per-project basis. See the Gradle Wrapper for an example.
The advantages of a standalone Yarn installation fall apart rather quickly, particularly with the Yarn team's change in direction. Installing via npm is now suggested, and instructions for standalone installations no longer appear to be offered on their site as of Yarn 2.x.
Original Answer:
According to the Yarn project maintainers, installing Yarn via npm goes against the goals of the project, can cause issues, and is, in general, worse than platform-specific installation methods.
Advantages to recommended platform-specific installation:
The Yarn teams regards npm as insecure and unreliable. From the "Install via npm" section on Yarn's "Installation" page:
Note: Installation of Yarn via npm is generally not recommended. Installing Yarn with npm is non-deterministic, the package is not signed, and the only integrity check performed is a basic SHA1 hash, which is a security risk when installing system-wide apps.
For these reasons, it is highly recommended that you install Yarn through the installation method best suited to your operating system.
Running Yarn, which is a separate package manager utility, via npm can lead to edge-case issues (see issue 2072)
Installing via a system package manager decouples Yarn from npm, allowing you to run Yarn without npm
The system package manager typically runs regularly, keeping Yarn updated
Installing Yarn via npm is slow
Advantages to npm install -g yarn:
Quick and easy (npm install -g yarn)
Can be done in any npm environment (platform-agnostic)
Familiar paradigm and process for Node.js developers
Can be easily updated (npm update -g yarn)
A Yarn update command exists (yarn self-update) but it seems to be broken
No dependence on system package managers
Can use different versions of Yarn for different projects or different versions of Node.js via nvm
The system package manager arguments for the recommended installation tend to break down when referring to Windows, where there is no official package manager (unless you count Windows Update). Also, Windows package managers such as Chocolatey are often not configured for automatic updates.
I'm not sure that I fully agree with the Yarn team's decision on this, but they do make some fair points. The Yarn project is still young and if it is to become a replacement for npm then it wouldn't make sense to encourage npm as its primary installer.
Regardless, installations via npm seem to work just fine for now in most cases.
Sources:
npm vs system package manager explanation
Additional explanation
Short comment on the "app" vs "npm package" goal for Yarn
Issue on how to keep Windows Yarn up to date
There's no visible disadvantage to installing Yarn through npm. In fact I chose this method myself because of a few reasons:
It's clearly the easiest way to do it. npm i --global yarn and you
can literally replace npm with yarn on your console immediately.
If you're using nvm and maintaining different code projects on each NodeJS version, then you can install Yarn on one version and not have it on the other
Honestly, the only reason I can think of that it is not mentioned in the Platform Specific installs, is that npm is platform agnostic
Because npm is not platform specific and runs on almost any system it is listed as an Alternative. There is no advantage or disadvantage over the platform specific installs. The difference would be the install location but all methods expose the global yarn command to your CLI.
I would argue they listed it as "the easiest way" because most people are already very familiar with npm.
I don't use npm to install yarn because: as of May 2022, installing on ubuntu according to the official documentation of nvm and Yarn via npm breaks capistrano scripts.
bash: yarn: command not found
Yarn works in the ssh terminal session.
Detailed Description "Why does something work in my SSH session, but not in Capistrano?" https://capistranorb.com/documentation/faq/why-does-something-work-in-my-ssh-session-but-not-in-capistrano/
So I removed the default install of nvm nodejs yarn,
$ npm uninstall -g yarn
$ nvm deactivate
$ nvm uninstall 16.15.0
$ nvm unload
$ rm -r ~/.nvm
and installed yarn like this:
$ curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash -
$ curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | gpg --dearmor | sudo tee /usr/share/keyrings/yarnkey.gpg >/dev/null
$ echo "deb [signed-by=/usr/share/keyrings/yarnkey.gpg] https://dl.yarnpkg.com/debian stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
$ sudo apt-get update && sudo apt-get install yarn
$ node -v
v16.15.0
$ npm -v
8.5.5
$ yarn -v
1.22.19
Capistrano scripts are now working.
According to Heroku I should avoid global dependencies when asking Heroku to build my project. But I still want Bower and Grunt on the command line.
My question is: how then should I be running these tools?
Rather than installing them with npm install -g, should I be adding paths from node_modules to PATH, or the like? (Ubuntu)
If Grunt/Bower are installed globally on development machines -say when someone new starts on the project -then presumably npm install -g grunt-cli might give a different Grunt version to what's in package.json. Hence what Heroku runs and what developers run might accidentally differ.
(Or is that unlikely to be a problem?)
The best practice is to keep everything local, with npm install --save.
That way you can align versions for everyone in the team simply by tweaking the package.json file.
If you only need Bower and Grunt etc. to be available in your dev environments, then install them with npm install --save-dev. This will cause them to be saved in a devDependencies section in your package.json. Dependencies referenced therein will not get distributed to production (e.g. Heroku), but will be available in all your dev environments.
If you really do need Bower and Grunt etc. to be available on Heroku, then install them with npm install --save.
At any rate, npm should automatically save symbolic links to your executables (e.g. grunt-cli) in directory node_modules/.bin, and should take care of adding node_modules/.bin to your PATH, so you don't have to worry about that.