urql-graphql
Add SolidJS integration
This is an attempt to fix the setup issues encountered by @Nvos on https://github.com/urql-graphql/urql/pull/3327
🦋 Changeset detected
Latest commit: 97601bc2ae749fc4c5e1be8811d9db1f9c8dadb6
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
![changeset-bot[bot] avatar](https://avatars.githubusercontent.com/in/28616?v=4 "Published by a pub.dev verified publisher"){kind=small}
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?)
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.
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 🤔
@XiNiHa do you want to pick that up? Reviving https://github.com/urql-graphql/urql/pull/3327 with either of those two solutions
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.conditionsin 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?
@XiNiHa I'll merge this branch as is and we can look at vitest workspaces as an optimisation to reduce the configs