feat: JSR compatibility #628
Conversation
|
Should I add a |
| @@ -1,4 +1,5 @@ | |||
| import { type Update } from "../types.ts"; | |||
| import { Buffer } from "node:buffer"; | |||
There was a problem hiding this comment.
This change is forcing us to upgrade the @types/node version to the ^16.20.2.
Should we do it?
There was a problem hiding this comment.
We are going to require at least Node 20, but probably rather an even more recent version. You can do this in the same PQ or it can also be done separately if you prefer.
There was a problem hiding this comment.
I think it is enough to depend on Node.js v20 because its maintenance period will have ended in April 2026. It is a lot of time.
It might be required we type-check certain code using type definitions defined in |
| import { | ||
| type ApiClientOptions, | ||
| type WebhookReplyEnvelope, | ||
| } from "./core/client.ts"; | ||
| import type { ApiClientOptions, WebhookReplyEnvelope } from "./core/client.ts"; |
There was a problem hiding this comment.
Does JSR require us to have separate import statements?
There was a problem hiding this comment.
It is not a JSR requirement, but a Deno one.
| @@ -965,7 +983,7 @@ export class Context implements RenamedUpdate { | |||
| text: string, | |||
| other?: Other<"sendMessage", "chat_id" | "text">, | |||
| signal?: AbortSignal, | |||
| ) { | |||
| ): Promise<ReturnType<ApiMethods["sendMessage"]>> { | |||
There was a problem hiding this comment.
We should introduce and export a new type alias for this, but this can be done later. You can keep it this way for now.
It seems so. It works on the |
| @@ -119,6 +135,222 @@ function inputMessageMethods<R extends InlineQueryResult>( | |||
| }; | |||
| } | |||
|
|
|||
| interface InlineQueryResultBuilder { | |||
There was a problem hiding this comment.
Can we get rid of the redundancy by doing it via typeof and the existing const? I am not sure how well JSR does this yet
There was a problem hiding this comment.
I don't quite understand it. What type will we typeof?
| @@ -36,6 +36,39 @@ type InlineQueryResultOptions<T, K extends keyof T> = Omit< | |||
| type OptionalKeys<T> = { [K in keyof T]-?: undefined extends T[K] ? K : never }; | |||
| type OptionalFields<T> = Pick<T, OptionalKeys<T>[keyof T]>; | |||
|
|
|||
| interface InputMessageMethods<R extends InlineQueryResult> { | |||
| getUpdates( | ||
| other?: Other<R, "getUpdates">, | ||
| signal?: AbortSignal, | ||
| ): Promise<ReturnType<ApiMethods["getUpdates"]>> { |
There was a problem hiding this comment.
Same thing as for the context object (but it naturally has to be a different type)
| @@ -2,7 +2,7 @@ | |||
| export const isDeno = typeof Deno !== "undefined"; | |||
|
|
|||
| // === Export debug | |||
| import debug from "https://cdn.skypack.dev/[email protected]"; | |||
| import debug from "npm:[email protected]"; | |||
With this PR, we are starting to work on migrating grammY and its ecosystem to the JSR registry.
Specifically, this PR resolves some of the type issues that arise due to JSR's restrictions.
Please review all changes carefully and test them on your bots.
In general, these changes shouldn't affect the logic of grammY, but it's worth making sure.
For example, the evaluation result has been improved from 47% to 76% (see screenshot).
Also, according to JSR, this should have improved the speed of code compilation.
The remaining scores are related to the package documentation.
This is just the beginning of the work.
In general, the migration to JSR should be fully completed with the release of grammY 2.0.
The second version will solve many of the existing problems, as well as move the code from a platform-specific approach to code compilation to capability-driven code behaviour.
This will allow us to fully rely on JSR to support multiple platforms.
You can test the build locally.
To do this, first run JSR on your machine as instructed.
Then publish the grammY package using
JSR_URL=http://jsr.test deno publish.The package will be available at http://jsr.test/@grammyjs/grammy, and the NPM build at http://npm.jsr.test/@jsr/grammyjs__grammy.
In the metafile of the NPM build, you can find a link to an archive that you can download and unzip to view its contents.
Such a build is suitable for publishing to NPM, except that it needs to be edited and repackaged a bit.