Migrate to TypeScript

[cyberhck]

• This is not a v0.x issue.
• I have searched the issues of this repository and believe that this is not a duplicate.

Hi according to roadmap, there'd be a possibility of discussion for migrating to typescript, as currently maintaining separately doesn't seem to be ideal, migrating the whole project into typescript would mean a huge task, but that'd make project much more maintainable.

Any plans on that front?

---

Edit by maintainers. We are progressively moving the codebase to TypeScript, as we write new modules or refactor existing ones. This started in 2019 and will likely take a while (and expected to), see this timeline:

• 02/2019: TypeScript: 1.6%
• 03/2020: TypeScript: 3.2%
• 07/2020: TypeScript: 5.3%
• 10/2020: TypeScript: 25.4%
• 11/2020: TypeScript: 34.7%
• 04/2021: TypeScript: 35%
• 07/2021: TypeScript: 35.4%
• 09/2021: TypeScript: 36.1%
• 03/2022: TypeScript: 40.5%
• 06/2022: TypeScript: 38.4% (we moved the pickers written in TS to MUI X)
• 09/2023: TypeScript: 50.9%
• 03/2024: TypeScrip: 56.4%

[oliviertassinari]

@cyberhck What do you expect for with such migration, as a user of Material-UI?

My counter-argument is with the opportunity cost it creates for us when committing with this effort. What else can we work on? From my perspective, the priorities are: 1. More components (more time saving) 2. Isolate the styling solution, have JSS has optional, make styled-components the default engine (broader reach). Do we have room for any other major effort?

[eps1lon]

as currently maintaining separately doesn't seem to be ideal

How did you come to this conclusion?

[cyberhck]

I think I might have given the wrong impression on my issue, please let me clarify

In no way I wish to pause the feature development for material UI and only work on typescript migration, I'd never ask any project to pause their own development. Then there'd be no v5 release, release without any new feature doesn't make any sense.

currently we're maintaining javascript files, and keeping definition files on the side, which may not be in sync all the time, and they might not reflect the true types, changing one js file and forgetting to change type definition might also be a problem or rushing through changing a component but forgetting to update types might also be a real problem,

That's what I meant when I said maintaining separately doesn't seem to be ideal.

The way I proposed to do is the following,
Add typescript to project, then interop with javascript, make sure test files are NOT changed when you change the component initially, for a few releases, you can work in parallel with JavaScript.

Say there's a bug fix for button or (someone interested from community), will start working on migrating that 1 component and make sure the tests pass (without converting tests to typescript initially), once the button is merged, we can come back to tests later to convert those as well.

This way you keep your development steady, and if you're touching some component any way, then you can convert that particular component into typescript because we already have so many components with good type definition, it should be easy to convert components one by one.

What do you hope for with such migration, as a user of Material-UI?

As a user of material-ui I might not be getting very tiny benefit where I can be confident that the typedefinition provided are actually in sync with project (because code is source of truth), but I'd argue benefits which will indirectly influence me.

after the migration is done, the codebase might have less potential problems and development might be a bit faster, I could contribute more easily if I wanted to.

It's more of a confidence thing I guess.

[yordis]

@oliviertassinari sharing something from Jest migration to TypeScript experience.

1. Set up the tooling upfront for all the packages and request help from the community. I am talking this about https://github.com/mui-org/material-ui/blob/21582fd3afb38ed4da036f453f3bf56b27d14c91/packages/material-ui-lab/package.json#L25-L35

2. List all the packages under Mui for visibility.

3. Be available for support understanding the edge cases.

The 3rd bullet point stopped me completely from actually giving you a hand, I tried to migrate material/styles and then I found out that the typespec was wrong and I will require some support from the core team.

Be prepare, do not hunt the perfect typespec, sometimes a simple any is enough and you can always circle back on it, just don't hunt for perfection where there is a little reward on it.

I am more than happy to help you, but since I tried this myself, I know I will require some support from the Core team.

[eps1lon]

The problem is not converting JavaScript to TypeScript. The problem consists of many issues of TypeScript in the JSX domain. We would need to any so many things that there would hardly be any benefit left.

Yes sometimes types are outdated but that's usually just a missing prop or CSS class key. It's very rare that those stay unfixed for more than one patch version.

Then we have to migrate all the internal tooling: lint, mocha test, karma vrtest etc. This is nowadays less of a hassle thanks to @babel/preset-typescript or eslint supporting tsx files but it still has potential for maintainer churn.

Which leads to the last point: Not every maintainer has experience with typescript. And this may be egoistic but I don't want to be the guy that has to review every PR because there's some issue with TypeScript. I like that we have the ability to move implementation and and interface separately which is what TypeScript is for us now: A interface description. Bugs that could've been caught by TypeScript are very rare as far as I can tell (didn't investigate this; just a feeling I have).

So far I could only identify that we would eliminate issues regarding outdated props. I don't think that justifies the amount of effort involved.

[yordis]

Yes sometimes types are outdated but that's usually just a missing prop or CSS class key. It's very rare that those stay unfixed for more than one patch version.

@eps1lon being a TypeScript user myself this is my pain https://github.com/straw-hat-team/react-admin/blob/1352d6c56d777e094febd652472d5dadf7387fe8/src/administrator/AppBar.tsx#L15

I keep adding, @ts-ignore Mui needs to fix this because the typespec is secondary. If you are taking the effort to maintain .d.ts files I don't see why you wouldn't use TypeScript then.

which is what TypeScript is for us now: A interface description.

Keep it like that then, you don't have to use strict rules and force yourself to do things that are almost no value, this is one thing I am trying to explain to people, there is nothing wrong with any type or simply omit the typespec.

You would argue the value of TypeScript then, but I would say that I would prefer to have correct typespec than having all the typespec.

I don't believe that we should be using TypeScript for capturing bugs, but I would encourage for documentation, faster understanding of the internals since you have more static types that you could analyze.

Use it when you need it 🤷‍♂

[eps1lon]

@eps1lon being a TypeScript user myself this is my pain straw-hat-team/react-admin:src/administrator/AppBar.tsx@1352d6c#L15

The issue you linked it not caused by an outdated type spec. I would encourage you to submit issues or search through them or read the docs. As a typescript user you should be aware that the error messages are not always helpful i.e. point in the right direction.

[oliviertassinari]

I agree with @eps1lon, I think that we would be better off (from a fundamental point of view) completing #14897 and spending our time of the existing reported TypeScript issues before even considering a migration of the codebase to TypeScript.

The main value I see in a TypeScript migration is a marketing one. We can turn the users' psychology in our favor without changing the core product value. It works as follow: "the codebase is written in TypeScript, it must have great support, let's use this library. Oh, there is a bug here, well it must be a bug in TypeScript itself or this library that doesn't use TypeScript, not Material-UI".
Most people think that marketing is cheating, I don't think so, it's quite the opposite, it's brilliant!

[rosskevin]

I believe 1. demos in typescript, then 2. tests migrated to typescript would yield the biggest benefit. Moving the source files there would be great from a ts-user standpoint (and generally understanding the codebase), but I also understand the non-ts user perspective so I am not strongly advocating either way. Certainly my personal perspective is pro-ts.

I do believe that tests in ts/tsx would very much help surface ts issues, similar to getting demos to ts/tsx.

[eps1lon]

I do believe that tests in ts/tsx would very much help surface ts issues, similar to getting demos to ts/tsx.

That is work that's up for grabs. You can add a // @ts-check to the unit test files in core/src and see if it type checks. See https://github.com/mui-org/material-ui/pull/16187/files#diff-4e15af19bc6a128de4ce036cdc12b862

[rosskevin]

I'd rather try changing to tsx and add the @babel/preset-typescript. If I get some time I'll try one and we can see what the changeset entails.

[eps1lon]

What would be the benefit of that?