As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint → , we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.
There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-wrap, which targets the .wrap() function, .wrapAll() function, .wrapInner() function, .unwrap() function,
core/.eslintrc.jquery.json Change "jquery/no-wrap": 0, to "jquery/no-wrap": 2, to enable eslint checks for uses of jQuery .wrap(), .wrapAll(), .wrapInner(), .unwrap(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directorycore/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed# @todo Remove the next chunk of lines before committing. This script only lints
# JavaScript files that have changed, so we add this to check all files for
# jQuery-specific lint errors.
cd "$TOP_LEVEL/core"
node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
CORRECTJQS=$?
if [ "$CORRECTJQS" -ne "0" ]; then
# No need to write any output the node command will do this for us.
printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
STATUS=1
FINAL_STATUS=1
fi
cd $TOP_LEVEL
# @todo end lines to remove
Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.
.wrap(), .wrapAll(), .wrapInner(), .unwrap() to use Vanilla (native) JavaScript instead.Closed: won't fix
11.0 🔥
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Speaking with @nod_ briefly in slack about this one. Think this is a no-go as the solution requires creating new functions making it more difficult to read.
Thanks!