Empty out and deprecate drupal libraries which are related to Internet Explorer 11 polyfills in 10.0.x for removal in 11.0.0

To avoid the fails we need to skip those deprecation messages, you can see here how it's done for existing depecations that we want to ignore during testing: https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/tests/Drupal...

Added your suggestion @_nod, let's see the tests now.

Discussed this in depth with @lauriii.

1. If we deprecate the libraries now, we'll be encouraging contrib modules to remove IE11 support in 9.x, which we don't really want to do.

2. If we don't deprecate the libraries and simply remove them in 11.x, then modules won't trigger any errors because depending on a missing library definition doesn't actually result in any warnings.

3. A contrib IE11 modules could add these back potentially with identical namespaces, which would mean modules or themes continuing to want to support IE11 could add a dependency, and if they don't then the worst case is some cruft, but not any actual errors.

Given all of that, while it's a bit unusual, I think the best option is to remove these in 10.x but not deprecate them in 9.x, so going to close this as a duplicate.

We might want to specifically document polyfills in the bc policy to try to make this a bit more defined - our existing deprecation policy just does not really work here.

Hmm, I'm not sure I agree. As a contrib or site developer I wouldn't expect that libraries I was relying on would simply disappear and stop doing anything with no fatal or warning or information of any kind. We need some way to communicate to developers that they won't be provided anymore in D10, and the deadline to make that communication is 9.4.0-beta1. So maybe it's not a deprecation per se, but we need some mechanism.

This is 100% browser support thing. If we have a notice of some kind it should be saying that we dropped IE11 support, not that the specific core/drupal.nodelist.foreach is deprecated. Since the browser support information is already in the release note for the major version people should already know that trying to use their code in IE11 won't work.

In any other modern browser the missing libraries will have no impact given that those features are already natively supported.

The only thing I can think of is something like:

# Internal, will be removed in Drupal 10.0.0. Drupal 10 will remove support for Internet Explorer 11.

That way we're documenting things somewhere without actively encouraging people to remove them.

However, I grepped contrib for a selection of these and couldn't find anything with dependencies on them. There are one or two modules providing their own similar polyfills without using the core ones. Wasn't an exhaustive search. Makes sense to an extent since you'd have to be explicitly supporting and testing on IE11 as well as using the functionality provided by the polyfill to then need to depend on it. And then once you don't support IE11 any more you don't have to do anything except for drop the dependency. I think we need to think about how we provide these again in the future if and when we need to.

One more option, although I don't think it's a good option particularly:

1. Leave the libraries as is in 9.4.x (and/or add the #internal comments).

2. In 10.0.x, empty out the library definitions to remove all the files - this way library dependencies are met but there's no IE11 support.

3. In 10.1.x deprecate the (now empty) libraries for removal in 11.0.x

Or a hybrid would be special casing the new deprecation to be added in 10.0.x

#14 matches the proposal we already have for #3239980: Deprecate Modernizr, so maybe that's the best way to go actually.

We should still have a CR and release note in both cases. And document it somewhere in the handbook, although I'm not sure where.

I think maybe we should also put a comment on the library definition to this end since we don't have a separate module status for it.

#14 was two variations of one proposal, discussed this with @xjm a bit in slack to go through the various drawbacks of each proposal. None of them have many pros IMO.

1. Silent removal (from #10) nothing 'breaks'. However modules/themes trying to support IE11 in Drupal 10 don't get any hint they need to require the IE11 module, or if they don't want to support IE11, nothing reminds them to remove the cruft from their dependencies.

2. Deprecation in 9.4.x for removal in 10.0.x encourages module/theme authors to remove IE11 support in 9.x, but we only want to drop IE11 in Drupal 10. It's not the same as a deprecated API.

3. Emptying out the library definition in 10.0.0, deprecating it in 10.1, removing it in 11.0.0 would follow the letter of the deprecation policy, but for anyone actually wanting to support IE11 for some reason they'd get absolutely no indication that they now don't until it's too late, making it functionally equivalent to #1 from that perspective, or maybe even worse since it'd look superficially like the polyfill is still there.

4. Emptying out and deprecating the library in 10.0.0, for removal in Drupal 11, notifies any modules/themes that they need to do something (we can point to a change record, that change record can later point to IE11 module if and when there is one), whether that's replacing the polyfill or removing a dependency. This breaks the letter of the deprecation/continuous upgrade path policy by adding a new deprecation in 10.0.x without 9.4.x, but it's the quietest way to notify people (except for silent removal with a CR) and the best timing (not too early in 9.4.x, not too late in 10.1.x).

While I think for all the reasons given, option #1 would have been acceptable, the odds are slightly tipped in favour of option #4 since it does provide signposting to an IE11 module if and when there is one. This means we need a 10.0.x-only patch to empty out and deprecate these library definitions, for removal in 11.0.0, and still no changes in 9.4.x

Which in turn means this.

Added a patch for Drupal 10.0.x.

1. +++ b/core/core.libraries.yml
   @@ -443,11 +444,13 @@ drupal.array.find:
    
    drupal.batch:
      version: VERSION
   @@ -460,6 +463,7 @@ drupal.batch:
   
   @@ -460,6 +463,7 @@ drupal.batch:
        - core/drupal.ajax
        - core/drupal.progress
        - core/once
   +  deprecated: *polyfill_deprecated
    
    drupal.checkbox:
      version: VERSION
   @@ -588,11 +592,13 @@ drupal.element.closest:
   
   @@ -588,11 +592,13 @@ drupal.element.closest:
        misc/polyfills/element.closest.js: { weight: -20 }
      dependencies:
        - core/drupal.element.matches
   +  deprecated: *polyfill_deprecated
    
   

   These two aren't IE11 polyfills - this is the cause of the test failures.

2. +++ b/core/tests/Drupal/Tests/Listeners/DeprecationListenerTrait.php
   @@ -118,6 +118,19 @@ public static function getSkippedDeprecations() {
          "The \"Drupal\Tests\Listeners\DrupalListener\" class implements \"PHPUnit\Framework\TestListener\" that is deprecated.",
   +      // The following deprecations are related to the IE 11 polyfills.
   +      'The "core/css.escape" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.array.find" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.array.includes" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.customevent" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.element.closest" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.element.matches" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.nodelist.foreach" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.object.assign" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/drupal.string.includes" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/es6-promise" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/once" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
   +      'The "core/picturefill" asset library is deprecated in drupal:9.4.0 and is removed from drupal:10.0.0. See https://www.drupal.org/project/drupal/issues/3238501',
        ];
   

   This section can be removed - instead we should ensure none of the polyfills are dependencies of any other core libraries.

   Additionally, core/once isn't a polyfill.

Attached patch against #22 #23
Attached interdiff

Reroll the patch for D10.

Added draft release note

See discussion in #3238501-40: Remove empty and deprecated IE11 polyfill library stub entries in 11.0.0.

Fixing a broken link in the issue summary.

MR!2440 is basically MR!1776 from #3238501: Remove empty and deprecated IE11 polyfill library stub entries in 11.0.0, but instead of removing the IE11--polyfills, it empties and deprecates them.

Some observations:

1. https://git.drupalcode.org/project/drupal/-/merge_requests/2440/diffs?co... shows us that we missed some references in #3238501: Remove empty and deprecated IE11 polyfill library stub entries in 11.0.0 and that we can reference libraries that don't exist without any error/notice. Is this something that is eligible for a follow-up?
2. yarn `build:js` command is deprecated in drupal:9.4.0 and will be removed from drupal:10.0.0. This command is no longer needed in Drupal 10.0.0 once https://www.drupal.org/project/drupal/issues/3278415 is committed.. Is that another 10.0.0 beta blocker or "just" another issue.
3. As stated by @longwave in #3238501-31: Remove empty and deprecated IE11 polyfill library stub entries in 11.0.0 postcss.config.js is obsolete. See #3086931: Remove unused postcss.config.js

Added CR

Updated release note snippet.

One comment/question on the MR but otherwise this looks great! Reviewed the release note and change record too.

Just a comment on the comment by catch, I'm not sure which way is best.

Marked #2343351: Make picture polyfill optional as duplicate.

I personally think with the responsive_image library we could just remove it with a CR, it's not providing any sort of API or even it's own polyfill, it's just an internal usage of a different polyfill. Shows we're sort-of missing the concept of internal libraries but not this issue's problem to fix IMO.

Makes sense, added (draft) CR https://www.drupal.org/node/3292687

Rerolled after the landing of #3086931: Remove unused postcss.config.js which took care of one of the observations in #33.

Slightly tweaked the release note.

I think this is ready to go.

Note that this will make some CSS backports a bit harder, but if we're going to un-polyfill those files it needs to be in a major release, and it's only a few lines in a few files.

NR for a question on MR. Also needs a rebase.

Added the comment from string.includes.es6.js to all files.

I'm suspecting the files are kept around to make sure libraries overrides or tests in hook_js_alter that look for a specific file still works as expected.

I think I mis-spoke in here https://www.drupal.org/project/drupal/issues/3263823#mr2440-note102324

What I was thinking was just remove the files and leave the empty but deprecated library definitions, not actually leaving empty files.

I don't think we need to account for library alters, the only reason for leaving the library definitions is so that if modules/themes have an explicit dependency on them, they'll get a deprecation message.

adressed #44

Committed f052a25 and pushed to 10.1.x. Also cherry-picked to 10.0.x. Thanks!

Revert was just because I had multiple browser tabs open and I copied the commit message from a wrong one 😅