Core: Support selectively disabling Migrate patches

[mgol]

This adds three new APIs:

• jQuery.migrateDisablePatches
• jQuery.migrateEnablePatches
• jQuery.migrateIsPatchEnabled

allowing to selectively disable/re-enable patches in runtime. Source code is
refactored to avoid manually overwriting jQuery methods in favor of using
migratePatchAndWarnFunc or migratePatchFunc which cooperate with above
methods.

The jQuery.UNSAFE_restoreLegacyHtmlPrefilter API, introduced in Migrate 3.2.0,
is now deprecated in favor of calling:

jQuery.migrateEnablePatches( "self-closed-tags" );

The commit also reorganizes test code a bit, grouping modules testing patches
to jQuery modules in a separate directory and extracting tests of Migrate APIs
out of core.js to a separate migrate.js file. Helper files are now put in
test/data/ and unit tests in test/unit/; jQuery patch tests are in
test/unit/jquery/.

Fixes gh-449

Original description below

This introduces two new methods: jQuery.migrateDisablePatches & jQuery.migrateEnablePatches that allow to selectively (& dynamically) disable & enable jQuery Migrate patches by their IDs. Those IDs have been added to their respective entries in the warnings.md file.

There are a few special warnings printed directly via console.log without the migrateWarn* wrappers; they were left as-is; they should not have false positives and they're not doing anything except for console.log calls.

I originally planned to just silence warnings (see gh-449 for reasons why we need that) but that creates a danger: if a project fixes violations of a particular warning and silences it, the patch is still live so new violations can be introduced. Originally, I worried disabling patches may introduce weird cross-dependencies but the patches seem quite isolated so that seems doable.

This is a work in progress. It needs tests for the new APIs as well as their effects on the patches. But I wanted to raise it to gather feedback about the proposed API and the implementation.

[dmethvin]

Happy new year!

Overall this seems fine, and not too bad as far as the size either. Being that naming things is the hardest problem in programming, I wonder if it would be better to use the actual camelCase names for things like deprecated methods. I know a few of them actually are groups so that breaks the pattern a bit. That's all nitpicks though, the general approach seems like it should work fine.

[mgol]

Being that naming things is the hardest problem in programming, I wonder if it would be better to use the actual camelCase names for things like deprecated methods. I know a few of them actually are groups so that breaks the pattern a bit.

I guess it will make it easier. Maybe I can keep methods camelcased but if adding my own words, I can use hyphens? Or is such mixing bad?

[dmethvin]

I'm not sure what's best to do for this. I like having the method name when it matches. Maybe just come up with some camelCase name for the group so the two aren't conflicting?

Thanks for taking care of this!

[mgol]

@dmethvin Let's look a the toggleclass-bool example. The method is toggleClass but what should be the code for the warning? toggleClass-bool or toggleClassBool? The latter only partially matches the method due to the Bool suffix but OTH it's consistently camelCase. I think I slightly prefer toggleClass-bool but I can do both. I'd just like to know before I start updating the codes.

[dmethvin]

Yeah the toggleClass-bool option sounds the best to me.

[timmywil]

We talked about this in the meeting last week, but I still like this approach:

Step 1:

if we only warned when the patch is applied then we could just start with that one patch being disabled and having to enable it through jQuery.migrateEnablePatches when someone wants it; then we wouldn't need the UNSAFE_restoreLegacyHtmlPrefilter method

Step 2:

we could redefine jQuery.UNSAFE_restoreLegacyHtmlPrefilter() to just defer to the proper jQuery.migrateEnablePatches call, though

[mgol]

@dmethvin @timmywil This still needs a lot of work in tests and lots of modules don't work but I'd appreciate if you could review:

1. src/disablePatches.js
2. src/main.js
3. src/jquery/manipulation.js
4. test/migrate.js, there's non-trivial new logic there
5. In test: ajax.js, attributes.js & css.js; all of them are passing on 3.x-git & git jQuery versions
6. test/core.js from the beginning to jQuery.isWindow tests (inclusive) - they start at line 336 on main & line 426 in my PR

It'd be useful for me to get feedback about these changes before I spend more time on applying them to the rest of the tests in case major changes are needed.

I tried to deduplicate this as much as I could but many of those attempts were hitting edge cases so it's not terribly DRY but I'm out of ideas on how to improve this.

[mgol]

@timmywil @dmethvin this is ready for a final review. The updated PR description provides more details.

An important point is that after this lands we should no longer manually overwrite jQuery methods but we should always use migratePatchAndWarnFunc or migratePatchFunc to do it as they cooperate with the mechanism I'm introducing here.

[mgol]

Note to self: update https://jquery.com/upgrade-guide/3.5/ once this is released to mention the new API.

[timmywil]

Looks great! Thanks for doing this.

[mgol]

@dmethvin do you want to have a look as well? It's a bit different to my original implementation.

[dmethvin]

Looks good. Thanks for doing this, I know it's pretty often requested!