Don't publish new versions when nothing has changed

[iebold]

Suggestion

Hello,

I see according to your versioning policy from https://main--typescript-eslint.netlify.app/users/versioning/ that

All of the packages in this project are published with the same version number to make it easier to coordinate both releases and installations.

I would suggest to reconsider this policy and not do version bumps on packages just to keep them in sync.

typescript-eslint is constantly being updated by dependabot and the diffs are constantly the largest ones because you version bump all the packages which all get new version numbers /and/ package hashes.

This is a considerable waste in reviewing diffs plus a waste in pushing npm packages that are basically identical.

I personally don't see how this policy helps since npm takes care of everything and I don't see when one needs to "coordinate" installations and this would be a problem.

[bradzacher]

I think if we do a release for another package - it does help to say "keep the versions in sync" and to get users to just keep everything at the same version.

But I do agree that on the week's we do nothing that we shouldn't do a release that week. (cc @JamesHenry is there a way we can stop the no-op deployment if there was no public commits at all?)

---

Dependabot is a problematic thing because it has no method to do batched updates - it only ever updates one package at a time.

We found this to be a huge problem internally which is why we ultimatley switched to renovate - it enabled us to setup a config that would batch related packages together to improve and streamline our update workflow.

For example all the babel packages update together, or all the docusaurus packages update together. Which really helps with the monorepo releases.

[JamesHenry]

@bradzacher completely agree that we don't want to have gaps and the pros far outweigh the cons of publishing all packages together. Also agree that it would be nice to be able to skip publishing if not a single package needs a bump.

I don't believe this is possible today in lerna but I'll look into adding it very soon and report back here

[JoshuaKGoldberg]

Dependabot is a problematic thing because it has no method to do batched updates

@bradzacher two days after you posted, they released the feature https://github.blog/2023-08-24-a-faster-way-to-manage-version-updates-with-dependabot. Nicely done. 👏

Though, we're still going to keep using Renovate [edit: at least] until dependabot/dependabot-core#3651 is resolved. Renovate's minimumReleaseAge feature helps reduce our vulnerability to malicious package publishes by letting us wait a few days until anything bad is likely reverted/fixed.

Renaming this issue to target just skipping unnecessary releases. We're not going to de-sync the versions. I've seen a ton of user-land pain from ours and other monorepo styles from confusingly different version numbers. I'd suggest using update automation that supports an equivalent to Dependabot's new groups or Renovate's packageRules for grouping packages.

[bradzacher]

TBH I doubt we'd go back to dependabot - renovate just has a tonne of nice features. It lays things out really nicely in the PR descriptions and has the tick boxes to rebase which is ncier than comment commands.

Also it has the dependency dashboard issue which is a nice summary of things (#6687).

But it is nice that they finally have added groups to dependabot after all these years!

[iebold]

Dependabot is a problematic thing because it has no method to do batched updates

@bradzacher two days after you posted, they released the feature https://github.blog/2023-08-24-a-faster-way-to-manage-version-updates-with-dependabot. Nicely done. 👏

We quickly switched to dependabot's groups, especially for your packages.

Still, the engineer in me is irked by new "updates" which are identical except a version change. This is polluting the npm registry with the same code over and over.

I understand you have your release workflow and scripts all figured out but I find it a bad practice. And by being so widely used you are introducing unneeded waste... globally! Like, Golden Raspberry Award levels of waste.

[bradzacher]

It's much easier to say to a user "use vX.Y.Z of all of the packages" rather than saying "use vX.Y.Z of the plugin and vX.A.B of the parser".

Users don't need to consider differing versions and just know "always keep the version numbers in sync".

For example babel takes the approach you prefer with each package only being released if it has changes. This means you can have many different minor and patch versions for each of the @babel/ packages and it can be hard to know if you've actually updated to the latest. Usually you need to go and check npm to double check the latest version.

It is a less than desirable solution, for sure, but we have found it drastically reduces our user support burden - which is very important given we're volunteers.

[iebold]

It's much easier to say to a user "use vX.Y.Z of all of the packages" rather than saying "use vX.Y.Z of the plugin and vX.A.B of the parser".

Users don't need to consider differing versions and just know "always keep the version numbers in sync".

I understand public facing packages but what about @typescript-eslint/scope-manager, @typescript-eslint/type-utils, @typescript-eslint/utils, @typescript-eslint/visitor-keys, @typescript-eslint/types and @typescript-eslint/typescript-estree? There's no need to bump these packages.

[bradzacher]

Because our project has two types of users:

1. linting users - those like yourself that use our tooling just to lint their codebases.
2. developers - those that use all of those other packages in some way to build things.

For us maintainers - they're all just users! Again it's much easier to say to the developers "use scope-manager vX.Y.Z with utils version vX.Y.Z and typescript-estree version vX.Y.Z" rather than prescribing multiple version numbers.

These developer users are often the ones that need the most help as well because there can be up to 8 of our packages in their dependency list! They're the ones that see the most value out of this system, TBH!

[JamesHenry]

We won't be publishing packages when none of the packages change very soon I promise, I am working on it.

But if any one of the packages changes, we will publish a new version of all packages. The pros far outweigh the cons as Brad says

[JamesHenry]

I'd prefer to keep this open @iebold as this is still a change to our release flow that I will be making and addresses the bulk of the confusion IMO

[JamesHenry]

This has now been resolved, we will no longer publish a new version of the packages on a Monday if nothing has changed across all packages since the last release 🎉