Material-ui: Migration to TypeScript?

[cyberhck]

• [x] This is not a v0.x issue.
• [x] 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?

[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 https://github.com/mui-org/material-ui/issues/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?

[rosskevin]

Builds with Babel and type checking with tsc?

[eps1lon]

We get type checking by adding @ts-check. An additional build pipeline is always a downside.

[rosskevin]

We are already running tsc with the script typescript in material-ui/package.json and run in ci with

      - run:
          name: Tests TypeScript definitions
          command: yarn typescript

so it is not an additional build step but an existing one. Further, are people more likely to know jsdoc(?) annotations or typescript annotations?

[eps1lon]

Further, are people more likely to know jsdoc(?) annotations or typescript annotations?

the jsdoc annotations are parsed by typescript just as regular typescript types. There's no difference there.

so it is not an additional build step but an existing one.

I thought we were talking about our unit tests. It's not strictly speaking a new build step but an additional preset that has to be configured.

We are already running tsc with the script typescript

Yes I know our CI setup quite well considering I build most of steps concerned with type checking.

To further clarify: That step already type checks Typography.test.js. If you want to include more tests you can add @ts-check to the files and add missing types (and potentially fix existing issues).

[rosskevin]

I'm not sure how @ts-check checks usage without running in tsc (I'm not familiar).

I get the sense that things like #16315 would more likely be surfaced by quite simply switching tests to tsx and including them in the tsconfig while using the standard tooling (tsc). This seems very simple, no need to annotate - just change the extension and we get better coverage.

I'm not sure doing something non-standard makes sense. Either we go towards ts, or not. My preference is clear that moving tests to tsx would be a positive:

• it would be familiar to ts users (@ts-check and jsdoc use is not as familiar as tsx)
• it would not be an extra step to ci
• it would increase coverage

[cyberhck]

Everyone knows we can easily do a partial migration and move slowly, but if maintainers don't want to give TypeScript a try, simply listing benefits won't do anything. As some of us already said we'll help migrate and do a gradual migration. I'm getting sense that they just don't want to do it. There's no point on arguing benefits or tradeoffs.

Issue title clearly says for v5 which means you can have breaking changes, some fixes which needs to be made for typescript can be done as a breaking change, and once we pass the initial friction, migrating the rest should be very easy. You don't have to turn on all the strict rules initially, you can get there gradually.

Arguing over things is just waste of time, I think the original request was we're willing to help, are you interested?

[eps1lon]

Arguing over things is just waste of time, I think the original request was we're willing to help, are you interested?

Sure. You can add @ts-check to files in ./packages/material-ui/src/**/*.test.js. This is a gradual migration strategy. I'm not sure how you get the impression we're not interested in improving types. It's a bit unfair to make these claims without being involved with the project.

[cyberhck]

The point was to start doing actual conversion, without only using @ts-check, but rather starting to change from js files to jsx files,

[eps1lon]

The point was to start doing actual conversion, without only using @ts-check, but rather starting to change from js files to jsx files,

I thought adding @ts-check would be the same as changing the extension. Is type-checking different for those two? Could you elaborate on the difference?

[cyberhck]

no, if you were to change extensions, you can inline your type definition, you can't have a javascript file like this:

const something = (): boolean => {
  return true;
}

If we start moving everything to proper typescript, the type checking will also increase, and will find potential bugs.

I'm advocating the complete move to typescript, not just type checking, which includes build system, linting and what not.

[joshwooding]

@cyberhck I don't think anyone is against the long term vision of potentially moving to TypeScript. @ts-check allows for us to start gradually migrating as @eps1lon said. I, for one, am grateful for the slower move since it allows me more time to get more comfortable with TypeScript.

[eps1lon]

Yeah I don't understand what's being proposed here. We are increasing our type coverage, we are using tslint. If the argument for ts extension is only a stylistic one then I think we don't have to put effort into it.

Also advocating for a move to linting with typescript (I guess you mean tslint?) is backwards. tslint will soon be deprecated. If anything we should look into moving to eslint 6 (released yesterday) and how we deal with dtslints expect rule in the future.

I would appreciate if the people arguing for a typescript migration would familiarize themselves with the codebase (I'm always eager to answer question and to get more people to contribute to the ts related code) before making such strong statements here.

It's easy for outside readers to get the impression that we don't test our types. Maybe something is lost in translation but I still don't understand what the difference in type checking is between .ts and @ts-check. An example would be appreciated.

[cyberhck]

Maybe I missed something, on your JS files, can you show me an instance, where you define a return type?

About the migrating to tslint, I understand your position, tslint isn't getting deprecated tomorrow, and we can always switch to eslint-typescript instead.

Changing extension is about the cognitive load when I read your js files, I don't exactly know what type your function is supposed to get by looking at your code, I've to open yet another file just to do that,

When I'm contributing, having ts files and having parameter type, return types right there gives me a knowledge of what's supposed to happen.

And also can you also mention what'd be the downside of changing the extension to tsx/ts if you're so sure with @ts-check is the same?

Like in my previous comment, you can't have a js file like this:

const something = (): boolean => {
  return true;
}

if it were a ts file, just by looking at code, I know I'm supposed to return a boolean

[eps1lon]

Just wanted to give a quick update on the current state: I'm in the process of re-examining the current state of typescript with regards to type patterns for react components. After that I'll summarize what would be necessary to migrate. That doesn't mean we will migrate.

To give a quick TL;DR as to why there are so many unsolved issues and why we haven't converted yet: Polymorphic components are hard.

I would appreciate it if anybody who casually drops a "converting to typescript would solve your issues" or "just convert, it's not hard" does some research on the topic first (Writing Type-Safe Polymorphic React Components is a very good starting point). If you have any insights or experience with polymorphic components I would love to hear from you.

[oliviertassinari]

If it does have to come to a TypeScript migration, I think that we should be open to the option and consider it. We can turn people perceived value and psychology in our favor. Plus, it's not all fake, I think that we can agree that a TypeScript migration could help, at least, a little.

[mbrookes]

Or it could hurt more than it helps.

Take Framer, since that is top of mind for me at the moment. The components are written as tsx files, so I have tried to use Typescript (understanding that they could be plain js despite the extension). When my wrapper components work as expected, it's all good; but when they don't, I hit a wall.

Sure, that is down to my inexperience with TS. But by migrating the components to typescript, we are introducing a barrier to potential contributors in a similar position, and this may barrier may be greater than the benefit as a whole. (Unless and until TS overtakes JS).

[cyberhck]

I don't wanna stretch this conversation any longer, but I keep getting at same point, js files != ts files despite the @ts-check, and maybe that's what weighing you down, I'm not saying it'll all be candies and unicorn, because it definitely not.

When you use JS files, you rely on having type definitions, and someone updating them, in ts files, you can define methods with return types, on js, you define methods, and go to typing file, then update the definition (and now think of what happens to those methods for which people didn't define types.

with ts you can have strict checking, you can setup ways where you HAVE to define return types

And come to contributors, I personally feel, because they know exactly what to pass as a property when they call a method or render a component, (and typescript would help them), the time it'd take for TS users to be able to productive and contribute would be far less than with JS (because you've no idea what to pass to a function, I know you already have @ts-check, but I'm making the point for ts)

this thread is taking way longer and my notification gets triggered often, I'm unsubscribing from the thread, I hope you guys go all in with TS :)

[eps1lon]

Disclaimer: Yes I am a bit annoyed about this topic. Anybody who thinks I called them out unfairly should rest assured that this wasn't targeted at them.

I decided not to pursue this since maintainers don't seem interested, I'll just use another framework.

I'm not leaving this here without response regardless of the intention: We are interested but not actively pursuing this. The amount of work that would be involved here and upstream (typescript, @types/* and the wider ecosystem) is not worth it at the moment.

Not using a library because it's not written in typescript is misguided (at face value this argument is non-sensical). Outstanding issues with typescript are not magically resolved by migrating to typescript. It's like saying rewriting the library using only native DOM APIs would solve all outstanding issues with using this library and native DOM APIs (e.g. #17660)

I want to also point out to passive readers that the people arguing for the migration to typescript didn't work with the repository for the past 6+ months or never have worked with the repository in the first place (opening PRs or sharing actual code workarounds). So anybody arguing for a migration and not putting in any work should take a look in the mirror and ask themselves who is not interested in this issue.

[oliviertassinari]

Reopening as we link this issue as potential improvement in the Roadmap

The definitions. We are continuously improving them. For instance, we are working on moving the props descriptions to TypeScript, so you can access them directly from your IDE. The codebase is written in JavaScript, we don't plan on migrating it to TypeScript in the near future. Upvote #15984 if you want us to rewrite the core in a future version.

https://material-ui.com/discover-more/roadmap/

[yordis]

@eps1lon I am annoyed by that person, laughing at your response because it got under your skin, and also worry about you because you let that happen.

We love, cheer up, and support you.

Having patience, and understanding people's emotions are the cost of popularity and OSS.

I want you and OSS maintainers to be happy. But we can't do anything about these situations other than understanding their childish and emotional behaviors and focus on what matter.

We signed off for these comments, please don't let this affect you.

[oliviertassinari]

An update on our progress toward TypeScript

What we have done

• We have migrated all our demos to TypeScript. This change seems to be the one that yields the most benefit. For instance (lead by @eps1lon):

https://github.com/mui-org/material-ui/blob/7994e11de8c02b9480efb927a8042939ad05ac5c/docs/src/pages/components/autocomplete/ControllableStates.tsx#L7-L8

• We have moved all source of truth of all the props from prop-types comments to TypeScript comments (lead by @eps1lon). This is valuable as it forces us to think about the TypeScript public interface first.

https://github.com/mui-org/material-ui/blob/7994e11de8c02b9480efb927a8042939ad05ac5c/packages/material-ui-lab/src/Autocomplete/Autocomplete.d.ts#L151-L157

• We have fixed a bunch of TypeScript issues.

Observations

• Looking at the feedback from this year's survey, we have seen a lot fewer people asking for improvement in the TypeScript types, 60% less https://material-ui.com/blog/2020-developer-survey-results/.
• In the survey, almost half of the participants were using TypeScript, JavaScript was still more popular but by a small margin.
• 14% of the sessions on the documentation are made with TypeScript as the default variant for the demos (not JavaScript). The figure is slowly increasing.
• TypeScript is on position number 4, which is not negligible. We asked people to include only 3 items among the list.
  https://material-ui.com/blog/2020-developer-survey-results/#6-what-are-your-key-criteria-when-choosing-a-ui-library

What we are working on

Improving our component infrastructure to support sources in TypeScript. For instance #21758.

• We are moving the date pickers components in the @material-ui/lab package #19706. The component is written in TypeScript.
• The repository for the advanced components of Material-UI is written in TypeScript: https://github.com/mui-org/material-ui-x.

Future?

• Should we have TypeScript as the default toggled language for the demos?
• Should we migrate our existing tests to TypeScript?
• Any proposal?

At this point, it doesn't seem that we need to willingly dedicate time to the problem. TypeScript is organically gaining usage in our codebase. It seems that we can sleep on it, and focus on other problems 🤔.

[yordis]

Should we migrate our existing tests to TypeScript?

This could be a way to validate the experience of the typespec but can get really annoyed and full of @ts-ignore in some test cases where you mock things.

Should we have TypeScript as the default toggled language for the demos?

I wouldn't, TypeScript has a cost, and most developers out there are not being taught in TypeScript as the first language. Personally, has been few years in TypeScript and I know I am not the norm (compared with the entire Front End ecosystem not just React) so I don't mind toggling.

That being said, use local storage, and save the configuration there, most likely if I switched is because I am interested in TypeScript over JavaScript.

At this point, it doesn't seem that we need to willingly dedicate time to the problem. TypeScript is organically gaining usage in our codebase. It seems that we can sleep on it, on focus on other problems 🤔.

Is there any process on wich I could find the series of steps to convert the codebase or help in any way?

I haven't look much but having a process that you could share with everyone outside the core team could open the door for more streamed line collaboration.

[dtassone]

I believe that we all want to build the best and most reliable set of react components ever written.
And one of the tools that can help us achieve this is Typescript, due to its type safety feature primarily.
So the goal would be to bring type safety in components and also support all teams that use typescript with properly generated declaration files (very important for all the TS teams out there).

As part of the core team today, we now have 2 big components written in typescript, date-pickers and the data-grid.
As well as all future development, part of the X project will be written in typescript.

Therefore it seems to me that now would be the right time to handle the pain and migrate every component in core and lab to typescript.
From my experience, a migration is always a bit of a pain and for this reason, things are easier to do on a short term big bang conversion than trying to support a half and half transition period. That makes things even more painful and does not really work well on the long term.
If you do short term, you can ditch the old tools straight away, and start from fresh after the migration and you end up in a much better situation at the end of the migration.
Secondly, when you migrate, 1 component, then 2 and 3, you get faster and faster so big bang migration are actually pretty efficient from my experience.

Also Typescript is very well supported by all the tools we use and it's pretty mature now, so the risk is limited.

[oliviertassinari]

I wouldn't, TypeScript has a cost, and most developers out there are not being taught in TypeScript as the first language.

@yordis Agree, I think that we can reevaluate this TS vs JS demo default decision in one year, with the 2021 developer survey results and with how the usage of the TypeScript demos grows. Yes, the choice of TypeScript vs JavaScript demos is persisted between sessions on the documentation, with a cookie: 15% (TS) vs 75% (JS).

Is there any process on wich I could find the series of steps to convert the codebase or help in any way?

We don't have any steps to perform the migration as we don't have any components yet fully written in TypeScript in the core infrastructure. The challenges that are left to be solved for doing such, cc @dmtrKovalenko:

• Writing the tests in TypeScript. There are a few changes in the configuration to move from material-ui-x to material-ui repository in order to have tests like XGrid.test.tsx work, nothing major. I recall 1, 2, and 3
• Have the logic that generates the prop-types object, handle the type definitions from .tsx input, not .d.ts input. (we miss the prop-types generation in material-ui-x)
• Have the logic that generates the API pages of the documentation handle the extraction of the information from the types, not the prop-types. (we miss the API generation in material-ui-x from the types, there is some early exploration but nothing in production). I believe @eps1lon is working on it, starting with the main repository.

Once we have that, we can do the migration as a background task, and ideally engage the community to do it, I have no doubt they will be happy to help, so the core team might just have to focus on reviewing migration pull requests from the community. During the JavaScript demos to TypeScript demos migration era, I believe the majority of the migration was done by the community, once Sebastian put the infrastructure in place to support it.

I believe that we all want to build the best and most reliable set of react components ever written.
And one of the tools that can help us achieve this is Typescript

@dtassone We have discussed this a bit in the past, at this point, for instance, if we look at the current open TypeScript issues or the problem we face, or even what people ask from us in the user-survey, the value of migration to TypeScript wouldn't be most about its intrinsic value but more about the perceived one by the community, where people wrongly approximate written in TypeScript with great to be used in a TypeScript codebase and higher code quality (I would argue that higher code quality is not strongly correlated, especially when we add defensive logic instead of @ts-ignore).

At this point, I think that the main incentive we can have for migration to TypeScript is:

1. Because it helps us with the logic that involves manipulating objections from a bunch of different directions, why we have the DatePicker and DataGrid uses TypeScript or even why https://github.com/mui-org/material-ui/pull/22055.
2. Because it has marketing and perceived value. Because of people associate TypeScript sources with higher-quality code and easier to use in a TypeScript codebase.

If you do short term, you can ditch the old tools straight away, and start from fresh after the migration and you end up in a much better situation at the end of the migration.

IMHO this wouldn't be the best option. I think that we should only do "big bang" when no other progressive approaches are sustainable. In this case, we are lucky to have TypeScript as an optional enhancement, that we can deploy progressively, so should we.

What do you have in mind with "ditch"?

---

Going back to the marketing value, there is one metric we might want to optimize for, this one:

GitHub determines the % by looking at the number of files, no matter how many lines there are (at least it seems). We have 8792 JavaScript files and 472 TypeScript files. So TypeScript is 5% (=472/(8792+472)). However, if you look closer, you will find that among all these JavaScript files there are 6578 generated icons, which are very small files and arguably we could consider having them written in TypeScript as there are generated types definitions and type tests. For instance, with this diff, using https://github.com/github/linguist:

diff --git a/packages/material-ui-icons/src/.gitattributes b/packages/material-ui-icons/src/.gitattributes
new file mode 100644
index 000000000..282f21f32
--- /dev/null
+++ b/packages/material-ui-icons/src/.gitattributes
@@ -0,0 +1 @@
+*.js linguist-language=TypeScript

we would go up to:

which seems more accurate to the state of the codebase. Thoughts?

[dtassone]

progressive approaches are sustainable. In this case, we are lucky to have TypeScript as an optional enhancement, that we can deploy progressively.

If you think about it there is no point in being progressive on this one. It's not like converging towards a certain API
Converting one component in JS to TS can all be done in one go. No big breaking changes, yes some issue here and there...
Then we can align all repo and build every libraries with rollup (preferred tool for libs) & typescript, so replace the current builder
Work towards a better release pipeline, unified. No need to maintain this, that and common... => the cost of being progressive comes from maintaining the transition. We need to do this before we can do that. Slower migration as we merge one component, do other things (forget) then merge another.

[oliviertassinari]

Converting one component in JS to TS can all be done in one go

@dtassone What's the smallest unit of codes we can incrementally migrate? I believe it's each .js file, individually, the ones that are behind each .d.ts file. So, we should be able to migrate each file one after the other. Considering we have over 100 d.ts files, I would expect that we can do the TypeScript migration with over 100 iterations (pull requests), iterations we can empower the community with.

There is no point in being progressive on this one

Taking a step back, I think that progressiveness should be our default answers to problems until we see strong values for not applying it. The value of progressiveness or working with small iterations is about all about: shorter feedback loop (the most important IMHO, to hit reality as fast as possible), delivering value to production more often, more flexibility. A core principle of Agile software development.

I don't fully understand the problem you are referring to by maintaining different build steps during the transition. Do you have more details? I don't see what needs to be maintained.

Then we can align all repo and build every library with rollup (preferred tool for libs) & typescript, so replace the current builder

I don't see the direct link between the TypeScript migration and the build step. Shouldn't we discuss the two individually? Do you want to open a new issue? Maybe you would like to engage in #18447?
Also, don't forget that Babel in the equation, it's an important part of the build. We leverage a couple of Babel plugins to optimize the published files on npm. I wrote about some of the Babel plugins we use a long time ago.

[mbrookes]

Since migration of core components to TS isn't a priority right now, further discussion is somewhat moot; so I'd rather we didn't spend more time on it.

[dmtrKovalenko]

You already spent so much time on supporting out-of-the-box typescript definitions and fixing small type-related issues so you will be able to migrate all the sources several times.

[oliviertassinari]

further discussion is somewhat moot

If we go back to the user-survey of 2020, we have almost half the respondents that mention using TypeScript, we also have "TypeScript integration" ranking at position 4 in the question: What are your key criteria when choosing a UI library? So the broader TypeScript topic is important (I'm not saying that migration is important, current metrics suggest it shouldn't be in the top of our priorities).

Should we close this issue?

• We are working on this problem, as a background task, at a priority level, that seems to match with what has a higher ROI and lower opportunity cost. Right now, it has a relatively low priority level. We can ask the community to contribute once we are ready.
• Many developers have upvoted the issue, I think that we can communicate that we are interested in feedback from the community, by keeping it open.
• I don't think that suppressing voices will resolve underlying issues (flawed thought process, inaccurate information, etc). I think that it will delay things that, usually, make the situation worse. Quite the opposite, I think that it's healthy to keep hearing constructive argumentation around the topic, especially if it can lead to more clarity in the thought process and agreed on facts of the core team.

[cyberhck]

I had unsubscribed from this issue, but wow, a lot has changed since I first asked for this.
First off a huge thanks to maintainers for looking into this, and moving forward.

I didn't even think this many people would be favoring migration to TypeScript.

For the people who just want the typing, I believe the current state of typing provided is very good, and more and more codebase is being written in TypeScript, so this definitely has good TypeScript support.

I want to state one more time, the issue was created in spirit of helping maintainers and new contributors, the end users already have it pretty good (except there's more possibility of having typing bugs, but that barely happens and when it does, creating one issue is all it takes for maintainers to fix it)

I do want to add a few things which got lost in conversation.

• I do not want maintainers to invest too much time doing a big bang migration, that'll make the feature release slower (I mean, I'm not expecting them to do this for our sakes)
• I do believe changing as we go (gradual change) is the way to go.
• About tests, till all the source files are converted I think keeping tests in JS is I think more fruitful because in case we introduce a bug, existing test will catch it, and once we know we've migrated source files, then we can convert tests to typescript as well :)

Huge thanks to @eps1lon for his contribution :)

[rajzik]

Hello, guys Airbnb just released a new tool for migration huge javascript basis to typescript:
https://github.com/airbnb/ts-migrate

Couldn't this help with the migration?

[eps1lon]

Couldn't this help with the migration?

Not really since the little nuances that this tool doesn't cover are why we wouldn't gain anything from the migration.

[eps1lon]

We have the infrastructure in place to write modules and tests in TypeScript and already have some tests and modules (public and private) written in TypeScript and we'll continue porting JS files to TypeScript where appropriate.

Components are not considered appropriate currently. On one hand because we don't think writing components in TypeScript solves an actual issue. If you disagree please refer to an existing issue (and we'll try to resolve it separately) or open a new one. This keeps the discussion focused. On the other hand TypeScript has some limitations that make this task hard. I've created a playground with a minimal component written in JS. If you're able to convert it to TypeScript please let us know. Changing type-tests is reasonable if a strong argument is made for your implementation. Playground: Minimal Material-UI component in TypeScript base