Open imcotton opened 2 months ago
Hi @imcotton
Supporting JSR is great. But there are some reasons I can't do it now:
Changesets.
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:
jsr.json
filedeno publish
or npx jsr publish
right after the npm publish
on its CIMaintenance 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.
+1 For JSR support. I really like the idea of not using npm at all in my deno project.
+1 too. Would be nice to have the @hono/zod-validator
package on there.
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.
From the Hono document:
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?