feat(presets): include Astro adapters in astro monorepo

[serhalp]

Changes

This adds the missing Astro adapters monorepo packages to the astro group.

Context

The astro group only include the core Astro monorepo. It is missing the Astro adapters monorepo, which includes packages like @astrojs/node, @astrojs/cloudflare, etc. These should be grouped together with Astro core dependencies.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

Do they have the same versions as the main Astro monorepo?

[serhalp]

Do they have the same versions as the main Astro monorepo?

No, the various withastro/astro monorepo packages and the various withastro/adapters monorepo packages all have separate versioning.

Why do you ask?

[viceice]

are they published with same versions? if not then this PR will make PRs immortal which we don't like

[rarkins]

Monorepo rules are form packages which must be upgraded together or either PR will break if they are separate PRs

[serhalp]

🤔 Interesting. I don't quite understand the definition here. It seems quite fuzzy to me. Is there a documented definition or philosophy somewhere?

I see dozens of currently defined monorepo groups here that contain packages that can be upgraded independently, based on most reasonable definitions in my head.

Is the intent for the packages in a monorepo group perhaps one of the following?

1. all their versions must be identical; otherwise, usage is guaranteed to misbehave (e.g. a blocking build error, app runtime error)
2. per the packages' documentation (or common sense?), all their versions must be identical; otherwise this is considered "undefined behaviour"
3. all their versions must match the same major; otherwise, usage is guaranteed to misbehave (e.g. a blocking build error, app runtime error)
4. per the packages' documentation (or common sense?), all their versions must match the same major; otherwise this is considered "undefined behaviour"
5. upgrading all their versions together (regardless of what "upgrading" means in the context of a given Renovate PR) is generally considered reasonable and convenient by its users, and it is what they would generally do if they were upgrading manually
6. something else?

It sounds like you're talking about either definition 1 or 2, but I can't think of any packages that would meet this definition.

All the packages I'm familiar with that are currently in the monorepo groups list would meet (if I'm not mistaken) definition 3 or 4. These seem like fairly reasonable definitions to me at first glance.

I think I'm leaning toward definition 5. When I try to think through all the variations out there (collections of unrelated utils like @lodash/*; sub-packages of a greater entity that should obviously be synced to the same major at least like @angular/* or @babel/*; one or more core packages plus one or more 'plugin'-style packages like @remix-run/*; and everything in the spectrum in between these...) I find this definition strikes the best balance.

Happy to move this into an issue or discussion if this is an open question!