search

meetecho / janode

A Node.js adapter for the Janus WebRTC server
ISC License
98 stars 36 forks source link

Migrating to Typescript #24

Open alvitoraidhy opened 1 year ago

alvitoraidhy commented 1 year ago

Any plan or interest in migrating the codebase to Typescript? I think it would be more manageable in the long run compared to managing separate d.ts files.

atoppi commented 1 year ago

What are the benefits of migrating to TS in your opinion?

Basically I'm concerned about the absence of native support in node, so code will need compiling. I use compiled languages a lot, so I know that leads to:

alvitoraidhy commented 1 year ago

With Typescript the package from npm would come with typings (*.d.ts files) without having to maintain them separately. Moreover you won't really need to type using jsdoc if you use Typescript and the TS compiler will ensure the source code is free from syntax errors.

While I do understand the cons that you described, I have only experienced point 3 out of all of them in my time of using TS for development.

atoppi commented 1 year ago

I am still not convinced, but I have to admit I've never managed a TS project before. Pinging @augustblack (author of #5) since he might have something to add to the discussion here.

augustblack commented 1 year ago

Hi,

I understand some of the concerns you mention @atoppi . Adding an extra step in the build chain can be adding another place of failure, another source of friction for initial onboarding, etc.

I'm not sure why you think it is more difficult debugging. Perhaps one main benefit is the addition of types to help narrow down potential bugs.

Personally, I moved to TS years ago since I find the advantages outweigh the disadvantages. Newer runtimes like bun and deno can also ingest TS directly.

I'd also prefer janode in TS.

atoppi commented 1 year ago

I'm not sure why you think it is more difficult debugging. Perhaps one main benefit is the addition of types to help narrow down potential bugs

I am not referring to static analysis. As far as I understand TS will not help at runtime and I am referring exactly to those kind of issues. A crash might happen on an instance, then the mapping files will point to the TS section that made the code crash, but since the code is transpiled from TS to JS, we don't know what the actual executed JS was. The specific env of the compiler might trigger a problem that in other scenarios is not occurring since the transpiled JS could not be the same.

Maybe I am worrying too much and that is a false problem, I don't know, as I said I don't have experience in managing TS projects.

Anyway I have understood that users really care about type definitions and I will definitely tackle this sooner or later, maybe by working on #5 or migrating the whole project to TS. Honestly, according to my personal roadmap, a VideoRoom plugin fully supporting multistream has the highest priority now, so I guess that will definetely come first.