Feature Request - Complete TypeScript Implementation

[zolero]

Is your feature request related to a problem? Please describe.

While the current JavaScript implementation of moleculer.js has served well, there have been instances where runtime errors and potential bugs could have been avoided if the package had been designed using TypeScript. The lack of static typing and autocompletion can lead to slower development speed and potential errors.

Describe the solution you'd like

I propose upgrading the package to support a complete TypeScript implementation. TypeScript, as a statically typed superset of JavaScript, provides robust type checking capabilities which help in catching potential bugs during compile-time, rather than at runtime. It also offers superior tooling, including autocompletion, type inference, and documentation capabilities. Additionally, TypeScript code can be more readable due to the availability of type annotations, thus making the package more maintainable.

Describe alternatives you've considered

As an alternative, we could consider introducing TypeScript gradually, by using it in certain parts of the package and progressively expanding its use. However, given the advantages of TypeScript over JavaScript, a full transition would still be the most beneficial in the long term.

Additional context

TypeScript is future-proof, as it is constantly updated to include the latest ECMAScript features. This ensures that the package will stay compatible and modern as the JavaScript standard evolves.

Despite being a different language, TypeScript is compiled down to JavaScript and thus maintains full compatibility with JavaScript code. This allows developers to gradually adopt TypeScript, or even to use both languages in the same project.

This proposed upgrade would not alienate developers who prefer JavaScript, but it would open the door to the growing number of developers who prefer TypeScript for its additional safety and tooling features.

The upgrade to TypeScript, although substantial, represents a significant investment in the long-term quality and sustainability of the moleculer.js. It is, in my view, a progressive move that would greatly improve the package's overall development experience and code reliability.

[ccampanale]

Not sure how accurate this is but "moving to TypesScript" is apparently on the v1 roadmap project.

[zolero]

Excuse me, I haven't checked the roadmap before you mentioned this. It's good to see @icebob has planned to upgrade the package to typescript. If you need help @icebob with converting the package to Typescript I'm willing to help making the transition. Whenever you are ready to start on this. Since right now our business is dependent on Moleculer and would love to see this package evolve.

[ccampanale]

No worries, I too just happened to stumble upon that after I saw your issue!

I'm in a similar situation and almost all of my microservice codebases are written in TypeScript. I don't have many issues, especially as the type declarations continue to evolve, but I agree that the framework may be able to benefit from use broadly.

[zolero]

Maybe it's an unpopular opinion, but there might be a good use-case for this package to upgrade it using GPT4 of OpenAI. It seems to be a relatively small package if I check all the files and methods. It might optimize quiet some code as well? Thoughts?

[AndreMaz]

Since it's a JS project there's quite a bit of implicit knowledge that's required to understand how things connect together. I think that GPT4's context size is not enough to feed all the source code in one go so it won't be able to build full context. All of this is just to say that I'm a little bit skeptical that GPT will be able to properly convert and optimize it (especially service broker, middleware, hooks, etc.)

However, since the code has a really huge amount of unit/integration tests you might give it a try and see the result.

I'm interested to see what GPT will be able to do

[zolero]

I'll do some testing to see what it's capable of. These unit tests will definitely by key in doing these transformations.

[ishfx]

It's a huge task to refactor the entire framework into typescript, and I believe it should be approached gradually. One possible solution is to develop tools, libraries, and other resources that can translate typescript into Moleculer service definitions. Think of it like babel for Moleculer.

If more people contribute by providing complementary typescript libraries in this endeavor, it will greatly facilitate the framework transition. Their input will offer valuable insights into the optimal path to take for transitioning to typescript.

By the way, I've shared my approach to migrating to TypeScript here: #1204. I opted for using decorators as they provide an effective means of storing metadata (particularly in typescript) and transforming it into JavaScript during runtime.