Canary test workflow, checks that key downstream packages still build

[ChristianMurphy]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)
• If applicable, I’ve added docs and tests

Description of changes

Follow up to: unifiedjs/ideas#7

Unified is a large and highly connected community of packages.
Changes to any package could have impact downstream packages.
Currently anticipating impact is a purely manual process.

It could be helpful to use downstream packages, which themselves have comprehensive test suites, to help automatically detect what changes may be breaking or have unintended impacts.

This aims to help alleviate some of that risk by choosing a few key packages.

• mdast-util-from-markdown
• remark
• react-markdown

which build on this, and have heavy usage, and comprehensive test suites, to anticipate potential downstream issues faster.

[wooorm]

Fixing the CI failure is most important, otherwise, good idea!

[wooorm]

Perhaps something to not run this on every PR? Similar to that “T-Shaped” model from MDX?

[ChristianMurphy]

Perhaps something to not run this on every PR?

I think there would be value in running this on every PR, seeing if code changes impact upstream.
And even if changes aren't code related, it can be an early warning for unrelated upstream issues.
This set of checks itself probably wouldn't be blocking for PRs.

Similar to that “T-Shaped” model from MDX?

There the T-Shaped model has to do with the matrix of jobs run, not when it is run, right?
I did drop windows from the matrix for now, because it appears most upstream projects do not test on Windows.
Which (may) eliminate the need to a T-Shaped model.

[wooorm]

Looking at the, how do you call this, build preview, it looks chaotic imo.

• Could the canary/* stuff be ordered after main/*?
• canary / testing / $user/$project -> canary-in-the-gold-mine / $package or citgm / $package maybe?

[ChristianMurphy]

Could the canary/* stuff be ordered after main/*?

I'm not sure if it can.
The order appears to be non-alphabetical.

canary / testing / $user/$project -> canary-in-the-gold-mine / $package or citgm / $package maybe?

Happy to rename things if wanted, I'm not sure it will fix the order issue though.

[wooorm]

I'm not sure if it can. The order appears to be non-alphabetical.

Yeah, though, taking MDX as an example: mdx-js/mdx#1854, it seems to indicate that different YAML files result in unordered, but when inside the same file, it does work?

Happy to rename things if wanted, I'm not sure it will fix the order issue though.

I meant the points separately. I guess $packageName doesn’t make sense though, but $user/$project does, as this seems to be more about the repo rather the npm package?

[ChristianMurphy]

but when inside the same file, it does work?

Moved canary job into main.yml

as this seems to be more about the repo rather the npm package?

it is more about the repositories, updated naming to better reflect this