-
Notifications
You must be signed in to change notification settings - Fork 4.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
Components: Remove "experimental" designation #60837
Changes from 2 commits
ce4f638
51d389b
ddaca25
65049e0
ddf0218
752a07f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -12,7 +12,10 @@ export { | |||||
} from '@wordpress/primitives'; | ||||||
|
||||||
// Components. | ||||||
export { default as __experimentalAlignmentMatrixControl } from './alignment-matrix-control'; | ||||||
export { | ||||||
default as __experimentalAlignmentMatrixControl, | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. While I appreciate that we're keeping the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are so many "shades" of deprecation — hard, soft, TS-only, TSDoc only... 😂 For these I think a TSDoc There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup, it's odd that deprecation can be so complex 😅 Anyway, imagine I'm a plugin dev that uses some experimental components in my plugin. How will a TSDoc There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I managed to make the export {
/**
* @deprecated Since version X.X. Will be removed in version X.Y. Use `ConfirmDialog` instead.
*/
ConfirmDialog as __experimentalConfirmDialog,
ConfirmDialog,
} from './confirm-dialog'; I can confirm it doesn't affect the second export there: And of the So I assume all editors/IDEs that support tsdoc will warn users about it. If that's a good way to prevent developers from continuing to use it, that is another story. It might be good to do the deprecation gradually? First soft-deprecate using a tsdoc, announce in the changelog and perhaps a Make post, then in another (major?) version, completely remove the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nice 👍 And yeah, gradual deprecation sounds good to me. We should likely document the plan for that in the related issue, including some releases where we aim to further/hard deprecate. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
My current stance on this is,
If the answer is "no" to both questions, we shouldn't log a console warning and we shouldn't block the TS from compiling. We shouldn't demand a dev's attention for what is essentially a housekeeping detail. If they care about housekeeping details, they'll do it. And to be clear, personally I don't think the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, the complex deprecation discussion again 😅 I think we have far too many cases that are cheap/free to maintain, but because we have too many, it adds so much noise. I wish we had a clear deprecation policy that actually allows us to get rid of deprecated features at some point. If I come back to planet Earth though and draw a line on the tradeoffs, you're right and it should be just fine to continue soft-deprecating as suggested. |
||||||
AlignmentMatrixControl, | ||||||
} from './alignment-matrix-control'; | ||||||
export { | ||||||
default as Animate, | ||||||
getAnimateClassName as __unstableGetAnimateClassName, | ||||||
|
@@ -33,6 +36,10 @@ export { | |||||
hasSplitBorders as __experimentalHasSplitBorders, | ||||||
isDefinedBorder as __experimentalIsDefinedBorder, | ||||||
isEmptyBorder as __experimentalIsEmptyBorder, | ||||||
BorderBoxControl, | ||||||
hasSplitBorders, | ||||||
isDefinedBorder, | ||||||
isEmptyBorder, | ||||||
Comment on lines
+40
to
+42
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, these three exports are sounding major alarm bells for me 😱 Not sure what's going on there. Let's keep these experimental for now so we can investigate and figure out a better way. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See: #61135 |
||||||
} from './border-box-control'; | ||||||
export { BorderControl as __experimentalBorderControl } from './border-control'; | ||||||
export { | ||||||
|
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.
Let's not touch the
*.native.js
stuff for now, they are completely separate.