Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow install only devDependencies #3254

Open
robdodson opened this issue Apr 25, 2017 · 27 comments

Comments

Projects
None yet
@robdodson
Copy link

commented Apr 25, 2017

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 #2781 (comment) 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

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2017

@bestander triage; label: [new feature]

@bestander

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

In a way discussed here yarnpkg/rfcs#36

@chrishyle

This comment has been minimized.

Copy link

commented May 3, 2017

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

This comment has been minimized.

Copy link

commented May 3, 2017

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

This comment has been minimized.

Copy link
Author

commented May 4, 2017

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

This comment has been minimized.

Copy link
Contributor

commented May 8, 2017

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

This comment has been minimized.

Copy link
Member

commented May 8, 2017

@rally25rs

This comment has been minimized.

Copy link
Contributor

commented May 8, 2017

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 :)

@BYK BYK added needs-discussion and removed cat-discussion labels Oct 27, 2017

@HosseinAgha

This comment has been minimized.

Copy link

commented Nov 12, 2017

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

This comment has been minimized.

Copy link

commented Jan 10, 2018

@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

This comment has been minimized.

Copy link

commented Feb 6, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 6, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 6, 2018

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

@bestander bestander closed this Feb 6, 2018

@eyalzek

This comment has been minimized.

Copy link

commented Feb 6, 2018

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

This comment has been minimized.

Copy link

commented Feb 7, 2018

@bestander Your workaround hardly lends itself to automation. 😞

@bestander

This comment has been minimized.

Copy link
Member

commented Feb 10, 2018

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

This comment has been minimized.

Copy link

commented Feb 11, 2018

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

@bestander bestander reopened this Feb 11, 2018

@bestander

This comment has been minimized.

Copy link
Member

commented Feb 11, 2018

@limonte, here you go

@eyalzek

This comment has been minimized.

Copy link

commented Feb 12, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 18, 2018

Looks good so far, thanks @eyalzek

@daKmoR

This comment has been minimized.

Copy link

commented Jun 29, 2018

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

@daKmoR

This comment has been minimized.

Copy link

commented Oct 4, 2018

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

This comment has been minimized.

Copy link

commented Oct 19, 2018

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

This comment has been minimized.

Copy link

commented Oct 21, 2018

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:

{
  "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:

yarn add -D react-native-schemes-manager
yarn install
@eyalzek

This comment has been minimized.

Copy link

commented Oct 22, 2018

I opened a PR for that attempt I mentioned earlier this year #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

This comment has been minimized.

Copy link

commented May 20, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.