Remove deprecated APIs from the components package #46105
Conversation
youknowriad
added
[Feature] UI Components
|
I thought, per #40316, we no longer removed deprecated public APIs. Recent example #45195 (comment). |
|
Size Change: -257 B (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
|
@Mamaduka That's not what I understood, for me, there's always a need to remove the APIs, especially the JS ones to reduce the bundle size as otherwise we'll be hurting the user experience for users of the latest versions. What I understand is that we should be following WP approach related to deprecations and API removals which is basically:
Similar process happened in Core for jQuery upgrade as an example. |
|
@adamziel might have more details on the final decision. I think we should also document this for easier reference in the future. |
|
To give move context, we have more examples of props that we'd like to remove — as George mentioned above, a few props from Recent conversations gave us the impressions that we are not really able to remove those props, although my personal view is very similar to Riad's |
|
I agree we need a clear guideline, I feel like we're discussing the same things over and over. It's clear to me that if we don't want to harm users and end in an unhealthy state we need to be able to give time, assess and remove APIs. A process we've followed for some time now and that worked pretty well IMO. |
I'd like to +1 both opinions here. Putting generalisations aside, this particular PR touches on fairly niche APIs, and they have been deprecated since at least 5.6 but going back to 5.4 — 26 months ago. IMO we should be able to just merge. |
|
As a comparison, the jQuery migration is more impactful by an order of magnitude and IIRC, developers only had like 6 months between the official deprecation and the upgrade. |
|
To be clear: I'm also for removing bloat from the packages and reducing the bundle size. |
|
Absolutely. I'd love to discuss and agree on a well-established strategy for deprecating and removing code, of course giving ample time and warnings for folks to adapt to those changes. We do want to avoid breaking changes as much as possible, but the inability to deprecate/delete old code can hinder our users as much, by making it harder for us developers to maintain the packages, and by making the overall size of the packages bigger and bigger over time. |
I'll give this PR a review nonetheless between today and tomorrow (currently struggling with a few last minute hiccups on my end) |
|
I agree with the general sentiment here. The amount of deprecated features has been growing and will continue growing unless we do something about it. We can't just leave these deprecated forever, unless we want to end up with a bloated codebase. To be honest, I thought this had already been decided. The It says "version in which the feature will be removed". I couldn't find a clearer way to express that something will be removed from the codebase. This is exactly why I proceeded to just remove the obsolete props in #45999 - because we gave a 6-month window for those to stay deprecated, and that window expired. It caught be by surprise that there is an unwritten rule that we "can't just delete things", which contradicts official public documentation, documentation that's 5 years old (see #5069). So, I'd prefer giving a 6-month, or even 1-year window for deprecating features, but then removing them once that time expires. If we don't do that, why do we even deprecate something? The fact that it's deprecated is worth nothing if we do nothing but keep warning forever. Just my $0.02. |
|
Could we get enough momentum to propose a way to safely remove deprecated APIs after a certain window of time? |
|
I'm very hesitant about merging this too. I've raised the hard deprecation of formally stable APIs in #41265 but didn't receive much of a response. I do understand the performance argument (the bot's report of 200ish bytes is flawed because it ignores I don't necessarily think hard deprecations are a bad thing but we all (we being WP contributors) need to get on the same page to do it. |
|
As I mentioned before, I'd love to get to an agreement. I believe it is a necessity for a project like Gutenberg to be able to hard deprecate (and remove) APIs — we would need to agree on the how. |
peterwilsoncc
added
the
Backwards Compatibility
See #41265 (comment) -- let's discuss agreement either on that ticket or at the community summit so we don't hijack this PR further. |
|
Just noting there's 114 extensions matching |
|
We're in an urgency to have a clear guidelines about how to set these versions, when it's one to (if ever) to remove APIs... How to deal with the ever growing complexity and bundle size of the project if we keep deprecations forever... We shouldn't have to ask our selves the same questions over and over again. Anyway, I'm going to close this PR for now as it's a bit stale. |
|
FYI I am proposing guidelines for component deprecations in #61099. |
What?
Some APIs from the components package are marked for removal for the WP 6.2 version. This PR removes them:
Note that the first two items above were due for removal in previous versions already but were delayed to give more time for developers.