Typescript pulling all MUI files - super slow compilation

[rpmonteiro]

• This is a v1.x issue (v0.x is no longer maintained).
• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

TSC should compile in about 3-8 seconds.

Current Behavior

TSC takes over 1 minute to compile, because it's pulling the entire library, with over half a million types.
running tsc --extendedDiagnostics --listFiles --noEmit

and it goes on...

If I remove the MUI folder (resulting in lots of errors of course)

Context

I'm only using 10 components in the entire app, all imported like this:
import CircularProgress from '@material-ui/core/CircularProgress/CircularProgress';

It should only import the relevant files and types.

My tsconfig:

{
  "compilerOptions": {
    "baseUrl": "./src",
    "outDir": "build/dist",
    "target": "es5",
    "lib": ["es6", "es7", "dom"],
    "sourceMap": true,
    "allowJs": false,
    "jsx": "react",
    "esModuleInterop": true,
    "skipLibCheck": true,
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "rootDir": "./src",
    "noEmitOnError": false,
    "isolatedModules": true,
    "strictPropertyInitialization": false,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "noErrorTruncation": true,
    "noImplicitReturns": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "strictNullChecks": true,
    "diagnostics": true,
    "suppressImplicitAnyIndexErrors": true,
    "noUnusedLocals": true
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "dist",
    "build",
    "node_modules",
    "src/**/__tests__"
  ],
  "defaultSeverity": "warning"
}

My @types folder:

Any ideas why this happens?

Thank you for your help!!!

Your Environment

Tech	Version
Material-UI	v1.2.2
React	latest
browser
etc

[Pajn]

This is an issue with Typescript, not with MUI. There is nothing MUI can do about this

[rpmonteiro]

May I ask you to expand a bit on that thought? Have you come across something similar before?

…

On Tue, 19 Jun 2018, 12:02 Rasmus Eneman, ***@***.***> wrote: This is an issue with Typescript, not with MUI. There is nothing MUI can do about this — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11916 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHdk5-rU0KaHFNzTxM4-V9Oe4ZHcoT8oks5t-Mw3gaJpZM4UtG9x> .

[Pajn]

MUI only provides types for its components, it can not control how the TS compiler chooses to load and parse any files. It is a big library which is why you might see bigger impact from MUI than other libraries but it is big because it provides a lot of things, not because of an error.

More clever loading of files, improved handling of many files etc. is up to the compiler.

[rpmonteiro]

If this was the case for other people, then this repo would be swamped with people complaining about astronomical build times. It seems this is a fringe case. Maybe someone has come across this before... or can spot something with my config that I'm missing.

[rpmonteiro]

I'm getting assistance on this issue:
microsoft/TypeScript#25085

[weswigham]

This is an issue with Typescript, not with MUI. There is nothing MUI can do about this

@Pajn
Actually while we definitely do (did? we should be publishing a fix on nightlies tonight) have a perf problem, there's an issue in MUI that is causing us to do more work than we should need to for a given deep import, too (which is why the file count goes up so much with a single component import)! Specifically, you have imports like this one:

import { StandardProps } from '..';

That import references the root index.d.ts - your root index.d.ts imports all components (to reexport them), causing us to load every type definition in MUI (we won't typecheck them unless requested, but we will load them all from disk and parse them, which has a cost). If you moved your utilitity types like StandardProps into a separate file from the root index.d.ts and did a direct import of them, it would cut down on the fileset loaded for a given component fairly significantly.

[Pajn]

@weswigham

First of all, just so it's clear. I'm not involved in MUI, I'm just a pretty active user of it.
Secondly, awesome track down and fix in TS! I did not mean anything negative against you or anyone on the TS team.
What I did mean was that even if the imports were more cautious that would only delay the problem until you use more of MUI. However that's still a good optimization for people not using the majority of the MUI components.

I was under the impression though that you still had to parse all distributed .d.ts file to find out if there are declare global declarations in them. But that might very well be completely false.

[rpmonteiro]

closing the issue, as it has been addressed. More details are in the ticket linked above.

[manpreetnarang]

@rpmonteiro What did you do to fix this issue?

[jtreminio]

@manpreetnarang instead of

import {
  AppBar,
  Button,
  Hidden,
  IconButton,
  Toolbar,
} from '@material-ui/core';
import { Menu } from '@material-ui/icons';

Do this:

import AppBar from '@material-ui/core/AppBar';
import Button from '@material-ui/core/Button';
import Hidden from '@material-ui/core/Hidden';
import IconButton from '@material-ui/core/IconButton';
import Toolbar from '@material-ui/core/Toolbar';

import Menu from '@material-ui/icons/Menu';

[zakton5]

For anyone still having this issue with VS Code, I had to disable typescript.tsserver.experimental.enableProjectDiagnostics. Turns out that setting just pulls all of node_modules typescript files constantly including MUI's which slowed my machine to a crawl.