JavaScript Chat Summary for May 16th

Below is a summary of the conversation from today’s JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. Chat (agenda, Slack archive):

Build Tools for Code Standards

  • There’s a desire to replace the current JSHint configuration with an ESLint solution (#31823)
  • @netweb shared a number of ESLint-related projects targeting parity with existing JSHint and JSCS configuration
  • JSHint was mainly designed to identify potentially erroneous code. ESLint builds upon this with support for style and custom rule enforcement
  • What steps do we then take to extend the ruleset to meet the remainder of the JavaScript Coding Standards? Parity with .jshintrc has the benefit of serving as a drop-in replacement, but legacy code and existing patches may be impacted by broader rule enforcement.
  • Options for incremental adoption of rules: first configure rules as warnings, or attempt to lint only lines modified in proposed change (as in PHPCS, or Calypso’s git-based eslines)
  • Alternatively, forgo incremental adoption and instead makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). a single pass to fix offending code, using ESLint’s fixer or prettier (discussion ticketticket Created for both bug reports and feature development on the bug tracker. to be created), at the cost of potential disruption to existing patches by conflicts introduced. This appears to be the favored path.
  • How do we reconcile a desire to retroactively fix coding offenses with our guidelines explicitly forbidding this sort of refactoring? The guideline was revised with an ending note about internal consistency. @jorbin later remarked that exceptions have been made in the past for allowing JSHint-based refactoring.

General Remarks on JavaScript Standards

  • @aduth raised a concern of the difficulty in following spacing exceptions on function arguments, arguing that the mental overhead in understanding how context varies application of the rule could explain why it’s followed inconsistently.

Tickets

  • @adamsilverstein requested feedback on a ticket proposing to make two utility functions specific to Press This more widely available (#40635)

Open Discussion

  • A meeting topic was proposed: Module patterns to extend or replace Browserify and make internal utilities more broadly available. Special attention will need to be made for interoperability with existing patterns for declaring script dependencies.
  • A meeting topic was proposed: Making a decision on a framework to use in place of Backbone, based on consensus from last week that a replacement is needed.

#javascript, #summary