[Questiong/Feature request] devDependencies and version bump

[Igmat]

Is it possible to ignore only devDependencies changes from package.json?

[Siilwyn]

Could you clarify your question?

[diegohaz]

@Siilwyn If the only change a package foo had since the last version was in devDependencies (eg. upgrading eslint), there should be an option to not bump foo version when running lerna version/publish.

That's something I really wanted too.

[Siilwyn]

Ah I see, this looks like a duplicate of #1357.

[diegohaz]

Just to add my case here. reakit is a dev/peer dependency on reakit-theme-default. Every time I want to publish a new version of reakit, lerna bumps reakit-theme-default's version too, even though there were literally no changes on the latter package. Dev dependencies should be ignored I guess.

Is there anything I can do to avoid this as of now? I tried to add **/package.json to the ignoreChanges option on lerna.json, but it doesn't work.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diegohaz]

I guess it's still relevant.

[evocateur]

It probably should, although perhaps not by default. In the dev/peer case, that does seem unnecessary.

[ryanflorence]

While building Reach UI making the slightest change to any packages causes most of them to have to bump versions because the examples in one package have a dev dependency on another.

For example:

• My MenuButton component has an example using it with Tooltip.
• If I change ToolTip then MenuButton has to bump a patch version just because there was an example using the two together.
• And since Dialog has an example that uses MenuButton, it has to bump as well.
• And since AlertDialog is built on Dialog, it also has to change versions.
• And since Alert is used in AlertDialog then it too has to bump versions!
• And since VisuallyHidden has an example with Alert it also has to bump versions!

All because an example in the repo has a dev dependency on Tooltip 🙃

[peter-mouland]

while not a solution, a work around we're happy with, is to almost never use devDeps in the component packages.

We put all devDeps into the root/projects package.json.

The only exception we have are devDeps that affect the output of the distributed code i.e. if we bump our build tool, we do want to bump the component packages just incase the distribution has changed.

We've been using this method for about a year while using lerna and it certainly reduces package bumps. I think this method proves the need for an official Lerna solution, but also proves the solution may not be as simple as it first seems! (since some devDep changes should bump the package)

[ryanflorence]

Ah! That seems like an obvious workaround now that you mention it, thanks, I'll do that.

[evocateur]

Root dependencies using relative file: specifiers is how I would solve it. The example can resolve the repo siblings via the standard node_modules resolution algorithm.

[diegohaz]

The downside of this workaround (removing them from devDeps) is that lerna doesn't execute lerna exec (and probably other commands) in the right order (running on the topmost dependencies first).

Maybe it could also check peerDeps.

[evocateur]

@diegohaz Oh, yes, I didn't mean the solution to Ryan's problem was acceptable for yours. Proper peer/devDep pairs should not necessarily trigger a package bump, but the devil is in the details...

[sidharthachatterjee]

This would be useful for gatsby as well. We have themes (in packages) that have a dev dependency on gatsby and every change to gatsby currently bumps their version up as well which is unnecessary version churn.

Happy to pick this up if we agree on something actionable here!

Cc @johno @pieh

[Filipoliko]

Hi, we could also really benefit from this feature at our project. We are currently in a not very good state, where many packages need dev/peer dependency to another package in the same monorep. We migrated to lerna recently and right now, whenever we want to release a single package, it is causing an unnecessary release of 10+ packages, mostly because of dev/peer dependencies.

[peter-mouland]

hey,
Sorry for commenting on an old issue, but I've recently been trying out Yarn PNP mode which forces all dependencies (dev or not) to be included explicitly in the package.json.

In the mean time using my 'devDeps in root' approach I'm forced to stick with nodeLinker: node-modules

@evocateur Would this feature request, even a naive first 'experimental' first stab, be possible to help some folks out?

unless others have another workaround or solution for Yarn PNP?

Other linked requests:

• lerna includes devDependencies in change detection #2368
• Do not increment version if a devDep + peerDep? #1898