-
Notifications
You must be signed in to change notification settings - Fork 49
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
Should there be an option to force devDependencies in root package.json? #233
Comments
Do you want to be able to mix root For reference, we currently have this rule |
I would like to force all dependencies to be |
this change would make sense to me, cc @emmatown - any objections? |
I still want to champion this change, I think it would be a positive one. |
I think it’s worth doing - so if you want to prepare a PR for it: let’s do it |
Just to make sure, the PR will switch the check to prefer Alternatively, we could put this behind an option and set devDependencies as the new default, but I prefer the first approach. Thoughts? |
I prefer the first option too. |
I like this change. We use Renovate bot and allow it to update |
I think that there is a valid case to be made that manypkg should optionally enforce all dependencies be in
devDependencies
in the root.We have a monorepo that needs to build docker containers. It has separate pnpm installs for the build step and the production step.
When it builds the production step, it uses turbo prune and then
pnpm install --prod
- this will unfortunately also install all monorepo management tools defined in the rootpackage.json#dependencies
, needlessly increasing the docker image size.Forcing root to use
devDependencies
instead would solve for this, and to some degree, I think it makes more intuitive sense if stuff liketypescript
,prettier
,lefthook
etc are dev dependencies instead of prod dependencies.If there is interest from maintainers and guidance on desired implementation, I would be happy to contribute a PR.
The text was updated successfully, but these errors were encountered: