Yarn install --production does not remove dev dependencies

[ajhool]

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

Bug
Feature Request

What is the current behavior?
I would expect the following sequence to remove all development dependencies from the project but it does not.

yarn install
yarn install --production

If the current behavior is a bug, please provide the steps to reproduce.

git clone https://github.com/ajhool/yarn-dependency-behavior.git
cd yarn-dependency-behavior
yarn install //moduleD only has devDependencies so ./packages/moduleD/node_modules is populated.
yarn install --production // observe that ./packages/moduleD/node_modules is still populated despited only include devDependencies.

What is the expected behavior?
Yarn install && yarn install --production should be idempotent, it should not matter if I call yarn install before yarn install --production

If the current behavior is expected, then perhaps an explicit statement in the yarn install --production documentation or an execution-time warning would be helpful. A lot of people simply run yarn install --production before zipping and deploying their code.

Please mention your node.js, yarn and operating system version.
Node 8.6.0
MacOS 10.12.6
Yarn 1.9.4

[arthurio]

Why has this issue been closed? It doesn't seem to be addressed yet.

[ajhool]

I believe that I closed it because yarn install --production is not designed to prune out dev dependencies. It is only supposed to install the production dependencies. yarn install --production is a subset of yarn install and calling yarn install --production after calling yarn install should have no effect.

Please don't kill the messenger on this one, I believe that yarn install --production should prune out the dev dependencies, but I don't believe that the yarn authors intended for that behavior.

This thread might be helpful: #696

I will reopen it and describe this as a feature request instead of a bug.

[arthurio]

Thanks for the clarification, I’ll just use npm prune --production for now...

[andrei-dascalu]

Does yarn have a way to prune package for production, though? For build scenarios it seems a fairly straightforward behaviour: install all dependencies (including dev for stuff like gulp or whatever), perform build, remove dev dependencies and voila.

For a 100% yarn-based process, seems like this fairly basic behaviour is missing so I have a choice between either removing the folder and reinstall or replicating yarn configuration for npm as well to be able to prune (since in my case I'm installing to a custom folder specified in yarnrc which NPM doesn't know about). In which I might as well just use npm.

I do think the behaviour described in the initial report is desirable.

[julianrutten]

If this is not a bug, then shouldnt this page be updated?
https://classic.yarnpkg.com/en/docs/cli/prune/

[RogierdeRuijter]

I would also really like the option to remove the dev dependencies from the node modules...

[shiro]

any way to prune dev dependencies using only yarn?

[donaminos]

Hi there,

I am running into the same issue, I need to install dev dependencies to build a NextJS/TypeScript app before running it for production. So I ended up doing it in 3 steps actually as below :

FROM node:14.15.4-alpine

WORKDIR /opt/webapp

# Remove unwanted preinstalled version of yarn 
RUN rm /usr/local/bin/yarn
RUN rm /usr/local/bin/yarnpkg

RUN npm install -g yarn@1.22.10

COPY . .

# Install all dependencies needed for production build
RUN yarn install
RUN yarn build

# clean all depencies
RUN rm -rf node_modules
RUN yarn cache clean

# install production dependencies only
RUN yarn install --production

CMD ["yarn", "start"]

I am not sure it's the best way to go... any thought on this approach please ?

[genox]

@donaminos Like a lot of people in this thread I rolled my own solution and I’ve been lurking here to not miss the silver bullet. ;-) .. I ended up with something similar to your approach. But I don’t remove node_modules before —production and I remove yarn and its cache as a final step. I wonder if removing node_modules before —production actually brings down the sizes, especially in a workspace context. Need to try this out later. Thanks for sharing :)

[genox]

Removing all node_modules folders after building/transpiling and before re-installing with —production flag (and other options noted by sibling above) reduces container image sizes of my app by roughly 5%.

If you’re building from a workspace project and some workspaces aren’t needed, remove them manually.

I also use a .yarnclean file in my root dir to removes some junk that isn’t required for a production build, like readmes, changelogs and the like (excluding licence statements). It also remove typescript files since I transpile to ES. Saves a significant chunk if you are using thousands of dependencies (which is .. likely.. sigh..).

[donaminos]

Thank you for your feedback @genox

[merceyz]

Closing as fixed in v2 where yarn workspaces focus --production only keeps dependencies

https://yarnpkg.com/getting-started/migration
https://yarnpkg.com/cli/workspaces/focus

[manuelnucci]

Hi @merceyz, I don't know if I'm wrong or not but yarn workspaces focus --production doesn't seem to delete dev dependencies installed inside .yarn/cache directory.

I arrived to this thread hoping to find something similar to npm prune --production and, having a multi-stage build in my Dockerfile really requires the ability to copy the cache directory to the new base image and prune dependencies there.

The only reasonable way to do this seems the solution proposed here: #696 comment

Anyway, I was hoping to clarify the situation and reignite the issue in case I'm right.

[merceyz]

Correct, it doesn't clear the cache. For docker builds I suggest using this Yarn plugin as it was specifically made for that https://gitlab.com/Larry1123/yarn-contrib/-/tree/master/packages/plugin-production-install

[mattvb91]

This is still an issue. Removing node_modules & running yarn --prod will install all devdependencies.

[merceyz]

@mattvb91 Read the reason for why this issue was closed

[mattvb91]

@merceyz have read them and still of the opinion that this is a bug.

[merceyz]

Sure it might be a bug in V1 but it has been fixed in V2

[arcanis]

I'm going to close this issue as it has reached its course. In case you believe a followup work needs to be done, I suggest you to open a new dedicated issue on the 2.x tracker.

Also note that as we mentioned more than a year ago (and repeatedly since then), the 1.x line will only see security fixes from our team. We're now at 2.4, on our merry way to 3.0, now is probably a good time to consider upgrading.