chore(gatsby-recipes): bundle dependencies

[pieh]

This PR bundles quite a bit of dependencies which cause problems for users (react, @mdx-js/*) when there are multiple version of those installed in node_modules hierarchy is not quite right

Closes #27278

---

This is part of PR series:

1. feat(gatsby-dev-cli): install deps if there are no gatsby deps but --forceInstall was used
2. test(integration/gatsby-cli): use sandboxed directory to "globally" install gatsby-cli
3. chore(gatsby-recipes): bundle dependencies (THIS PR)
4. chore(gatsby-cli): bundle dependencies

[ch17886]

[gatsby-cloud]

Gatsby Cloud Build Report

gatsby

🎉 Your build was successful! See the Deploy preview here.

Build Details

View the build logs here.

🕐 Build time: 21m

[pieh]

Those are additional candidates for bundling - I wasn't sure if those cause problems or not, so for now those are not bundled

[wardpeet]

some small nits

[kitten]

Hiya 👋 I'm just wondering; I did notice that this dependency on urql is getting a little old, so I'm wondering whether anyone on the Recipes team has tried out the newer versions? Also, I'm a little confused about the aim of this PR. I see the problems with MDX above, but a lot of dependencies seem to now selectively either bundled or not bundled at random ✌️ wouldn't it be consequent then to consequently bundle all dependencies that become part of the CLI?

[pieh]

I think I put it in there because of urql's peerDependency on react - if I didn't, then it would resolve to different react version that other things in the recipes cli use, so that caused problems. Please also note that this is CLI react (ink) and not web target to make things more confusing.

Essentially I bundled everything that had any connection to react here as that was causing problems with react version provided by user (but as mention in description - this is special case for the way npm install dependencies, we really shouldn't need to do it (and I rather not do this and let package manager properly resolve node_modules hierarchy, but that's not the reality unfortunately). So this is workaround on npm quirk, rather than problem with the way we, or deps we bundled are setup).

Few of "tickets" that are about similar issues with npm:

• https://npm.community/t/packages-with-peerdependencies-are-incorrectly-hoisted/4794
• https://npm.community/t/unmet-peerdependency-but-its-listed-as-a-dependency/5322

Even if those got fixed in recent npm version (didn't try), unfortunately our users will also use older versions (like those autoinstalled with Node itself)

As for bundling everything: I did want to limit the scope of bundling to those packages that cause the problems for users (again due to npm quirk, and NOT because packages themselves are problematic). Those that didn't cause (known) problem I did leave as they were - there is some value in not bundling more than needed in node, because there is less duplication as shared packages can be parsed/executed just once (i.e. I explicitly mentioned potential candidates for bundling that I left out not bundled here in #27057 (comment) )

[pieh]

I did notice that this dependency on urql is getting a little old

From what I can latest of urql is 1.11.2, so this should be covered by that version range - but granted, because we do bundle urql now, we will use version that we have specified in lock file

[kitten]

That makes sense! The first impression I got was that some packages seemed related to the UI but aren't bundled, which seems a little odd at first.