grammyjs
feat: bun related docs (@stonega)
Originally PR was created by @stonega, but it looks like he's not going to continue with this PR. So, I think we should mention Bun as a possible way to work with a bot, even though Bun has a large number of issues. Also Bun finally supports conversations plugin and a decent part of Russian language chat users use it for their projects.
I made some changes and added Bun mentions to the hosting files documentation
🚀 Deployed on https://690dd35ebfa55ee9a3317450--grammy.netlify.app
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Should we leave index.ts or should we tell the user to create a bot.ts file each time in order for the NodeJS and Deno examples to be the same?
I have now wasted more time on this than I ever wanted, maybe I'll get back to this in a week or so
Unfortunately we can't fix it. We will have to ask the user to change it manually every time. But I don't understand the point of this, because everything works with the current tsconfig O.O
Yeah but I don't want to go through all the code examples and make sure that they compile even with the non-standard TS config that bun introduces. It can be fixed very easily by running tsc --init in the getting started guide.
@KnorpelSenf : Yeah but I don't want to go through all the code examples and make sure that they compile even with the non-standard TS config that bun introduces. It can be fixed very easily by running tsc --init in the getting started guide.
@MasedMSD: But I don't understand the point of this, because everything works with the current tsconfig O.O
I am agree with @MasedMSD. I don't see any problem with the default generated tsconfig.json. Pretty sure it works well with our examples.
@KnorpelSenf : Yeah but I don't want to go through all the code examples and make sure that they compile even with the non-standard TS config that bun introduces. It can be fixed very easily by running tsc --init in the getting started guide.
@MasedMSD: But I don't understand the point of this, because everything works with the current tsconfig O.O
I am agree with @MasedMSD. I don't see any problem with the default generated tsconfig.json. Pretty sure it works well with our examples.
Then please go through them and verify this. Also, please test all future changes to the docs for bun compatibility. I don't care what the config file contains, I just won't double the time I spend on code examples just to make a few bun users happy.
Only as soon as we find somebody who actually puts in the work and makes sure that the code examples work. I don't want to merge docs that don't type-check because then I'm gonna be the one who has to deal with all the complaints.
If somebody is willing to
- make sure that the current docs type-check, and
- make sure that all future docs type-check
then we can ship docs that use a new TS config setup.
@KnorpelSenf It would be useful to create some package for easy unit testing of the bot. I don't think that's possible given the flood handling by telegram
I mean that we should have some kind of tests to make sure that the bot and the code work. For example, as for the situation now, when we can't be sure that bun will pass all type-checks
That's why you have to test it, or adjust the TS config. But I'm beginning to repeat myself a little
I mean that we should have some kind of tests to make sure that the bot and the code work. For example, as for the situation now, when we can't be sure that bun will pass all type-checks
It’ll be hard to write integration tests for Bun and grammY because the existing test suite is in Deno. We’d have to spend a lot of time instrumenting some Docker CI test just specifically for Bun, and I am not sure if it’s worth the effort.
There's no need to actually run any tests, why do you think this? I can't follow
I don't have strong opinions on what exactly you're gonna do. I just need you to make sure that the code examples are correct. It doesn't matter to me if you achieve this by making people use the setup that is known to work, or if you want to test all present and future code snippets against a new setup.
What I mean is that this command generates the typescript config that we use in all the examples. I think we should add Bun, but if there are any problems (which I'm not sure about at all, Bun is quite stable) we should deal with them as they come up.
Yes. We will merge this PR into main if we leave the command to generate the config we use everywhere else? We should mention the Bun's support, because a lot of users in our community use it
I mean, this PR has been hanging around for a long time and we need to do something about it. Either put it on hold or get on with it
I don't care if you use the command or not and I'm not opposed to mentioning bun support
I'm not opposed to mentioning bun support
Great, I'll take care of that PR
I mean, this PR has been hanging around for a long time and we need to do something about it. Either put it on hold or get on with it
That's true, what was stopping you?
I'm not opposed to mentioning bun support
Great, I'll take care of that PR
Nice