JavaScript Chat Summary for May 16th

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in the bug tracker.

Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.

Other questions? Here is a detailed handbook for contributors, complete with tutorials.

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 PHPCSPHP Code Sniffer 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 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

Brent Jett 4:25 pm on May 17, 2017

I’m curious about the discussion to move away from backbone and the reasons that might be wise, but the provided “consensus from last week” link doesn’t cover anything about that. Does anyone have notes on what the cons for backbone.js and what an ideal replacement framework might look like?
- Andrew Duthie 8:38 pm on May 17, 2017
  In lieu of my own personal opinions, I’ll defer to the full Slack transcript, which includes a fair number of anecdotes and rationale.
  
  #40427 is relevant in discussing specific issues relating to Backbone view extensibility and testability.
  
  Other common themes I’ve noticed throughout the conversations include:
  - Backbone as an unopinionated framework tends toward complex architectures
  - Models and views are often strongly tied together, requiring an understanding of the assumptions made in these relationships
  - Difficulty in managing DOM and data state, and the interactions between
  - Intense learning curve and few feeling comfortable in maintaining these features
  Contrary points include:
  - Attributing some difficulty to overall lack of documentation
  - Fragmentation in maintaining multiple frameworks worsens consistency and thereby maintainability
Weston Ruter 4:44 am on May 25, 2017

attempt to lint only lines modified in proposed change (as in PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS., or Calypso’s git-based eslines)

See #34694. The wp-dev-lib project implements utilities for filtering out errors for lines not modified in a diff, not only for ESLint but also for PHPCS and stylelint (in a PR).

Comments are closed.

Welcome!

Communication

Build Tools for Code Standards

General Remarks on JavaScript Standards

Tickets

Open Discussion

Share this: