TSC should compile in about 3-8 seconds.
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)
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!!!
| Tech | Version |
|--------------|---------|
| Material-UI | v1.2.2 |
| React | latest |
| browser | |
| etc | |
This is an issue with Typescript, not with MUI. There is nothing MUI can do about this
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, notifications@github.com 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
https://github.com/mui-org/material-ui/issues/11916#issuecomment-398345551,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHdk5-rU0KaHFNzTxM4-V9Oe4ZHcoT8oks5t-Mw3gaJpZM4UtG9x
.
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.
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.
I'm getting assistance on this issue:
https://github.com/Microsoft/TypeScript/issues/25085
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.
@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.
closing the issue, as it has been addressed. More details are in the ticket linked above.
@rpmonteiro What did you do to fix this issue?
@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';
Most helpful comment
@manpreetnarang instead of
Do this: