Migrate to TypeScript?

[grubersjoe]

Hey. Since this project has gained a lot of momentum and more and more people are contributing I think it might be sensible to start a discussion if a migration to TypeScript makes sense. It's clear that such a migration would be a huge effort and I don't know if this is something people (and the author) are interested in. Still, I think the project would benefit a lot from it:

• static types document the code automatically
• confidence to refactor increases
• some bugs become compile errors
• easier for new contributors to find their way around
• some general issues in the codebase might surface (wrong API usage etc.)

If we want to do that, I think we would have to do it in small steps. Maybe start with allowJs: true and migrate package for package. You can also infer TypeScript types based on the Yup schema. If you knew the exact data structure of a Collection etc. everywhere that alone would be a huge improvement regarding maintainability in my opinion.

[trin4ik]

I'm against it, I'm new here and I'm just starting to learn the code for further contribution. And TS is not about quick development and easy entry, it's about routine, where 90% of the time you describe the code.
I'm not imposing my opinion ))

[PalmDevs]

Unfortunately that's how it is and it'll always be like that. You can't really just let TS infer whatever it wants. That'd just be JavaScript with less oopsies and not really a typesafe language.

[helloanoop]

@ajaishankar @Its-treason @martinsefcik @lared What do you guys think ?

If we ever decide to move core modules to TS, We should only be doing it post V1 release

[Its-treason]

Our team started to rewrite most applications in typescript, and it's been amazing so far. Getting better intellisense in the IDE and a static type checker really helped us prevent most bugs and be more productive.

So I would migrate Bruno to typescript.

[martinsefcik]

I'm primary Java backend developer so I'm not sure If my opinion is relevant. But I have some experience with type-safe and non type-safe programming languages and I think for smaller projects can be non type-safe languages good option but for larger one is type-safety a must.
When I was rarely doing something in recent months in JS I always chose TypeScript instead of pure Javascript.

[ajaishankar]

@helloanoop I love typescript and would not think of starting a project without it (for all the reasons @grubersjoe mentioned)

But was shocked to read recently Hotwire Turbo ditched Typescript altogether.

https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01

In Bruno's case depends on what the collaborators feel. If it makes it difficult for them to contribute then most probably not.

Personally I'm all for it, in fact the query package is already in Typescript 😄

[ajaishankar]

That said, take any popular package nowadays and chances are it will be written in Typescript.

I think Turbo is an aberration...

[xaviermarchegay]

Svelte also migrated away from Typescript to JSDoc I think.

[ajaishankar]

Yes, that is actually funny - a compiler tool moving to JSDoc just because Typescript has a "build step" 😄

[ajaishankar]

Let's do it! 😄

[grubersjoe]

TypeScript might have saved us ^^
#686 [Bug] Ordering collections fails in v0.26.0

[aliasgar55]

Maybe this one as well #717

[bpoulaindev]

I'm also in the Typescript side of the force, some functions are more obscure than others, having interfaces from here and there may help us having a cleaner development in the future, especially while improving the import scripts from insomnia, postman...

[nelup20]

I definitely agree with moving towards TypeScript in the future, especially since it seems that type annotations in JS won't be arriving anytime soon (still in stage 1).
It'll make the project much easier to work with & reason about.

We used TS in a previous team/project & the only issue we really had was mocking with Jest. Specifically, you can't mock interfaces like in Java/C#-world, and mocking dependencies in a class was also a pain.
We didn't have time to try these, but it looks like one of these libraries could fix that:

• https://github.com/marchaos/jest-mock-extended
• https://github.com/NagRock/ts-mockito