Migrate project to TypeScript

[smoya]

Reason/Context

TypeScript provides a really good set of features on top of Javascript. It is very opinionated and used widely across the whole OSS scene.

Some of the features I consider very interesting here are Static (or strict) typing and OOP syntax models including interfaces, classes, enums, etc.

All those things improve not only the Developer Experience but codes stability and resiliency by:

• Early catching errors.
• Improving code reusability.
• Improving code extensibility.
• Making (unit) testing a more thorough thing.
• Having a nice IDE integration.
• Etc.

Definitely, it drives us through the road of Producing software that can be easily extended, reusable, and highly testable.

Considering the Road to v2.0.0 and the fact major changes are going to happen, such as a complete rewrite of the API of the parser (See #453), or the rewrite we plan to do for the parsing logic integrating Spectral (See #477), I can't think of a better time to move forward with this task.

Description

To rewrite/migrate the entire parser-js library in TypeScript.
We should create PR's targeting next-major branch if we finally want this to happen in v2.0.0.

This development also includes porting the new Parser-API based on the latest implementation that can be found here: #497 (comment)

[magicmatatjahu]

@smoya I am 100% in favor of this! I can of course help with the rewriting. We can split it so that you take care of models and intent API and I will take care of validation (by spectral) and parsing. WDYT?

[smoya]

@smoya I am 100% in favor of this! I can of course help with the rewriting. We can split it so that you take care of models and intent API and I will take care of validation (by spectral) and parsing. WDYT?

That's awesome @magicmatatjahu! Thanks for jumping in 💯 . Let's zap all previous code so we can freshly start with this! #483

[Souvikns]

@smoya would love to help, I have been reading parser for some time now and I wanted to get started with the project but didn't know where to start, I think this is the best time to get started since we are rewriting the whole parser. Just let me know how I can help.

[smoya]

@smoya would love to help, I have been reading parser for some time now and I wanted to get started with the project but didn't know where to start, I think this is the best time to get started since we are rewriting the whole parser. Just let me know how I can help.

Hi @Souvikns! I'm so happy we can count on you! 🎉

Currently, I'm working on the the Model side, in particular building up all the new Models for the Intent-Driven API (See #401).
@magicmatatjahu is working on the Parse logic side, which is also very large.
Maybe you @Souvikns could take one issue from #481 that you like and work on it.

Do you suggest any in particular @magicmatatjahu (you have a broader knowledge on this codebase as well)?

[magicmatatjahu]

@Souvikns @smoya Parser logic side is very complex than Models/Intent API, so maybe you @Souvikns can rewrite some models from old API to new with tests :) @smoya what do you think? At the moment a lot of things from issue #481 can't be done because significant logic is missing.

[Souvikns]

At the moment a lot of things from issue #481 can't be done because significant logic is missing.

Yeah, I figured that, so I was exploring spectral, there are a lot of models that we have to rewrite I can help with that, if @smoya lets me 😄

[Souvikns]

@magicmatatjahu @smoya can I try writing the server model?

[magicmatatjahu]

@Souvikns Yeah, you can :) Please base implementation on the https://github.com/asyncapi/parser-api/blob/master/docs/v1.md#server and remember that we have mixins for description, bindings and extensions methods

[magicmatatjahu]

In 99% we don't need the traversing functionality, because atm we only use it for anonymous naming and for retrieving all schemas and messages, and we do that in simpler way than current. For Custom ID naming we can implement idea from Jonas - #176

I'm just wondering if these lack of travserse functionality won't affect ecosystem badly because someone might use it besides us in the parser, and if the new way of anonymous schema won't affect Modelina badly, which makes heavy use of generated names.

[magicmatatjahu]

Issue is resolved in v2 ParserJS - now in https://github.com/asyncapi/parser-js/tree/next-major branch