Also publish to JSR?

[imcotton]

From the Hono document:

If you want to use Third-party Middleware with the TypeScript Type inferences, you need to use the npm: specifier. ^deno

For package like npm:@hono/valibot-validator, this holding my back from using Hono from JSR by:

• jsr:@hono/hono
• jsr:@valibot/valibot

Any plans to have middleware packages also available on JSR too?

[yusukebe]

Hi @imcotton

Supporting JSR is great. But there are some reasons I can't do it now:

• Making them support JSR will be hard. Especially removing slow types.
• Have to create deploy flow. I'm unsure if we can create a good flow to publicize them with Changesets.
• Maintenance costs will be increased. We(almost I) must also check the JSR things by adding npm packages.

[imcotton]

I think slow types is OK-ish for just publish with --allow-slow-types if it cost too much of effort.

Flow-wise, I think it'd be done by:

• having one corresponding jsr.json file
• add deno publish or npx jsr publish right after the npm publish on its CI

Maintenance indeed increased, but if I'm not missing anything else, above only be one time setup per package and then automatically carried afterwards.

Not sure the jsr:@hono/* is the intended place to publish these middleware, but right now it rather empty since only hosting the jsr:@hono/hono and nothing else.

I understand this is low priority and still up to decisions, in the meantime I could vendor the TypeScript source code by coping into my own project, but thought it worth to brought up to discussion, thanks for the participation.

[ingokpp]

+1 For JSR support. I really like the idea of not using npm at all in my deno project.

[mintydev789]

+1 too. Would be nice to have the @hono/zod-validator package on there.

[azohra]

Took me longer than I care to admit to figure out these were not on JSR and that I had to use NPM. I am a newer Deno user and I can absolutely appreciate it may not be worth the effort to cross-publish.

My small ask would be if updating the docs to indicate that the 3rd party portions are only available on NPM. Happy to make a PR if this would be a desired outcome.

[riderx]

My type is broken because it uses 2 different types apparently, and I think it's linked to this: It's important to have all in JSR if you need support for this my company can found it

[sant123]

It would be nice to have this repo published on JSR 🙏🏼

[NuroDev]

+1 too. Would be nice to have the @hono/zod-validator package on there.

Big +1 to this. Currently if you try to use jsr:@hono/hono with npm:@hono/zod-validator it doesn't work because the env types clash.

I would guess if / when the day comes that Zod gets published to JSR (colinhacks/zod#3506) there may be more of an incentive to also publish @hono/zod-validator as well.

[yusukebe]

I've set up the flow to publish the package to JSR on honojs/hono repo. But currently, I'm not sure how we can do that in this "monorepo".

Hey @BarryThePenguin! Do you have time to work on this? We have to consider it if it's difficult to set up or maintain.

[BarryThePenguin]

Sure thing, I haven't spent much time with deno or JSR but I'm happy to take a look 👀

https://jsr.io/docs/publishing-packages

[NuroDev]

If it is of any help, I created the following GitHub action in another project to deploy to JSR in a "monorepo" style structure. Entirely opt-in for each package you want to publish.

name: Publish

on:
  push:
    branches:
      - main

concurrency: ${{ github.workflow }}-${{ github.ref }}

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write # The OIDC ID token is used for authentication with JSR.
    strategy:
      fail-fast: false
      matrix:
        package: []
    steps:
      - name: Clone repository
        uses: actions/checkout@v4

      - name: Publish to JSR
        run: npx jsr publish
        working-directory: ./packages/${{ matrix.package }}

[BarryThePenguin]

To deal with JSR "slow types", I'll enable isolatedDeclarations in the workspaces that it's easy to do so.

If you are using TypeScript with isolatedDeclarations, your code is already compliant with the “no slow types” policy of JSR. However, you may still need to make some changes to your code to comply with the other restrictions of JSR, such as not using module augmentation or global augmentation.

[BarryThePenguin]

One issue I've run into is JSR doesn't allow typescript that uses module and global augmentation

Module augmentation and global augmentation must not be used. This means that packages cannot use declare global, declare module, or export as namespace to augment the global scope or other modules.

TypeScript restrictions

So it sounds like we can't publish packages that use declare module 'hono' to augment ContextVariableMap, ContextRenderer, etc.

This includes:

• @hono/auth-js
• @hono/clerk-auth
• @hono/cloudflare-access
• @hono/oauth-providers
• @hono/oidc-auth
• @hono/react-renderer
• @hono/sentry
• @hono/tsyringe

[yusukebe]

@BarryThePenguin Thank you for the hard work.

Regarding it will not be able to use declare module 'hono', I think exploring each variable type and user use it by manually importing it and adding it to the generics of Hono.

import { SentryVariables } from '@hono/sentry'

type MyVariables = {}

const app = new Hono<{
  Variables: MyVariables & SentryVariables
}>()

[yusukebe]

Now, some package on the JSR!

For example, the combination of @hono/hono and @hono/zod-validator does not throw a type error!

Great work @BarryThePenguin !

[imcotton]

Thanks for making this happen. I really appreciate all the effort that went into it.

I noticed that jsr:@hono/valibot-validator currently depends on npm:valibot. Would it be possible to switch the dependency to jsr:@valibot/valibot instead? In addition as changes of PR 1277?

[BarryThePenguin]

I've created PR to make that change 👍🏻

[knotbin]

Incredible work @BarryThePenguin! I'll be honest I was scrolling through this PR fully expecting it to have been closed as stale and was so pleasantly surprised to see it had been done!

@yusukebe this is mostly unimportant and a nitpick but if you have the time could you go through the new packages or the most used ones and add simple metadata like a description and compatible runtimes to increase the JSR Scores and show the packages are compatible with all runtimes?

[yusukebe]

@knotbin

Done!

[knotbin]

Wow thank you so much! Could you also archive the "do-not-use-this" package or do you still use that for testing?

[yusukebe]

Could you also archive the "do-not-use-this" package or do you still use that for testing?

Ah, it's not needed now. I've archived it.