feat(jsr): support JSR #2662

yusukebe · 2024-05-12T01:04:12Z

This PR will enable Hono to support the JSR.

We've done:

Added type annotations to reduce Slow Types. perf(types): add type annotations #2663
I added the jsr-dry-run command in CI to check if it's ready to publish JSR. 8b24707
Added deno.json. 7ac6306 And modified.
Made JSX be exported from hono/jsx/jsx-runtime not global. 5bd2b71
Made hono-base.ts does not use dynamicClass. b902590
Made ExecutionContext is not declared in global. cf020c6
Removed deno_dist and denoify completely. 0c776fa
Made deno.json exports ./, ./jsx/jsx-runtime, ~~./middleware, and ./helper~~.
Made deno.json exports each helper, middleware, and adapter following @nakasyou's comment. 90892be

Usage

Currently, we are uploading Hono as @hono/do-not-use-this on the JSR.

deno add @hono/do-not-use-this

You don't use it, but you can use it for experimental purposes.

We will support both npm and JSR

Though this PR will merged and Hono supports JSR, we don't stop supporting the npm. I'm thinking we can do it with the following publishing steps:

Publish the npm package with the np command on my local machine.
The new commit and tag will be pushed to this repo.
If the tag is created, the GitHub Action will execute and release the new version of the JSR package to the JSR. Can we do it with this? https://github.com/dsherret/jsr-publish-on-tag

Differences between npm package

It can't use declare global if it will be published in JSR. So you can't use ContextVariableMap. Instead, you can use the Variables type exported from the middleware.

import { Hono } from '@hono/hono'
import { jwt } from '@hono/hono/jwt'
import type { JwtVariables } from '@hono/hono/jwt'

type Env = {
  Variables: JwtVariables
}

const app = new Hono<Env>()

Goodbye Denoify

We have to say Goodbye to Deonify if this PR is merged.

We were using it heavily to support publishing Hono on deno.land/x. But with this PR, it's not necessary because the --unstable-sloppy-imports option can be used. I've removed the deno_dist directory completely.

Thanks Denoify.

TODO

Review the PR.
Add a GitHub action to release it to the JSR if the new tag is created. Can we use this? https://github.com/dsherret/jsr-publish-on-tag e91d92e
Publish the RC versions and try them in the real world. => later
Add module docs in the source. => later
Update website docs. => later
Add badges for the JSR. => later
Update jsr.json to prepare publishing.

* feat(jsr): reduce slow types * fix: use allow function * chore: format code * chore: denoify

nakasyou · 2024-05-12T11:45:25Z

I think that JSR can instead npm registry, also it's not only for Deno.
JSR users use JSR with runtimes such as Node.js, Bun, CF Workers and Browsers, not limited Deno. So instead of merging it like the traditional middleware.ts, I recommend to exports detailed name such as ./jwt, ./timing, ./logger and etc...

In the same way, we should not export only Deno adapter like serve-static middleware. I think that exporting all runtime adapter like current package.json is good.

yusukebe · 2024-05-12T12:05:46Z

Thanks for the comment @nakasyou !

It makes sense. I'll do it now.

KnorpelSenf · 2024-05-12T13:33:58Z

@yusukebe are you going to publish dually to both npm and JSR? How are you planning on doing the build step?

Context: I am myself maintaining a library for Telegram bots (https://github.com/grammyjs) and we're planning on switching over to JSR, as well, but we are not ready to ditch npm entirely. We are discussing several strategies at the moment in grammyjs/grammY#559 and I'm curious what your take on registry support is. (Side-note: there's actually a grammY-hono integration.)

yusukebe · 2024-05-12T13:58:18Z

Hi @KnorpelSenf

Yes. Both npm and JSR. Exactly, it's important to make the publishing steps. I've updated the description of this PR, please read it.

yusukebe · 2024-05-12T14:01:55Z

Hey @nakasyou @usualoma @ryuapp @watany-dev and others!

Please see this PR. We don't need a detailed review at first. I want to know if this approach is the right one. I would also like you to use the package @hono/do-not-use-this because it is already available.

usualoma · 2024-05-13T00:38:13Z

Great nice work! I am fine with this approach.

usualoma · 2024-05-13T03:23:36Z

Oh, one comment.

I think SuperClass should be invisible to the user.

I think it would be better to simply define it as a property in Hono itself.

diff --git a/src/hono-base.ts b/src/hono-base.ts
index f15ee2fd..47e8a053 100644
--- a/src/hono-base.ts
+++ b/src/hono-base.ts
@@ -76,28 +76,22 @@ export type HonoOptions<E extends Env> = {
   getPath?: GetPath<E>
 }
 
-abstract class SuperClass<
-  E extends Env = Env,
-  S extends Schema = {},
-  BasePath extends string = '/'
-> {
-  // The implementations of these methods are fake.
-  get: HandlerInterface<E, 'get', S, BasePath> = () => new Hono<any>()
-  post: HandlerInterface<E, 'post', S, BasePath> = () => new Hono<any>()
-  put: HandlerInterface<E, 'put', S, BasePath> = () => new Hono<any>()
-  delete: HandlerInterface<E, 'delete', S, BasePath> = () => new Hono<any>()
-  options: HandlerInterface<E, 'options', S, BasePath> = () => new Hono<any>()
-  patch: HandlerInterface<E, 'patch', S, BasePath> = () => new Hono<any>()
-  all: HandlerInterface<E, 'all', S, BasePath> = () => new Hono<any>()
-  on: OnHandlerInterface<E, S, BasePath> = () => new Hono<any>()
-  use: MiddlewareHandlerInterface<E, S, BasePath> = () => new Hono<any>()
-}
-
 class Hono<
   E extends Env = Env,
   S extends Schema = {},
   BasePath extends string = '/'
-> extends SuperClass<E, S, BasePath> {
+> {
+  // Theses methods are dynamically initialized in the constructor.
+  get!: HandlerInterface<E, 'get', S, BasePath>
+  post!: HandlerInterface<E, 'post', S, BasePath>
+  put!: HandlerInterface<E, 'put', S, BasePath>
+  delete!: HandlerInterface<E, 'delete', S, BasePath>
+  options!: HandlerInterface<E, 'options', S, BasePath>
+  patch!: HandlerInterface<E, 'patch', S, BasePath>
+  all!: HandlerInterface<E, 'all', S, BasePath>
+  on: OnHandlerInterface<E, S, BasePath>
+  use: MiddlewareHandlerInterface<E, S, BasePath>
+
   /*
     This class is like an abstract class and does not have a router.
     To use it, inherit the class and implement router in the constructor.
@@ -111,8 +105,6 @@ class Hono<
   routes: RouterRoute[] = []
 
   constructor(options: HonoOptions<E> = {}) {
-    super()
-
     // Implementation of app.get(...handlers[]) or app.get(path, ...handlers[])
     const allMethods = [...METHODS, METHOD_NAME_ALL_LOWERCASE]
     allMethods.forEach((method) => {

imcotton · 2024-05-13T07:33:07Z

The pkg naming jsr:@hono/hono seemed repetitive, does alternative like jsr:@hono/core on the table?

nakasyou · 2024-05-13T08:50:46Z

The pkg naming jsr:@hono/hono seemed repetitive, does alternative like jsr:@hono/core on the table?

I don't have any opinion, but in reference, Oak uses @oak/oak.

imcotton · 2024-05-13T09:41:06Z

That's fair, and it is absolutely non-critical, just brought to attention.

* feat(jsr): remove helper.ts and middleware.ts * fix: fix test

usualoma · 2024-05-22T21:04:43Z

Thanks for the great results.
I think it's good!

kt3k · 2024-05-23T02:26:27Z

Hi @yusukebe. Thanks for working on this!

I also tried @hono/do-not-use-this. The hello world server started without issue on my end. example repo: https://github.com/kt3k/hono-jsr-test

One thing I noticed is that the route context variable doesn't look typed correctly with @hono/do-not-use-this:

The same variable looks typed more accurately when I import Hono from deno.land/x/:

yusukebe · 2024-05-23T02:35:37Z

Hi @kt3k !

Thanks! In my environment, it is typed correctly:

Maybe the cache or something makes it bad?

kt3k · 2024-05-23T03:51:34Z

I was able to fix the issue if I changed the version to 0.0.6, but I still see the same issue with 0.0.7. I'll take a look in more details later.

usualoma · 2024-05-23T04:09:32Z

Actually, I confirmed the same site as @kt3k , although I skipped it because I thought it was an issue dependent on my environment, since I could no longer reproduce it at hand.

After adding one line, import type { HandlerInterface } from '@hono/do-not-use-this/types' , the problem went away and has not occurred since. And no matter how I try, I can't reproduce it.

kt3k · 2024-05-23T04:25:18Z

Oh, adding import type { HandlerInterface } from "jsr:@hono/[email protected]/types"; resolved the issue for me, and if the issue once resolved, it doesn't reproduce even if I removed that workaround..

(BTW if I restart the language server from the command palette of VS Code (selecting Deno: Restart Language Server), then I can still reproduce it)

yusukebe · 2024-05-23T04:41:21Z

Hi @usualoma @kt3k

I've modified some and uploaded 0.0.8. Could you try it and let me know the result?

kt3k · 2024-05-23T04:55:46Z

Tested with 0.0.8. I still see the issue only after hitting Deno: Restart Language Server command, but if I changed anything in the file, that error disappears. I feel this is minor enough issue and probably can be ignored?

usualoma · 2024-05-23T05:52:35Z

I updated to 0.0.8 and types.ts was again unreadable in my environment. Then I added a line and explicitly loaded it and it was resolved again. I have a Deno: Restart Language Server that is unreproducible; after adding one line, I can never reproduce it again. The problem may not be caused by hono, but by Deno's language server.

kt3k · 2024-05-23T06:39:10Z

The problem may not be caused by hono, but by Deno's language server.

Sounds true to me. If I check the script with deno check command, then the context object is correctly typed. Looks like deno lsp issue to me.

yusukebe · 2024-05-23T06:46:11Z

@usualoma @kt3k

Thank you very much! I think we should go with this.

P.S. The DX for using JSR is good! There is no need to build, it is easy to publish, and the docs are generated automatically. These are great!

yusukebe · 2024-05-24T08:47:07Z

The time has come. Let's land it!

yusukebe · 2024-05-24T09:17:33Z

Publishing the RC version to JSR is a success! You can use @hono/hono by editing the deno.json:

{
  "imports": {
    "@hono/hono": "jsr:@hono/[email protected]"
  }
}

main.ts:

import { Hono } from '@hono/hono'

const app = new Hono()

app.get('/', (c) => {
  return c.text('Hello JSR!')
})

export default app

riderx · 2024-06-05T00:22:52Z

Hello I'm trying to migrate from Denoland to JSR, here is my code (I publish the same code in Deno, Node.js and Cloudflare workers)

import { env, getRuntimeKey } from 'hono/adapter'
import type { Context } from 'hono'

export function existInEnv(c: Context, key: string): boolean {
  return key in env(c)
}

export function getEnv(c: Context, key: string): string {
  if (key in env(c))
    return env(c)[key] ?? ''
  return ''
}

The error i get:

error: TS2345 [ERROR]: Argument of type 'import("https://jsr.io/@hono/hono/4.4.2/src/context.ts").Context<any, any, {}>' is not assignable to parameter of type 'import("file:///Users/martindonadieu/Documents/Projects.tmp/capgo/capgo-app/node_modules/.deno/[email protected]/node_modules/hono/dist/types/context.d.ts").Context<any, any, {}>'.
  Property '#private' in type 'Context' refers to a different member that cannot be accessed from within type 'Context'.
  return key in env(c)
                    ^
    at file:///Users/martindonadieu/Documents/Projects.tmp/capgo/capgo-app/supabase/functions/_backend/utils/utils.ts:100:21

TS2345 [ERROR]: Argument of type 'import("https://jsr.io/@hono/hono/4.4.2/src/context.ts").Context<any, any, {}>' is not assignable to parameter of type 'import("file:///Users/martindonadieu/Documents/Projects.tmp/capgo/capgo-app/node_modules/.deno/[email protected]/node_modules/hono/dist/types/context.d.ts").Context<any, any, {}>'.
  if (key in env(c))
                 ^
    at file:///Users/martindonadieu/Documents/Projects.tmp/capgo/capgo-app/supabase/functions/_backend/utils/utils.ts:104:18

TS2345 [ERROR]: Argument of type 'import("https://jsr.io/@hono/hono/4.4.2/src/context.ts").Context<any, any, {}>' is not assignable to parameter of type 'import("file:///Users/martindonadieu/Documents/Projects.tmp/capgo/capgo-app/node_modules/.deno/[email protected]/node_modules/hono/dist/types/context.d.ts").Context<any, any, {}>'.
    return env(c)[key] ?? ''
               ^
    at file:///Users/martindonadieu/Documents/Projects.tmp/capgo/capgo-app/supabase/functions/_backend/utils/utils.ts:105:16

Found 3 errors.

In the doc I see c.env() is obsolete. Use getRuntimeKey() but I don't understand, both functions do very different things.
My import map changed:

So i'm not sure how to migrate, on the doc website there is no mention of deprecation of env()

yusukebe · 2024-06-05T00:35:07Z

Hi @riderx

@hono/sentry is not on the JSR. So use npm:@hono/sentry as is. And if it will not be resolved, you can't use mix both npm:@hono/* and jsr:@hono/hono. Please use both npm specifiers.

riderx · 2024-06-05T00:39:18Z

Thanks, sadly the problem is not related to Sentry package, so i changed it and still have the same problem.
It seems related to the Typing.

riderx · 2024-06-05T00:41:24Z

I made a branch if you want to look at it: https://github.com/Cap-go/capgo/tree/migrate_hono
And the file:
https://github.com/Cap-go/capgo/blob/migrate_hono/supabase/functions/_backend/utils/utils.ts

riderx · 2024-06-05T00:45:46Z

I updated my code example to be more precise

yusukebe · 2024-06-05T01:02:26Z

@riderx

I don't know why it will be so, but the there are two hono packages are used in the project. npm: and jsr:

This mismatch causet the problem. I can't find a good way immediately but you can use full URL to solve it:

import { env, getRuntimeKey } from 'jsr:@hono/[email protected]/adapter'
import type { SupabaseClient } from '@supabase/supabase-js'
import type { Context } from 'jsr:@hono/[email protected]'
import type { Database } from './supabase.types.ts'

riderx · 2024-06-05T02:05:14Z

I don't think I can use the JSR prefix, since I'm deploying in 3 envs.
That why I use import map.
But you made me realize one issue, the new import name is @hono/hono and I didn't migrate it so it still used the NPM one for others env.
So I did now the migration and found a way to make it work in Deno, but now the Cloudflare workers doesn't work as the schema used in Deno doesn't work anymore.
So i updated my branch and now my current problem is this:

 ⛅️ wrangler 3.57.2 (update available 3.59.0)
-------------------------------------------------------

✘ [ERROR] Could not resolve "@hono/tiny"

    cloudflare_workers/index.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/http-exception"

    cloudflare_workers/index.ts:5:30:
      5 │ import { HTTPException } from '@hono/http-exception'
        ╵                               ~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@hono/http-exception" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/plugins/channel_self.ts:5:21:
      5 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/plugins/stats.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/plugins/updates.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/config.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/delete_failed_version.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/devices.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/download_link.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/log_as.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/plans.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/public_stats.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/stats.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/store_top.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/stripe_checkout.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/stripe_portal.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/private/upload_link.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/public/bundles.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/public/channel.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/public/devices.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/public/ok.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/clear_app_cache.ts:3:21:
      3 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/clear_device_cache.ts:3:21:
      3 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/cron_clear_versions.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/cron_email.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/cron_plan.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/cron_scrapper.ts:2:21:
      2 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/cron_stats.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/logsnag_insights.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_app_create.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_channel_update.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_organization_create.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_user_create.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_user_delete.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_user_update.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_version_create.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_version_delete.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/on_version_update.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/tiny"

    supabase/functions/_backend/triggers/stripe_event.ts:1:21:
      1 │ import { Hono } from '@hono/tiny'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/tiny" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/utils/buffer"

    supabase/functions/_backend/utils/hono.ts:1:32:
      1 │ import { timingSafeEqual } from '@hono/utils/buffer'
        ╵                                 ~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@hono/utils/buffer" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/http-exception"

    supabase/functions/_backend/utils/hono.ts:3:30:
      3 │ import { HTTPException } from '@hono/http-exception'
        ╵                               ~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@hono/http-exception" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/cors"

    supabase/functions/_backend/utils/hono.ts:4:21:
      4 │ import { cors } from '@hono/cors'
        ╵                      ~~~~~~~~~~~~

  You can mark the path "@hono/cors" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/adapter"

    supabase/functions/_backend/utils/pg.ts:6:30:
      6 │ import { getRuntimeKey } from '@hono/adapter'
        ╵                               ~~~~~~~~~~~~~~~

  You can mark the path "@hono/adapter" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/adapter"

    supabase/functions/_backend/utils/stats.ts:2:30:
      2 │ import { getRuntimeKey } from '@hono/adapter'
        ╵                               ~~~~~~~~~~~~~~~

  You can mark the path "@hono/adapter" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Could not resolve "@hono/adapter"

    supabase/functions/_backend/utils/utils.ts:1:35:
      1 │ import { env, getRuntimeKey } from '@hono/adapter'
        ╵                                    ~~~~~~~~~~~~~~~

  You can mark the path "@hono/adapter" as external to exclude it from the bundle, which will remove this error.


✘ [ERROR] Build failed with 45 errors:

  cloudflare_workers/index.ts:1:21: ERROR: Could not resolve "@hono/tiny"
  cloudflare_workers/index.ts:5:30: ERROR: Could not resolve "@hono/http-exception"
  supabase/functions/_backend/plugins/channel_self.ts:5:21: ERROR: Could not resolve "@hono/tiny"
  supabase/functions/_backend/plugins/stats.ts:1:21: ERROR: Could not resolve "@hono/tiny"
  supabase/functions/_backend/plugins/updates.ts:1:21: ERROR: Could not resolve "@hono/tiny"
  ...


🪵  Logs were written to "/Users/martindonadieu/Library/Preferences/.wrangler/logs/wrangler-2024-06-05_02-03-22_577.log"

Before the import where structured the same on all platforms, so I didn't have the issue

riderx · 2024-06-05T02:24:53Z

@yusukebe thanks a lot I found my way to JSR, here was my required change:

And in import:

And package json:

nakasyou and others added 8 commits May 12, 2024 10:03

feat(jsr): reduce slow types (#2369)

24dde8a

* feat(jsr): reduce slow types * fix: use allow function * chore: format code * chore: denoify

add deno.json

7ac6306

Merge branch 'main' into feat/jsr

376c5ad

add jsr-dry-run command for CI

8b24707

don't put JSX on global

5bd2b71

fix test settings for deno

c45fa0f

don't use dynamicClass

b902590

don't declare ExecutionContext in global

cf020c6

yusukebe force-pushed the feat/jsr branch from e1e8a21 to 82350d9 Compare May 12, 2024 09:32

goodbye denoify

0c776fa

yusukebe force-pushed the feat/jsr branch from 82350d9 to 0c776fa Compare May 12, 2024 11:09

yusukebe added 2 commits May 12, 2024 20:29

exports ./middleware

0ef5bb1

exports ./helper

498c4f2

yusukebe added the v4.4 label May 12, 2024

shevernitskiy mentioned this pull request May 12, 2024

Publish grammY to JSR respository grammyjs/grammY#559

Open

exports each helper and middleware

90892be

yusukebe force-pushed the feat/jsr branch from 1d03dea to 90892be Compare May 12, 2024 13:28

remove the awslambda implementation which is not enough

804f32b

yusukebe marked this pull request as ready for review May 12, 2024 13:55

feat(jsr): remove helper.ts and middleware.ts (#2667)

b8b8e70

* feat(jsr): remove helper.ts and middleware.ts * fix: fix test

yusukebe changed the base branch from main to next May 22, 2024 20:36

yusukebe added 2 commits May 24, 2024 17:41

Merge branch 'next' into feat/jsr

78d9cc5

update jsr.json

9849612

yusukebe merged commit 1b2a4c0 into next May 24, 2024
11 checks passed

yusukebe deleted the feat/jsr branch May 24, 2024 08:47

yusukebe mentioned this pull request May 31, 2024

Support JSR #2201

Closed

This was referenced Jun 9, 2024

NPM->Vercel template has incorrect typings issue wevm/frog#336

Closed

chore: bump hono wevm/frog#354

Merged

YoutacRandS-VA mentioned this pull request Jun 20, 2024

[Snyk] Upgrade hono from 3.12.0 to 4.4.0 YoutacRandS-VA/api-server#1

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(jsr): support JSR #2662

feat(jsr): support JSR #2662

yusukebe commented May 12, 2024 •

edited

Loading

nakasyou commented May 12, 2024

yusukebe commented May 12, 2024

KnorpelSenf commented May 12, 2024

yusukebe commented May 12, 2024

yusukebe commented May 12, 2024

usualoma commented May 13, 2024

usualoma commented May 13, 2024

imcotton commented May 13, 2024 •

edited

Loading

nakasyou commented May 13, 2024 •

edited

Loading

imcotton commented May 13, 2024

usualoma commented May 22, 2024

kt3k commented May 23, 2024

yusukebe commented May 23, 2024

kt3k commented May 23, 2024

usualoma commented May 23, 2024

kt3k commented May 23, 2024 •

edited

Loading

yusukebe commented May 23, 2024

kt3k commented May 23, 2024

usualoma commented May 23, 2024

kt3k commented May 23, 2024

yusukebe commented May 23, 2024

yusukebe commented May 24, 2024

yusukebe commented May 24, 2024

riderx commented Jun 5, 2024 •

edited

Loading

yusukebe commented Jun 5, 2024

riderx commented Jun 5, 2024

riderx commented Jun 5, 2024

riderx commented Jun 5, 2024

yusukebe commented Jun 5, 2024

riderx commented Jun 5, 2024

riderx commented Jun 5, 2024

feat(jsr): support JSR #2662

feat(jsr): support JSR #2662

Conversation

yusukebe commented May 12, 2024 • edited Loading

Usage

We will support both npm and JSR

Differences between npm package

Goodbye Denoify

TODO

nakasyou commented May 12, 2024

yusukebe commented May 12, 2024

KnorpelSenf commented May 12, 2024

yusukebe commented May 12, 2024

yusukebe commented May 12, 2024

usualoma commented May 13, 2024

usualoma commented May 13, 2024

imcotton commented May 13, 2024 • edited Loading

nakasyou commented May 13, 2024 • edited Loading

imcotton commented May 13, 2024

usualoma commented May 22, 2024

kt3k commented May 23, 2024

yusukebe commented May 23, 2024

kt3k commented May 23, 2024

usualoma commented May 23, 2024

kt3k commented May 23, 2024 • edited Loading

yusukebe commented May 23, 2024

kt3k commented May 23, 2024

usualoma commented May 23, 2024

kt3k commented May 23, 2024

yusukebe commented May 23, 2024

yusukebe commented May 24, 2024

yusukebe commented May 24, 2024

riderx commented Jun 5, 2024 • edited Loading

yusukebe commented Jun 5, 2024

riderx commented Jun 5, 2024

riderx commented Jun 5, 2024

riderx commented Jun 5, 2024

yusukebe commented Jun 5, 2024

riderx commented Jun 5, 2024

riderx commented Jun 5, 2024

yusukebe commented May 12, 2024 •

edited

Loading

imcotton commented May 13, 2024 •

edited

Loading

nakasyou commented May 13, 2024 •

edited

Loading

kt3k commented May 23, 2024 •

edited

Loading

riderx commented Jun 5, 2024 •

edited

Loading