Issue 1:
Well, not yet. We need a plan for doing so. The v1 effort started 18 months ago. We have had some interesting discussion in #9388 and #9614.

Here are the problems I want to solve all at once:

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.

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.

Some of our components are pretty stable while some aren't. Should the few unstable components prevent us from releasing the stable components earlier?

I'm proposing the following plan, any feedback is welcomed.

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.

We take advantage of @material-ui npm scope name

Effectively people imports will change:

-import { Button } from 'material-ui';
+import { Button } from '@material-ui/core';

I have opened a poll on Twitter to collect some feedback.

Pros

It will signal to the world what's official and what's not.

It will prevent any future package name clashing.

It will make the transition from v0.x to v1 much easier.

Without, it's really tricky as some external libs might be relying on material-ui@0.x while others on material-ui@1.x. In this situation, people can't have both versions installed at the same time.

They only have one option. They do the migration in one go. This solves pain point n°1 and a bit of n°2.

We can remove 2k lines of code and close #9469.

Cons

The downloads stats restart from scratch. It should only be a short time issue. It's not something I would worry about.

Overall, the Babel blog on this topic is very interesting https://babeljs.io/blog/2017/12/27/nearing-the-7.0-release.

We create a lab package

The package can be named @material-ui/lab or @material-ui/denovo as @rosskevin likes it.

What's more important is that we can leverage this package.

Pros

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 https://material-ui.com to http://material-ui.com.

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".

Having a lab package is creating a clear contract. People know what they can expect from the components. It's solving problem n°2.

Releasing a high-quality component is a time-consuming process. People feedbacks are critical. Having a lab package can encourage people giving feedback.

We can do more experimentations.

Cons

We will need to set up the infrastructure needed for such package.

Overall, the Blueprint approach in interesting to have a look at http://blueprintjs.com/docs/#labs.

mono-repository ❤️

No matter what. I think that we should try very hard to keep the project in a single GitHub repository.

cc @mui-org/core-contributors

Issue 2:
It's actually WebStorm bug, but they fix bugs lots of time. New beta.17 component exports look like this:

declare const AppBar: React.ComponentType<AppBarProps>;
export default AppBar;

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.

For auto-complete and props suggestion working I should create wrappers:

import * as React from 'react';
import {default as MuiAppBar, AppBarProps } from 'material-ui/AppBar';

class AppBarDumb extends React.Component<AppBarProps> {}
export default (cl => MuiAppBar)(AppBarDumb);

I have searched the issues of this repository and believe that this is not a duplicate.

Possible solution

Return back type definitions of classes, not constants of ComponentClass types.

Tech
Version

Material-UI
1.0.0-beta.17

Typescript
2.4.2

React
16.0.0