-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[Alert] Move from lab to core #22651
Conversation
@mbrookes What do you think about we re-export the Alert in the lab from the core up until v5.1.0. This would avoid forcing developers to rename imports when they update the dependency. Making the migration a bit smoother. |
I was going to do that for 4.x (with deprecation warnings), but sure, we could do that here too. |
3c2045c
to
1946412
Compare
@mbrookes What's the advantage of doing it for v4? I think that we could only handle v5, the components are unstable in v4. Would making the lab components stable in v4 conflict with the objective to make them stable as an incentive to upgrade? What about if we need to make a breaking change to them? |
@material-ui/core: parsed: +1.34% , gzip: +0.98% |
Deprecation warnings.
Not stable in core v4, just deprecated in lab v4 (when lab v5 is release), but perhaps that's overkill? |
de997b3
to
a0cf0a0
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Why the heck is the API docs generator script checking for the presence of unit tests? |
To verify that the documented behavior is actually implemented. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not recommend duplicating the component to prevent bundling it twice. We already introduce breaking changes to apply consistent prop naming so I don't think we need to start being careful now. Especially because imports are codemod-able.
Then we automatically avoid potential documentation conflicts by having one component in two packages.
What's the plan here? |
I've forgotten what goes into an empty type definition file...
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
ea8ad32
to
7d9fbec
Compare
@@ -3,6 +3,9 @@ import Alert from '@material-ui/core/Alert'; | |||
|
|||
let warnedOnce = false; | |||
|
|||
/** | |||
* @ignore - do not document. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, of course! 🤦
From my perspective, we don't need any backport for this in v4, nor will we for any of the other components we move from the lab to the core. Making the import from lab still work already fulfill the objective of making the v4 -> v5 switch easy. |
Yes – some of the components have been in the lab for so long, I almost forgot that it's perpetually breaking! 🙂 |
Missing https://github.com/mui-org/material-ui/blob/next/packages/material-ui/src/styles/components.d.ts MuiAlert from material-ui/labs typescript in v5.0.0-alpha.12 |
@povilass Thanks for raising it. Do you want to submit a pull request to fix it? |
#23028 here you go @oliviertassinari |
Breaking changes
[Alert] Move the component from the lab to the core. The component will become stable.