Publish `grammY` to JSR respository

Question

Publish `grammY` to JSR respository

fwqaaq opened this issue 7 months ago · 28 comments

GitHub Action: https://jsr.io/docs/publishing-packages#publishing-from-github-actions
Migrating Deno modules from /x to JSR: https://jsr.io/docs/migrate-x-to-jsr

You can use npm or deno to get packages from JSR.

Answer 1 · 2024-04-10T08:15:54.000Z

This will be done with the entire ecosystem, not just the core library. We have to make sure that things stay consistent and compatible.

This requires a new build infrastructure. We still want to publish everything to npm because as of 2024, that is still the go-to place for Node.js users.

It is currently unclear whether or not we are going to leverage the existing tools we built. We may also want to write a service called jsr2npm that

takes a module from JSR,
downlaods its npm tarball,
rewrites the package name,
repackages the tarball,
consumes a publish token from npm, and
publishes the package to npm.

There are a lot of things to consider here, since people should be able to import grammY

from Deno (in one way or another)
from npm for Node.js
from npm for Vercel, Cloudflare Workers, and others
from npm for Browsers
from GitHub with Deno
from GitHub with npm for Node.js
from GitHub with npm for Vercel, Cloudflare Workers, and others
from GitHub with npm for Browsers
via a URL (JS-only, no types)

and it should all just work with no further setup.

We might have to make the difficult decision to drop support for CJS, but since this commit we might just ship ESM without TLA and require CJS users to pass a flag until it is stable.

Answer 2 · 2024-04-10T08:43:16.000Z

I advocate for writing a custom script that replaces imports with JSR ones, and vendors whatever cannot be replaced.

Answer 3 · 2024-04-10T09:02:30.000Z

Which imports? Do you mean @std?

Answer 4 · 2024-04-10T09:02:47.000Z

This will be done with the entire ecosystem, not just the core library. We have to make sure that things stay consistent and compatible.

Yeah, the support of grammy for ESM is excellent, and JSR provides a very simple way to migrate: https://jsr.io/docs/migrate-x-to-jsr

Answer 5 · 2024-04-10T09:04:06.000Z

Which imports? Do you mean @std?

@KnorpelSenf Yes, and grammY imports, of course.

Answer 6 · 2024-04-10T09:04:56.000Z

I’m also unsure how JSR handles peer dependencies for Node.js, so I don’t think it’d be good to recommend it for Node.js users (maybe?).

Answer 7 · 2024-05-11T14:50:02.000Z

It's pretty simple to download npm-ready tarball from jsr.
There is a special endpoint . For example:https://npm.jsr.io/@jsr/shevernitskiy__amooutputs:

{
  "name": "@jsr/shevernitskiy__amo",
  "description": "This is a simple wrapper client for the amoCRM REST API. It covers almost all API modules and endpoints. Also, it manages to token refreshing and webhook handling.",
  "dist-tags": {
    "latest": "0.2.5"
  },
  "versions": {
    "0.2.5": {
      "name": "@jsr/shevernitskiy__amo",
      "version": "0.2.5",
      "description": "This is a simple wrapper client for the amoCRM REST API. It covers almost all API modules and endpoints. Also, it manages to token refreshing and webhook handling.",
      "dist": {
        "tarball": "https://npm.jsr.io/~/11/@jsr/shevernitskiy__amo/0.2.5.tgz",
        "shasum": "04C2380FC1C556A52FA0A40FD3865A881550537D",
        "integrity": "sha512-k/HilfYJb+hbTRfbdtZy2G//nOLSmk1VCfNrXDHjnyWyeq06KS5LzUns0zAghmVSMoPQJYTOSW0nIA6Y7hiYkg=="
      },
      "dependencies": {
        
      }
    },
    "0.2.4": {
      "name": "@jsr/shevernitskiy__amo",
      "version": "0.2.4",
      "description": "This is a simple wrapper client for the amoCRM REST API. It covers almost all API modules and endpoints. Also, it manages to token refreshing and webhook handling.",
      "dist": {
        "tarball": "https://npm.jsr.io/~/11/@jsr/shevernitskiy__amo/0.2.4.tgz",
        "shasum": "39C6C73D454DE23A06E693F5A8E6308AB4084C01",
        "integrity": "sha512-J1Vx1QduYjUXKe2vVcK7luL8znCOfo1DA+Tv1VG6CVRGfOUx3Z2/Yk7SBHV8HNTs/q77dSxxglIJWL40grEFIA=="
      },
      "dependencies": {
        
      }
    }
  },
  "time": {
    "created": "2024-03-02T05:37:01.088Z",
    "modified": "2024-03-03T05:14:15.443Z",
    "0.2.5": "2024-04-11T05:02:50.177Z",
    "0.2.4": "2024-03-02T05:37:10.149Z"
  }
}

It contains all npm needs including package.json:

_dist contains d.ts files

Answer 8 · 2024-05-12T09:28:37.000Z

Yep we're aware how JSR works, the pending question is just if we

a) download npm tarballs from JSR and upload them to npm, or
b) build our own tool, potentially leveraging the build functionality of JSR, and package stuff in CI and upload it ourselves.

a) is much easier, but we depend on an API during build.

b) is harder but naturally more reliable.

Answer 9 · 2024-05-12T09:36:02.000Z

I think it could be a for start and then replaced for b without any issues (if it will be needed). In CI it cloud be 1 or several steps.

Answer 10 · 2024-05-12T12:12:36.000Z

I've noticed, that hono dev doing some work on this too:) honojs/hono#2662

Answer 11 · 2024-05-15T05:18:30.000Z

Btw, https://github.com/denoland/dnt allows to download a package and make it local in case of it can't be resolved as npm packcage. Also it supports shims and mappings like *.deno.ts/ *.node.ts as well as deno2node and handles with jsr specifiers (denoland/dnt#398).
So, we could prepare npm build with this tool and move to JSR imports in deno source code.

Answer 12 · 2024-05-15T05:25:28.000Z

d2n already does this for us. You're describing our current build setup, just with /x swapped out for jsr.

Answer 13 · 2024-05-15T05:32:48.000Z

As I understand, d2n can't download packages and make it local when it can't be resolved as npm package.

Answer 14 · 2024-05-15T05:50:01.000Z

It can do this, but I don't think we use that feature anyway.

If we can't get rid of custom build tooling, then we can switch to JSR immediately and close this issue. Moving to dnt is not an option, this has been discussed extensively on numerous occasions. The only reason why we'd need to touch our tooling is if we can maybe drop everything and let JSR handle it, and all that's left for us to do is to download and re-upload.

Answer 15 · 2024-05-16T14:44:49.000Z

I think I would like to go with the following approach:

Check if we can rely on JSR to build our own npm tarball in GH actions, such as by importing the api crate from https://github.com/jsr-io/jsr/tree/main/api and then calling https://github.com/jsr-io/jsr/blob/4389058b3e80b647e3126fd84c005272d66e5348/api/src/tasks.rs#L71
If this can be done with a reasonable amount of effort, publish dually to JSR and npm, both using the same transform logic (once running on JSR and once running inside GH actions)
If step 1 fails, we instead build a tool to download tarballs from JSR, repackage them, and upload them to npm again
Step 3 has the downside of relying on a third-party service during build, which is not ideal. If this ever breaks down or starts being unacceptable, we can go back to step 1 and put in more effort to use JSR, or build our own tool, or find a different solution so that CI is self-contained again

Answer 16 · 2024-05-16T15:52:55.000Z

Do you want to spin up whole api and use endpoint or just get the tarball build code?
Seems like the actual build code is here https://github.com/jsr-io/jsr/blob/main/api/src/analysis.rs#L434

Answer 17 · 2024-05-16T16:06:11.000Z

Well, at least i want to try:D
jsr-io/jsr#525

Answer 18 · 2024-05-17T11:38:38.000Z

Nice! I'd fork JSR and extract the things myself so that we can work with it. If they accept a contribution upstream, that's great, but I would not want to wait for that.

The best way to do this is to isolate the transpilation up to the point that we just need to provide a scope, a name, and a version, and receive a tarball.

Answer 19 · 2024-10-10T05:38:52.000Z

Deno 2 is out and i believe this changes things a lot.

Answer 20 · 2024-10-10T05:41:22.000Z

In what way?

Answer 21 · 2024-10-12T07:32:15.000Z

@KnorpelSenf: JSR is out of beta. It is superior in almost every way to deno land from a package management/docs perspective. The migration path is minimal as well https://jsr.io/docs/migrate-x-to-jsr

Answer 22 · 2024-10-12T07:35:25.000Z

@kamikazechaser have you read the above issue?

Answer 23 · 2024-10-12T07:36:07.000Z

@KnorpelSenf Yeah, I wanted to add a P.S on my previous comment that I am speaking for Deno only. Not Node.js + Deno.

Answer 24 · 2024-10-12T07:40:37.000Z

But … Deno 2 changes nothing for us, and whether or not JSR is in beta is irrelevant for us, too. It's a cool release but how is any of what you're saying related to this issue, or grammY in general?

Answer 25 · 2024-10-12T07:44:42.000Z

what you're saying related to this issue, or grammY in general?

The title is Publish grammY to JSR respository

What I am trying to say is that there is no downside to re-publishing this repo to JSR. It is going to go mainstream with Deno heavily investing into it. If you don;t want, I understand and that is fine.

Answer 26 · 2024-10-12T07:46:11.000Z

I think you just have not read this issue 😁

Answer 27 · 2024-10-12T07:48:41.000Z

I think this is going nowhere. I'll leave it at this. I understand that you want to be consistent with all ecosystems and that is fine.

Answer 28 · 2024-11-06T11:26:50.000Z

@wojpawlik @niusia-ua I think we should not wait for jsr2npm to become a reality. We can start working on v2 before that, and publish beta releases to JSR for the time being. There will be enough time before a major release to figure out how to solve npm compat, so the tool can be written at a later point.

In contrast to JSR, npm can actually install things from GH, so we won't even leave npm users behind.