Add support for JSR

[okikio]

• Adds deno.jsonc files

  let's us take advantage of Deno's support for workspaces, makes publishing easier

• Added allowImportingTsExtensions & noEmit to root tsconfig.json

  JSR requires ts files to use .ts & typescript only allows .ts files if you disable ts emitting files

• Simplified the tsconfig.json for packages, leaving only src & extends in each packages tsconfig.json

  composite: true, references: [], etc... tsconfig options error out when noEmit: true at the root

• Added return types & fix other type errors where possible

  JSR strongly dislikes missing return types & ambient global declaration they count as slow types and to avoid slowing down the end users machine will strongly enforce explicit returns
  I couldn't quite get rid of ambient global declarations but I did use --allow-slow-types as an escape hatch for said packages

• Switch build setup to use tsdown, it covers most of the same usecases as the existing scripts/build.ts

  with noEmit: true on the root tsconfig.json the scripts/build.ts breaks as tsc -b no longer works, so reconfiguring the build script was necessary

• Added jsr gh actions

  I've tested the publish process locally but we'd likely need to test it as part of a CI pipeline tbh

Closes #726

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6cb540f

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

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 582af0a4-ce12-4eb6-9a13-79e8c44ea02d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[thetarnav]

Switch build setup to use tsdown, it covers most of the same usecases as the existing scripts/build.ts

Using tsc -b + esbuild for few jsx transforms from a single script was to have a single build process for building all packages at once.
It makes the build lightweight and fast, ~4s or instant when cached.
Building all ~80 packages with a separate build process for each is very slow and cpu/memory intensive. It makes the ci take minutes instead of seconds.

[okikio]

tsdown does actually support this exact functionality, it's just that I kept running out of memory while using it locally, so I switched to an individual build but workspace builds are actually really fantastic https://tsdown.dev/reference/cli#w-workspace-dir

they are working on fixes to it going full throttle without breaks rolldown/tsdown#940

[thetarnav]

They are still running tsc 80 times.
The build script runs just one.
That's why you are running out of memory when ran in parallel on all threads.
And that's why I tried to move away from individual build steps in favor or a single script in monorepos.
I'm not going to block this or anything, if others prefer jsr support so be it. Personally I just hate it that this is how it works.
It used to be the case with turborepo + tsup that I either ran out of memory or the build took several minutes to complete.
I guess tsgo will reduce it down a bit eventually.

[okikio]

fair, though jsr doesn't require it per-se, it's kinda node that requires it. if only tsc didn't mandate noEmit: true when allowing importing ts this just wouldn't even be a problem 🤷🏽‍♂️

[okikio]

@thetarnav Fantastic news, I figured out a solution. Using isolatedDeclarations in tsconfig.json let's us speed this up by quite a bit, tsdown then basically avoids needing to call tsc at all and can just uses oxc-transformer

[davedbase]

@thetarnav does this full satisfy your concerns? :) if so can I get your blessing?

[thetarnav]

The build takes 16s on ci again so I'm fine with that.
But I'll need to check if the outputs. It's one thing to have build "work" locally and actually work in another project.
Also should the tests be failing?

[thetarnav]

Alright checked locally and it looks good.
But why is the build script tsc -b packages/* && tsdown and not just tsdown?
tsc -b packages/* is not emitting anything because of the noEmit: true so there is no point to even running it.
Just typechecking? It could be a separate script then. A part of linting.

[okikio]

Your original build script did type checking via typescript, tsdown just strips the types. I thought yall had that there because that was part of your linting process. I can remove it if we deem it not necessary, removing tsc -b actually speeds up the builds even further.

[okikio]

I actually misspoke earlier tsdown does type check, so tsc -b really isn't necessary anymore

[okikio]

the builds are now 2x faster