Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Remove typings for @material-ui/core/es #14392

Closed
eps1lon opened this issue Feb 3, 2019 · 2 comments
Closed

[RFC] Remove typings for @material-ui/core/es #14392

eps1lon opened this issue Feb 3, 2019 · 2 comments

Comments

@eps1lon
Copy link
Member

eps1lon commented Feb 3, 2019

Disclaimer: This can only break builds for typescript users. VSCode JS users will loose some intellisense.

We're currently duplicating our type declarations for the /es build folder to support
type definitions for imports like import Button from '@material-ui/core/es/Button'.

I propose the get rid of this duplication to reduce download size of this package and improve the typescript experience for codesandbox. Codesandbox is currently bailing out of type acquisition because it detects to many type declaration files.

This does not mean that explicit imports from the /es build are not supported anymore. Typescript/VSCode users would only have to add the following path alias to their tsconfig/jsconfig:

"paths": {
  "@material-ui/core/es*": ["@material-ui/core/*"]
}

I'm aware that this is not working for react-scripts@2.x. See facebook/create-react-app#5645

I would file this under "advanced build scenarios". The /es build does not support our supported platforms anyway and likely requires additional transpilation steps depending on your target. It shouldn't be part of your import paths and rather aliased (and processed) in your build pipeline.

/cc @mui-org/core-contributors

@oliviertassinari
Copy link
Member

oliviertassinari commented Feb 3, 2019

I'm happy with this change 👍, it's already for advanced users: https://material-ui.com/guides/minimizing-bundle-size/#ecmascript. I would expect few users relying on /es.

@joshwooding
Copy link
Member

Hopefully this change will increase the accuracy of IntelliJ choosing the correct import to auto complete. I’m happy too 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants