Skip to content
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

Differentiate between compatibility patches and pure warnings #472

Open
mgol opened this issue Aug 12, 2022 · 2 comments
Open

Differentiate between compatibility patches and pure warnings #472

mgol opened this issue Aug 12, 2022 · 2 comments

Comments

@mgol
Copy link
Member

mgol commented Aug 12, 2022

jQuery Migrate does two things:

  1. Fills in removed APIs, warning when used.
  2. Warns about deprecated APIs that still exist.

It makes sense to differentiate these two for a few reasons:

  1. Teams may not always have the capacity to tackle all warnings, they may want to resolve just the ones that block Migrate removal and then remove Migrate, leaving resolving the other warnings for later, when they prepare for updating to the next major version.
  2. A project may have already been on jQuery 3.x without Migrate and then it added Migrate to prepare for an update to jQuery 4.0. But Migrate would now also restore some APIs & behaviors removed in jQuery 3.0 which is counterproductive. Since Core: Support selectively disabling Migrate patches #450, it's now possible to exclude warnings but this use case would require first determining those patches.

We should have an easier way to only enable patches required to address before removing Migrate or to only enable the ones preparing for the next major version.

Thoughts, @dmethvin @timmywil @gibson042?

@dmethvin
Copy link
Member

I agree we're doing two different things here, but wonder what the solution is for this. Would we create another flag like jQuery.disableDeprecationWarnings or something like that?

@mgol
Copy link
Member Author

mgol commented Aug 14, 2022

Yeah, naming is hard. ;) Would a single API be enough, considering there are use cases both to only enable patches required to make the current major version of jQuery work post-upgrade and to only enable deprecation warnings for a future major?

We could also bake it into jQuery.migrateDisablePatches & jQuery.migrateEnablePatches as some special keys like compatibility-patches & deprecation-patches (again, better naming suggestions welcome). Together with that, we could introduce a special key all that would disable all patches in case someone wants to enable one by one instead of disabling one by one.

Then we'd just need to keep a list of compat patches and compare those special keys against that. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants