<p dir="auto"><strong>Well, not yet</strong>. We need a plan for doing so. The v1 effort started 18 months ago. We have had some interesting discussion in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="279093101" data-permission-text="Title is private" data-url="https://github.com/mui/material-ui/issues/9388" data-hovercard-type="issue" data-hovercard-url="/mui/material-ui/issues/9388/hovercard" href="https://github.com/mui/material-ui/issues/9388">#9388</a> and <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="284472596" data-permission-text="Title is private" data-url="https://github.com/mui/material-ui/issues/9614" data-hovercard-type="pull_request" data-hovercard-url="/mui/material-ui/pull/9614/hovercard" href="https://github.com/mui/material-ui/pull/9614">#9614</a>.<br>
Here are the problems I want to solve all at once:</p>
<ol dir="auto">
<li>How can we make the migration from v0.x to v1 as smooth as possible? Right now, people have to do it in a single batch. It's very hard.</li>
<li>How can we scale the number of components we support? The community has been building a lot of components on top of Material-UI, with large quality distribution.</li>
<li>Some of our components are pretty stable while some aren't. Should the few unstable components prevent us from releasing the stable components earlier?</li>
</ol>
<p dir="auto">I'm proposing the following plan, any feedback is welcomed.<br>
If we follow it. I'm expecting the to see  the first v1 stable release of our components in a month or two and to complete it in 6 months or so.</p>
<h2 dir="auto">We take advantage of <code class="notranslate">@material-ui</code> npm scope name</h2>
<p dir="auto">Effectively people imports will change:</p>
<div class="highlight highlight-source-diff notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="-import { Button } from 'material-ui';
+import { Button } from '@material-ui/core';"><pre class="notranslate"><span class="pl-md"><span class="pl-md">-</span>import { Button } from 'material-ui';</span>
<span class="pl-mi1"><span class="pl-mi1">+</span>import { Button } from '@material-ui/core';</span></pre></div>
<p dir="auto">I have opened <a href="https://twitter.com/olivtassinari/status/947161769528655888" rel="nofollow">a poll on Twitter</a> to collect some feedback.</p>
<h3 dir="auto">Pros</h3>
<ul dir="auto">
<li>It will signal to the world what's official and what's not.</li>
<li>It will prevent any future package name clashing.</li>
<li>It will make the transition from v0.x to v1 much easier.<br>
Without, it's really tricky as some external libs might be relying on <a href="mailto:material-ui@0.x">material-ui@0.x</a> while others on <a href="mailto:material-ui@1.x">material-ui@1.x</a>. In this situation, people can't have both versions installed at the same time.<br>
They only have one option. <strong>They do the migration in one go</strong>. This solves pain point n°1 and a bit of n°2.</li>
<li>We can remove 2k lines of code and close <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="281071814" data-permission-text="Title is private" data-url="https://github.com/mui/material-ui/issues/9469" data-hovercard-type="issue" data-hovercard-url="/mui/material-ui/issues/9469/hovercard" href="https://github.com/mui/material-ui/issues/9469">#9469</a>.</li>
</ul>
<h3 dir="auto">Cons</h3>
<ul dir="auto">
<li>The downloads stats restart from scratch. It should only be a short time issue. It's not something I would worry about.</li>
</ul>
<p dir="auto">Overall, the Babel blog on this topic is very interesting <a href="https://babeljs.io/blog/2017/12/27/nearing-the-7.0-release" rel="nofollow">https://babeljs.io/blog/2017/12/27/nearing-the-7.0-release</a>.</p>
<h2 dir="auto">We create a lab package</h2>
<p dir="auto">The package can be named <code class="notranslate">@material-ui/lab</code> or <a href="https://en.wikipedia.org/wiki/De_novo" rel="nofollow"><code class="notranslate">@material-ui/denovo</code></a> as <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/rosskevin/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/rosskevin">@rosskevin</a> likes it.<br>
What's more important is that we can leverage this package.</p>
<h3 dir="auto">Pros</h3>
<ul dir="auto">
<li>Right now we can consider all our components as belonging to the lab. But as we solve all the core issues and stabilize some components, we can start promoting and gradually components from lab to core (stable). It's solving problem n°3. v1 will be complete once we merge v1-beta into the master branch and we move <a href="https://material-ui.com" rel="nofollow">https://material-ui.com</a> to <a href="http://material-ui.com" rel="nofollow">http://material-ui.com</a>.</li>
<li>Let's say we ship X, a new component as soon as we merge the pull-request. People might jump to conclusion. "X is buggy, I bet the other components are the same. I'm not going to use this crap".<br>
Having a lab package is creating a clear contract. People know what they can expect from the components. It's solving problem n°2.</li>
<li>Releasing a high-quality component is a time-consuming process. People feedbacks are critical. Having a lab package can encourage people giving feedback.</li>
<li>We can do more experimentations.</li>
</ul>
<h3 dir="auto">Cons</h3>
<ul dir="auto">
<li>We will need to set up the infrastructure needed for such package.</li>
</ul>
<p dir="auto">Overall, the Blueprint approach in interesting to have a look at <a href="http://blueprintjs.com/docs/#labs" rel="nofollow">http://blueprintjs.com/docs/#labs</a>.</p>
<h2 dir="auto">mono-repository <g-emoji class="g-emoji" alias="heart" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/2764.png">❤️</g-emoji></h2>
<p dir="auto">No matter what. I think that we should try very hard to keep the project in a single GitHub repository.</p>
<p dir="auto">cc @mui-org/core-contributors</p>
<p dir="auto">It's actually WebStorm bug, but they fix bugs lots of time. New beta.17 component exports look like this:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="declare const AppBar: React.ComponentType&lt;AppBarProps&gt;;
export default AppBar;
"><pre class="notranslate"><code class="notranslate">declare const AppBar: React.ComponentType&lt;AppBarProps&gt;;
export default AppBar;

</code></pre></div>
<p dir="auto">Webstorm does not recognize props of such exported components in TSX files and props suggestions and auto-completing not works. It only recognizes when somewhere the class or stateless function is declared.</p>
<p dir="auto">For auto-complete and props suggestion working I should create wrappers:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="import * as React from 'react';
import {default as MuiAppBar, AppBarProps } from 'material-ui/AppBar';

class AppBarDumb extends React.Component&lt;AppBarProps&gt; {}
export default (cl =&gt; MuiAppBar)(AppBarDumb);"><pre class="notranslate"><code class="notranslate">import * as React from 'react';
import {default as MuiAppBar, AppBarProps } from 'material-ui/AppBar';

class AppBarDumb extends React.Component&lt;AppBarProps&gt; {}
export default (cl =&gt; MuiAppBar)(AppBarDumb);
</code></pre></div>


<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> I have searched the <a href="https://github.com/callemall/material-ui/issues">issues</a> of this repository and believe that this is not a duplicate.</li>
</ul>
<h1 dir="auto">Possible solution</h1>
<p dir="auto">Return back type definitions of classes, not constants of ComponentClass types.</p>
<table role="table">
<thead>
<tr>
<th>Tech</th>
<th>Version</th>
</tr>
</thead>
<tbody>
<tr>
<td>Material-UI</td>
<td>1.0.0-beta.17</td>
</tr>
<tr>
<td>Typescript</td>
<td>2.4.2</td>
</tr>
<tr>
<td>React</td>
<td>16.0.0</td>
</tr>
</tbody>
</table>