Deprecate the use of drgullin/icheck

+1 for this. Good reasons to do this:

1. Stewardship: The maintainer doesn't appear to care about downstream impacts and security exploits that changing their username could create.
2. Technical Debt: This is written in jQuery, which the Drupal ecosystem is trying to move away from.
3. Maintenance: It hasn't received an update in more than 4 years. The "coming soon" v2 was promised 10 years ago and still hasn't been released.
4. Criticality: This module only provides UI niceties--hardly mandatory for Webform itself--that largely do not require a JS library in the modern browser ecosystem.

It seems self contained in it's own "webform_icheck" submodule. So we can add a deprecation message to remove it in "V6.4.X" like core does, and move the module to it's own contrib space for those few sites that would still need it. If then something blows up again, it's only in that separate module, and not the whole webform user base.

@bramdriesen It isn't self-contained. You can see it in the core Webform module's Composer libraries file https://git.drupalcode.org/project/webform/-/blob/6.3.x/composer.librari...

If we move the webform_icheck module into its own project, the composer package will become webform_icheck-webform_icheck because all webform sub-modules are exposed as dedicated composer packages. I think the DA can fix this problem.

Here is an example of a sub-module moving into its project and getting the double namespace.
https://www.drupal.org/project/schemadotorg_next/releases/1.0.0-alpha16 →

Below are all the projects that have been deprecated for at least two years.

• Webform Algolia Places
• Webform iCheck
• Webform jQueryUI Buttons
• Webform jQueryUI Datepicker
• Webform Location Geocomplete
• Webform Toggles

My thought and recommendation is to move all of the sub-modules in the webform_deprecated project (and let them die a slow death).

Having a single project to deal with deprecated sub-modules will be easier to maintain.

I am unsure if we should move the Webform jQuery UI sub-modules because I suspect many sites are still using the datepicker.

The advantage to making a separate project for each module is that is allows the users of that module to work on maintaining it together or not, if there is not enough community interest.

It could be helpful to move to their own projects most Webform modules that exist only to make an external library work with Webform. This allows Webform it self to not need to worry about maintaining a dependency on a library that only a subset use.

I moved:

• Webform Algolia Places
• Webform iCheck
• Webform Location Geocomplete
• Webform Toggles

Into contrib space: https://www.drupal.org/project/webform_deprecated → and added jrockowitz as maintainer (feel free to remove me after this issue is closed).

webform_deprecated is a module on it's own because of a bartik CSS tweak and to set a requirement on Webform.

A few observations that @jrockowitz probably can best decide over:

1. I removed a few tests checks from: tests/src/Functional/Element/WebformElementPluginDefinitionsTest.php, tests/src/Functional/Element/WebformElementPluginPropertiesTest.php and tests/src/Functional/WebformLibrariesTest.php Which I did not add to the new deprecated module. Which, imo is fine but not to decide :-).
3. There is a little bit of leftover code in webform_ui\Form\WebformUiElementTypeFormBase::buildElementPreview line 425 and webform\Plugin\WebformElement\OptionsBase::prepare line 158 in regards to webform_toggles. Not sure what to do with that and if it could/should be moved into the webform_deprecated module somehow.

I did not touch the jQuery UI modules by the way.

The advantage to making a separate project for each module is that is allows the users of that module to work on maintaining it together or not, if there is not enough community interest.

I think the problem is there is no interest in maintaining these projects. At any time someone can opt to move a project from the webform_deprecated project into a dedicated project.

I am cool with moving these 4 deprecated modules. Is everyone okay with approach, knowing we can move these modules into dedicated projects if needed.

Moving this to Critical because it will block the beta and stable release of Webform 6.3.x

I'm fine with #15 since the libraries themself are usually abandoned/deprecated, I really see no need to move them separately into a contrib.