Yarn: Allow install only devDependencies

[robdodson]

Do you want to request a feature or report a bug?
Hopefully this is a small feature request. I'd like a flag that allows me to only install devDependencies. This would allow me to split my flat installed client code from my build tools code.

Thanks to the fix in https://github.com/yarnpkg/yarn/issues/2781#issuecomment-296955569 I can now do:

yarn install --flat --production --modules-folder client_modules

And only install dependencies in my client_modules directory. This is awesome ❤️

If I also do yarn, it will install dependencies and devDependencies into my node_modules directory. But I already flat installed my dependencies into client_modules so installing them again in node_modules isn't necessary.

What is the current behavior?
There's no way to only install devDependenices.

What is the expected behavior?
A flag, maybe yarn install --dev-dependencies or something like that?

[rally25rs]

@bestander triage; label: [new feature]

[bestander]

In a way discussed here https://github.com/yarnpkg/rfcs/pull/36

[chrishyle]

This feature would be great. Client-side projects really benefit from yarn install --prod --flat because it avoids potentially costly duplication of dependencies that would otherwise have to be shipped to the end-user's browser over the wire. That being said, client-side projects also generally rely on devDependencies for build/dev (things like babel plugins, eslint configs, etc) that have no need to be flattened, and resolving the devDependencies version conflicts can be tedious. For example, on a recent project, my dependencies had one conflict which I understood clearly how to resolve, but my devDependencies had 25 conflicts, on projects like "camelcase", "string-width" and a bunch of other stuff that I had no idea how to resolve, and because they're not in shipping code, I don't really have a need to resolve.

Further complicating this is that using multiple folders as @robdodson is doing is sometimes difficult because some useful tools and scripts in the ecosystem have unfortunately hard coded to "node_modules/" (ran into this with ImportJS, I assume there are others). While they shouldn't do that, and there would be clear fixes, I am always nervous in my own projects about introducing new non-standard configurations because of these kinds of conflicts.

So, ideally, I'd be able to run:

yarn install --prod --flat
yarn install --dev-dependencies

…and have them install in the same folder.

[chrishyle]

One additional complication. If you have directly declared a devDependency that conflicts with a sub-dependency version of the same package, what would yarn do when they are installed with the commands in my comment above? My guess is that it would overwrite the hoisted production dependency, but that feels scary to me. What should it do?

Tree:

project
└ dep: A
    └ dep: B @ 1.0.0
└ devDep: B @ 2.0.0

[robdodson]

One additional complication. If you have directly declared a devDependency that conflicts with a sub-dependency version of the same package, what would yarn do when they are installed with the commands in my comment above?

This occurred to me too. I prefer the client_modules approach because it would avoid this. As you said, the folks hard coding paths to node_modules should (hopefully) be able to patch in fixes for that.

[rally25rs]

I wouldn't even mind the case where you can manage multiple directories. Take for example projects that currently use Bower as a package manager.

I need devDependencies like Grunt, Babel, Browserify that I still NPM install into node_modules/

However my web-deployed packages like Backbone, Underscore, jQuery are all Bower installed into bower_components/

So my workflow is:

git clone whatever
cd whatever
npm install
bower install

It would be awesome to have Yarn somehow manage both of these, even if they were separate install directories with separate lock files, or maybe some kind of configuration file that can be specified to tell it the lock file, module directory, and if it is "flat" or not.

Something like:

git clone whatever
cd whatever
yarn
yarn --config web_components

where the initial yarn installs to node_modules as usual, but the web_components configuration somehow tells it to:

• use bower.json as the input
• extract to bower_components
• do a flat install
• use a different lock file

However I totally understand that this may not be feasible or in the roadmap of what this project wants to be in the future... I might have gone way out of scope of this issue too.

[bestander]

I've seen successful examples of people using folders frontend and backend
each with package.json.

So far it looks like a somewhat more convenient dependency management in
one file is worth the extra complexity.

On Mon, 8 May 2017 at 20:17, Jeff Valore [e-mail] wrote:

I wouldn't even mind the case where you can manage multiple directories.
Take for example projects that currently use Bower as a package manager.

I need devDependencies like Grunt, Babel, Browserify that I still NPM
install into node_modules/

However my web-deployed packages like Backbone, Underscore, jQuery are all
Bower installed into bower_components/

So my workflow is:

git clone whatever
cd whatever
npm install
bower install

It would be awesome to have Yarn somehow manage both of these, even if
they were separate install directories with separate lock files, or maybe
some kind of configuration file that can be specified to tell it the lock
file, module directory, and if it is "flat" or not.

Something like:

git clone whatever
cd whatever
yarn
yarn --config web_components

where the initial yarn installs to node_modules as usual, but the
web_components configuration somehow tells it to:

• use bower.json as the input
• extract to bower_components
• do a flat install
• use a different lock file

However I totally understand that this may not be feasible or in the
roadmap of what this project wants to be in the future... I might have gone
way out of scope of this issue too.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/3254#issuecomment-299963491, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACBdWApWdGRRcnc0NRrejdBQNJBaU4Rvks5r32osgaJpZM4NH4Ty
.

[rally25rs]

In reply to myself about replacing Bower, it seems that is a thing that was previously removed #617
I forgot that it wouldn't use Bower's package repo anyway, so you can't really totally replace it with Yarn (i.e. you would get the npm-published package, not the bower-published package. they use different online repositories). Just ignore me :)

[HosseinAgha]

For me, this feature is very useful when I want to build my project inside a docker container and I only need the devDependecies to build the project in first layer and then production dependencies in the final layer. __take a look at multistage builds__.
So I think it is very helpful in CD pipelines both in frontend and (compiled) backend node.js apps

[juancampa]

@HosseinAgha I'm on the same boat, excluding non-dev dependencies would slim down the build-only images and make the CD pipeline much faster

[contento]

I wonder if it would help e2e as well. I seem to need only some of the dev dependencies. I am assuming I don't want to install some dependencies globally in my test machines (for example smoke UI) and or create specific configurations for testing purposes.

[bestander]

While yarn has not accepted this feature to categorize dependencies I would use this workaround:

Before running yarn install modify package.json:

1. Remove dependencies section
2. Rename devDependencies into dependencies

Yarn would install only devDependencies and using resolutions present in yarn.lock

[bestander]

I'll close the issue because there is a reasonable workaround and simplicity/maintainability of Yarn is a higher priority.
It is a community project after all, if there are enough arguments to have this feature in Yarn then everything is possible

[eyalzek]

I have a use case for this. I'm building and running the frontend app within docker using multi stage builds, thus creating a docker image which contains only the compiled JS and the dependencies. This enables creating a relatively small image which I then push into our private registry. I would like to do the same for our e2e tests which I don't want to have on our main app image and would also like to install only the devDependencies for that purpose, since I wouldn't need anything else in that image. Since I cannot do that, I'm installing all the dependencies and this results in an image roughly ~300mb bigger than what it should be, which I then push to our registry (taking up more space, raising the price and reducing performance). So while this is feasible by editing the package.json, this is not a real solution. I would argue that with the abundance of flags already existing for yarn, adding one for this purpose wouldn't add any complexity to yarn, but would enable doing other, powerful uses.

[victorz]

@bestander Your workaround hardly lends itself to automation. 😞

[bestander]

Considering that so many people want this I may be incorrect.
Let's see how much code is needed to make this change.

If it is a few lines of code and a unit test then cool, I'll approve it.
Send a PR.

[limonte]

@bestander if you're open for PRs, maybe it makes sense to reopen this issue?

[bestander]

@limonte, here you go

[eyalzek]

I started https://github.com/eyalzek/yarn/commits/dev-deps-flag, but since I'm practically greping and modifying this might take a while.

[bestander]

Looks good so far, thanks @eyalzek

[daKmoR]

oh that looks nice :) has there been an process or agreement?

[ghost]

https://yarnpkg.com/lang/en/docs/cli/install/#toc-yarn-install-production-true-false

[daKmoR]

available

yarn install --production=false

will install dependencies & devDependencies

yarn install --production=true

will install only dependencies

what we want

yarn install --we-need-a-new-flag

should install only devDependencies

[gwh-cpnet]

My use case for dev-only deps is that I got a project coded in ES6. So on my building machine, which runs node/yarn in docker, only need babel-cli and babel-preset-node8 to compile the source to dist. After it, another production image would be built to copy this compiled file with production deps only.

Somehow, installing all devdeps still seems too much for me in compiling process.

[ldgarcia]

I think this feature request may help with my current problem, but only if postinstall runs for dependencies only and not for devDependencies.

I currently want to use a package, from devDependencies, in a postinstall script:
json { "devDependencies": { "react-native-schemes-manager": "^1.0.5", }, "scripts": { "postinstall": "react-native-schemes-manager all" }, "dependencies": {} }

My current workaround involves manually adding the package first and then running install:
bash yarn add -D react-native-schemes-manager yarn install

[eyalzek]

I opened a PR for that attempt I mentioned earlier this year https://github.com/yarnpkg/yarn/pull/6564, since I'm not really using yarn at the moment I don't have time to focus on it, feel free to pick it up and prepare it for merging.

[ewolfe]

If anyone is willing to switch to npm, they already have support for this via npm install --only=dev. I would love to see this ported over to yarn though.

[mattaningram]

This would be enormously useful to me since I run in a Docker environment but still need some dev dependencies locally for things like linting in my editor.

[brice-noowu]

Anything new here ?

[CongAn]

I need it

[redaxmedia]

Let me introduce handpick that lets you target and filter multiple dependencies. I wrote this to speed up CI stages that just need a fragment of the devDependencies but there are eventually more usecases.

npx handpick --target=devDependencies --filter=lintDependencies

[IanVS]

@redaxmedia Handpick looks great, but I think ideally this would be baked into yarn directly so that it can keep support for yarn.lock.

[redaxmedia]

@IanVS Handpick now supports --range=exact to work around this.

[CongAn]

@IanVS Handpick now supports --range=exact to work around this.

It's too late.I've reused NPM.

[redaxmedia]

@CongAn It is not yarn related as it supports npm and pnpm aswell :-)

[CongAn]

@CongAn It is not yarn related as it supports npm and pnpm aswell :-)

Sorry, I can't find the document for the --range=exact. Can share it?

[redaxmedia]

@CongAn I don't want to add too much noise on this issue... check out my tweet and reach out via twitter for more questions.