chore(workspace): automatically publish urql-core to JSR

[JoviDeCroock]

Summary

This adds a publishing pipeline to jsr, for now it will only publish @urql/core because we have a lot of "slow types" where it doesn't infer from the generic or is implicit. I'd solve these one by one rather than creating one big PR. The PR already adds the infrastructure in each workspace to publish to JSR by means of the jsr.json file. This also adds a new script during versioning where it will bump all the jsr packages.

A point for improvement that I'm considering in scope of this PR is a transformation script for our TS codebase where we transform all the process.env.NODE_ENV to import.meta.env.NODE_ENV or we strip it out. Not doing so will cut out deno support for a while, supporting both Deno as well as Node in JSR would require globalThis.Deno?.env.get("NODE_ENV") || process.env.NODE_ENV. I think with regards to https://github.com/graphql/graphql-js/issues/4075 it might be a good idea to transform our ESM bundles to import.meta.env sometime either way.

Currently we do not support canaries on jsr.

TODO

• [x] add dry run step to the PR so we know when slow types are added
• [x] release the current version by adding it to the PR workflow for a bit

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 2c3a4aee143fd5f39fa82a81129d77708d64109b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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