Future Plan discussion

[yagop]

Feel free to discuss the following topics.

Rewrite to TypeScript

Rewrite all files to TypeScript. We have to decide which version of ES we want to target depending on NodeJS version we target.

Target NodeJS v16

v16 is old enough and have LTS support.

If we target v16 we can have support up to ES2021 which has most modern JS features.

Use Zod to validate incoming JSON's

We can use zod to validate the incoming JSON as to make sure the schema is right. This may cause errors if we don't correctly describe the schema. If Telegram decide to change some data it will cause errors too.

We can use safeParse to avoid the program crashes but the behaviour is unexpected.

Stop using EventEmiter and use asynchronous generators

Asynchronous generator is an efficient and clean way to process async data. We can consume the data like:

for await (const event of fetchEvents()) {
    if (event.type === 'text') {
       ...
    }
}

This would mean a breaking change in many ways.

Support deno

Maybe it's easy we support deno.

Split the logic in different files

telegram.js have 2658 lines of code. We can split some logic across different files.

Test against tdlib/telegram-bot-api)

Maybe we can patch tdlib/telegram-bot-api to run our tests against it

[wojpawlik]

Node 18 is also LTS and has globalThis.fetch. Related: #1007.

Rewriting to TypeScript might not be necessary. Instead, existing JSDoc annotations can be changed to let typedoc typecheck the code and generate docs and .d.ts. Related: #855.

for await is not a great fit. Most importantly, it's sequential, making it difficult to process updates concurrently.

[danielperez9430]

In complete agreement with support starts from node 18, users how still use node 16/17 could use the library with native fetch by passing a flag (node app.js --experimental-fetch) to it on run if they want fetch support.

But without a doubt, starting in support from Node 18 onwards would make things a lot easier.

[kamikazechaser]

Use Zod to validate incoming JSON's

I propose that we should always trust Telegram server payloads. The burden of protecting the webhook endpoint should be on the user. As for polling, the library will already have the correct endpoint and any other config the user makes around this (Proxy e.t.c) will again be with the user.

If Zod is still a requirement for the user, the burden could be offloaded to the server itself as a prehook e.g. Fastify.