Have a new type of dependencies called buildDependencies.

[mastrauckas]

Do you want to request a feature or report a bug?
feature

What is the current behavior?
Currently there is yarn install and yarn install --production. When on a build server it might be nice to have a yarn install --build which installs dependencies and a new type of dependencies called buildDependencies.

[Volune]

I like that feature request. Could use this to build the git dependencies, and fallback to devDependencies if it's missing.

[mastrauckas]

So what is the process of getting this looked at about getting it implemented?

[BYK]

I don't understand why do we need this on top of devDependencies. Can you elaborate more why devDependencies doesn't already satisfy this need?

[mastrauckas]

@BYK a scenario where it came up for me is at the company I work for.

I needed to build an application on a build server which had very limited internet access. So I used yarn offline with command yarn install --offline to install the packages. This worked great until it needed to install node-sass and Protractor.

While node-sass was not very difficult to overcome working offline, getting Protractor to work required a hack that had shortcomings.

Now node-sass is required to build the project on the build server but Protractor is not needed since e2e testing is not done on the build server. So the hack to get Protractor to work seem really pointless since I didn't even need the package to build.

So it would be nice to have items that are required to build in buildDependencies so it will only install packages that are required for building the application

Also, this would allow a smaller footprint and quicker build time too.

Another solution which might be even more flexible is to have custom dependencies which can be passed in during installation?

For example You can have

 "customDependencies1": {
  "package1": "^1.0.0",
  "package2": "^1.0.0"
},
 "customDependencies2": {
  "package3": "^1.0.0",
  "package4": "^1.0.0"
}

Now if you do yarn install --custom customDependencies1, yarn would only install package1 and package2. However if you do yarn install --custom customDependencies1 customDependencies2, it will install package1, package2, package3 and package4.

Hope my explanation helps.

[BYK]

@mastrauckas I think this is an interesting proposal but compared to the added complexity I'm not completely sold on it. Would you mind if we sleep on this some more (you too) and try to see the possible downsides along with upsides?

[mastrauckas]

@BYK That sounds good.

[paprikati]

Hey - I've just had a conversation with heroku about a similar idea (heroku/heroku-buildpack-nodejs#779)

My use-case is simple - I run builds on a build-machine, which needs to pull dependencies like webpack and babel. However, I don't want it to pull all my test and ci dependencies (cypress, jest, storybook) as that makes my builds take much longer.

I think this is a really common JS use-case to be honest - all JS projects I've seen have this sort of setup.

So Could we add buildDependencies as separate from devDependencies, or alternatively some other flags (like something more bespoke and less opinionated) to let users install groups of dependencies instead of a sort of 'all or nothing'?