Closed lexuzieel closed 7 months ago
After trying the workflow with npm link
it seems like two references to Context
are clashing (one from the grammy types package and another from my linked menu types):
Here the first one is from the linked package and works with Menu<Context>
, but it doesn't work in the rest of the project.
The second one works in the rest of the project, but then I cannot use my custom context type with the Menu
imported from linked package:
Maybe it's worth creating a simple test bot in this repository and use it during development?
Maybe it's worth creating a simple test bot in this repository and use it during development?
I'm not quite sure what the point of this would be tbh. You can just copy & paste the example bot from the README.
This is a Deno project. You do not have to run a build step or run npm link
or do guesswork with file paths and imports. Those are things we leave behind by not using Node tooling anymore.
Instead, just change the import URL of a Deno example bot to rely on "src/mod.ts"
. grammY itself can still be fetched from /x
. Then everything will work.
Alright, I see. Let's make it clearer in the docs for other people who are not familiar with Deno.
Could you outline a list of step by step commands one has to run during development?
As for the bot, I was thinking of creating scripts to be able to iterate during development using real telegram bot.
For example pagination.bot.ts
or similar would run a sample bot with different pagination demos. Same thing could be done for nested menus. Do you have better suggestion on how to iterate during development?
Alright, I see. Let's make it clearer in the docs for other people who are not familiar with Deno.
Do you want to copy these things around for all 30+ repos, or document it once in the core repo, or link people to https://deno.land/manual?
Could you outline a list of step by step commands one has to run during development?
Setup: install Deno, install the Deno extension. Optionally, use the quick fixes in the editor in case some deps are not cached, but there is a light bulb that tells you what to do, so I trust that people do not need docs for this. "If there is a quickfix, try it" seems to be more or less common sense.
As for the bot, I was thinking of creating scripts to be able to iterate during development using real telegram bot.
For example
pagination.bot.ts
or similar would run a sample bot with different pagination demos. Same thing could be done for nested menus. Do you have better suggestion on how to iterate during development?
The way how I do it is to write tests. Tests can be run in watch mode using deno test --watch
. I write sample bots if I want to check whether the API for a certain feature is good, but I usually just type-check that code and run it a few times to make sure I did not forget to export things or so.
If you think about the core lib, there are way too many features to have sample bots committed to the repo. This would not be useful during development. Even this plugin is quite large, so I am not sure how useful they are. I literally just write them on the fly if I have to test once thing (takes maybe a minute to do that) and then I discard them again afterwards. This is much less effort than having to maintain a folder with 30 example bots, knowing which one does what, keeping things explained and up to date all the time for all plugins.
We do provide a few examples in https://github.com/grammyjs/examples, but they are meant for users rather than for development. We could still have some more of them.
Do you want to copy these things around for all 30+ repos, or document it once in the core repo, or link people to https://deno.land/manual?
Of course documenting it once makes the most sense :) I think it's best to add "Contributing" section somewhere in the plugin docs and put a link there in each plugin's README. That way common aspects will be in a single place while also having an ability to extend with plugin-specific details in its README. Furthermore, maybe we could expand this towards the whole project later.
I think it's a great place to introduce people to Deno as well!
As for the tests I agree that maintaining them isn't a great idea, however it must be documented. As someone who never used Deno I currently have to try various approaches myself and figure out what works and what doesn't.
So the documentation on the following points will help:
<something>.test.ts
file and running deno test --watch --allow-all
). I would still at least provide a boilerplate test file in the docs which loads bot token from the environment and waits for user input.--allow-all
flag, which puzzled me for a moment.These points could be covered in docs on grammy.dev. This should bootstrap any future contributors and might even act as an introduction to Deno.
To sum it up, we want to finally have a true contribution guide that gets people up and running with grammY development on Deno.
So far, we kept user-facing docs on the website and contributor-facing docs in the markdown files inside repositories. We can either keep it that way and just write a much better contribution guide on @grammyjs/grammY, or we add a new section to the website where we elaborate on all the points you mentioned above. @roj1512 do you even think that these things should go on the website?
Closing due to inactivity
@KnorpelSenf I've added a section on how to setup development environment after stumbling upon those issues myself. Maybe it's a bit too verbose, then we could hide those instructions under the collapsible section.