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
.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 PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on 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 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.
- @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.
- @adamsilverstein requested feedback on a ticket proposing to make two utility functions specific to Press This more widely available (#40635)
- 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.