fix: Update dependency @rollup/pluginutils to ^5.0.1

[meyfa]

Rollup Plugin Name: (too many to list)

This PR contains:

• bugfix
• feature
• refactor
• documentation
• other (dependency update)

Are tests included?

• yes (bugfixes and features will not be merged without tests)
• no

Breaking Changes?

• yes (breaking changes will not be merged unless absolutely necessary)
• no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers: #1315

Description

pluginutils version 4 has a missing production dependency on @types/estree, which manifested itself in issue #1315. pluginutils v5.0.1 is now released that fixes this problem (via #1320). This patch updates all plugins that depend on pluginutils to use the fixed version.

[meyfa]

CC @lukastaegert, since you reviewed #1320, would you also look at this, please? I think it is required to fully resolve #1315.

[lukastaegert]

cc @shellscape if it is possible to trigger a release across half the repo with a single commit, and how to format the commit messages. I do not dare trigger merge on this one without your feedback, but the changes look fine to me.

[lukastaegert]

There are some build failures across the repo that need some looking into

[meyfa]

Only Babel tests seem to fail. Unfortunately, I can't fathom how this would have broken them. Does anyone know why?

[lukastaegert]

That would need some debugging. In first approximation, why not revert the Babel changes.

[meyfa]

Done, and tests pass. Seems a bit sad to leave babel outdated but I don't have time to track this down right now :(

[lukastaegert]

Ok, so the release script did not release anything because it requires a separate commit for every package. So I guess we either need to create a separate PR for every single package, or create a PR with a separate commit for every package (with the pattern fix(pluginname): Update dependency @rollup/pluginutils to ^5.0.1) and then temporarily turn of squash merging in favor of a fast-forward merge.
And you need to make some arbitrary change for every commit...
Not me, not today.

But at least the next release will contain the change, even though it will not show up in the changelog.

[lukastaegert]

Ok, I reverted the commit to master and put it into a separate branch to disect later

[meyfa]

Oh, that's unfortunate. At least now we know. I have some time available right now to work on this. Would you like me to make a bunch of PRs or one PR with many commits, or do you want to deal with it some other way?

Also, it seems like the babel problem is now happening on the master branch?

[lukastaegert]

Yes, but I actually fixed it on your branch. I also took the liberty to update all other Rollup-related dependencies on your branch, just look at the latest changes (but I also created the update-pluginutils branch in the Rollup repo to conserve the changes).

I have some time available right now to work on this

That would be amazing

one PR with many commits

One PR with many commits it should be, then it does not matter if the lock file is inconsistent between commits as long as it is fine after the last one. But make sure that commit messages follow this

fix(pluginname): description

pattern, that is what the release job scans for. Then I just need to make sure I preserve commits when merging the PR. If you want to put central changes into its own commit, call it chore(repo): description and maybe make it the first one.

[meyfa]

The followup PR is at #1326.