JavaScript Chat Summary for May 16th

Below is a summary of the conversation from today’s JavaScript 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 make a single pass to fix offending code, using ESLint’s fixer or prettier (discussion ticket 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