Comments (18)
Which imports? Do you mean
@std
?
@KnorpelSenf Yes, and grammY imports, of course.
from grammy.
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.
from grammy.
I've noticed, that hono dev doing some work on this too:) honojs/hono#2662
from grammy.
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.
from grammy.
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.
from grammy.
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.
from grammy.
I advocate for writing a custom script that replaces imports with JSR ones, and vendors whatever cannot be replaced.
from grammy.
Which imports? Do you mean @std
?
from grammy.
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
from grammy.
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?).
from grammy.
It's pretty simple to download npm-ready tarball from jsr.
There is a special endpoint . For example:https://npm.jsr.io/@jsr/shevernitskiy__amo
outputs:
{
"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
from grammy.
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.
from grammy.
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.
from grammy.
d2n
already does this for us. You're describing our current build setup, just with /x swapped out for jsr.
from grammy.
As I understand, d2n can't download packages and make it local when it can't be resolved as npm package.
from grammy.
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
from grammy.
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
from grammy.
Well, at least i want to try:D
jsr-io/jsr#525
from grammy.
Related Issues (20)
- (bug) memory leak HOT 6
- Stripe Pre-Checkout Timeout Error while making a Test Payment from Telegram Bot HOT 2
- parse_mode doesn't work with editMessageText HOT 5
- baseApiUrl not working HOT 1
- feat: add a warning in debug mode upon "Call to 'getMe' failed! (401: Unauthorized)" that the bot token is incorrect HOT 9
- 1.22.0 broke existing code type check HOT 7
- [feature] How do I listen for every messages in a group chat? HOT 2
- Can't deploy conversations plugin on Cloudflare Workers HOT 1
- Property 'wait' does not exist on type 'ConversationControls'.ts(2339) HOT 2
- feat: ctx.message.message_thread_id presumably should not be | undefined in message:is_topic_message HOT 6
- Conditionally enrich context and change it's type for all subsequent midleware. HOT 7
- [Proposal] Expose type FilteredContext. HOT 1
- HttpError: Network request for 'getMe' failed! HOT 5
- HttpError: Network request for 'sendMessage' failed! HOT 3
- Add error type to `GrammyError` HOT 2
- Problem with editing files (editMessageMedia and editMessageMediaInline) HOT 3
- menu plugin with multiple language translations error HOT 2
- Bot not full width on mobile HOT 4
- Allow using AbortController in globalThis if available
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grammy.