Add SolidJS integration

[stefanmaric]

This is an attempt to fix the setup issues encountered by @Nvos on #3327

[changeset-bot]

🦋 Changeset detected

Latest commit: 97601bc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@urql/solid	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[XiNiHa]

Are there any blockers for reviewing and merging the PR? I was also interested in creating the Solid integration and found this PR waiting reviews for months 😢 I'm open to both code contributing and experimenting in a real project (I guess it'll be more convenient to try this if we have pkg.pr.new set up?)

[JoviDeCroock]

The main issue with this PR is what is described, it requires so many changes to our workspace setup. I'll try to free up time to look at alternatives/... but it comes down to the same thing as when I initially tried to get solid setup, the testing story in solid seems lacking.

[XiNiHa]

Since it looks like it's the JSX transform that causes the issue, how about using tagged template literals or HyperScript API instead of JSX? They exist for supporting no-build scenarios and I think it matches pretty well with what we want 🤔

[JoviDeCroock]

@XiNiHa do you want to pick that up? Reviving #3327 with either of those two solutions

[XiNiHa]

Sure! I'll make a PR shortly 😋

[XiNiHa]

Well I got blocked by some issues:

• Both tagged template literals and HyperScript wrappers are broken 🤦‍♂️ so it'll be the only way to put precompiled code directly in the test code if we really want to have no-build
• Solid Testing Library requires JSDOM environments to run, and this breaks one of the current persistent exchange tests in the repo
  • Using JSDOM everywhere will also harm performance and make SSR tests unreliable
• Solid requires resolve.conditions in the Vite config to be set as ["development", "browser"] at least and this breaks Preact Testing Library 😵‍💫

After going through these, I just felt that it's natural to have different test environments for each package, as they could run on entirely different environments. Imagine supporting React Server components and bringing all the bundling stuffs; maybe breaking up the config would be the only option there. So I'd like to suggest to go with what we have in this PR, and make it as an opportunity to microtune each test environment per package to reflect the actual environment the package would run. Thoughts?

[JoviDeCroock]

@XiNiHa I'll merge this branch as is and we can look at vitest workspaces as an optimisation to reduce the configs