[wp-trac] [WordPress Trac] #58645: Remove outdated jsvalidate task from Gruntfile

[WordPress Trac]

#58645: Remove outdated jsvalidate task from Gruntfile
--------------------------+-----------------------------
 Reporter:  kadamwhite    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:  javascript    |
--------------------------+-----------------------------
 We should remove the outdated `grunt-jsvalidate` step in our JS build
 process to eliminate distracting false-positive errors and complications
 when introducing new valid JS into WordPress core.

 While working on improvements to the Emoji Loader in
 https://github.com/WordPress/wordpress-develop/pull/4562 , @westonruter
 identified that the `grunt-jsvalidate` task used in Core's Gruntfile build
 process was reporting false-positive JS parsing issues.

 This validation task was added in #26615 to pass generated JS assets
 through [https://esprima.org/ Esprima] in order to verify that the
 minification step did not introduce parsing errors in the JS engines of
 the time (notably Internet Explorer, as you might expect).

 `grunt-jsvalidate` has not been updated in a decade, and uses an outdated
 version of Esprima that does not understand well-established modern
 JavaScript syntax. The supported browser landscape has changed, and the
 version of Uglify JS we use has been continually improved in the ten years
 since we added this validator (our current version of Uglify, consumed
 through `grunt-contrib-uglify`, is less than a year old).

 In Slack, @joemcgill proposed removing the validation step,

  With many files now being written in ES6 or included from built files,
 should we consider removing this step entirely? Looking at Trac search
 results, it looks like many times jsvalidate is not catching legitimate
 errors, but instead needs to be worked around when updating libraries or
 bumping our own npm packages.
  \\
  See @youknowriad's comment from earlier today as an example.
  \\
  Alternately, if this is still needed in very specific cases, perhaps we
 should start to narrow the scope of which files are validated during
 builds so we can deprecate and remove this task over time?

 I (@kadamwhite) support removing `grunt-jsvalidate` entirely, on the
 grounds that supported browser parser reliability is much higher than it
 was ten years ago, and that the complexity of updating this build step to
 a modern solution is not worth the value it provides the project.
 @youknowriad also supports removal, "I see very little value in that
 validation step."

 @desrosj deferred to @jorbin, who notes,

  I'm of the opinion that the usefulness of jsvalidate is no longer there
 and we should remove it. The background is as suspected, there were some
 errors in minification, usually in browsers we weren't regularly testing,
 and this [grunt-jsvalidate] was seen as a way to reduce those.
  \\
  While it's certainly possible for there to still be an issue, I think
 that minifiers are ALOT better now and the JS engines WordPress target are
 much more modern and similar than 10 years ago.

 Ticket adapted from slack thread
 https://wordpress.slack.com/archives/C5UNMSU4R/p1686977423731239

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58645>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform