JavaScript chat summary, January 22nd, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: NPM Scripts

Slack Conversation

A few new commands have been proposed for addition to the @wordpress/scripts module:

  • build and start: https://github.com/WordPress/gutenberg/pull/12837
  • format: https://github.com/WordPress/gutenberg/pull/13394

The discussion around build and start focused mostly on the question how to approach default configuration for plugins and themes. We’re considering to extract parts of the Webpack config as npm package to simplify setup for plugin developers. This would also allow to provide a default config for @wordpress/scripts and proposed scripts. To provide flexibility, it was raised that an eventual Webpack config package could have 3 types of exports:

  • A full webpack config with a simple preset entries map for simple starter plugins ( front.js, admin.js, blocks.js or something like that ) to provide a simple zero-config option
  • A function that takes an entries map and outputs the full webpack config with recommended values.
  • Each part of the recommended config as their own keys.

The discussion provided good input for further iteration. Next, progress was shared on the format command, which aims to provide autoformatting functionality using Prettier and Eslint autofixers. It is still in an experimental state, but would provide a powerful tool for developers to more easily adhere to coding standards.

Agenda: Linting

Slack Conversation

We discussed the lack of ES2015+ rules in the WordPress JavaScript coding standards. A pull request was proposed on Gutenberg which makes using Object shorthand notation required for Gutenberg JavaScript. We agreed this was a desirable standard to have for ES2015+ code. For now, we decided to include the rule in the Gutenberg coding guidelines until a formal proposal to include ES2015+ rules in the WordPress JavaScript coding standards is drafted.

Agenda: E2E tests in core

Slack Conversation

Progress is being made on making Gutenberg’s e2e test functionality reusable for WordPress core and beyond. @gziolo gave the following status update:

  • Added package for Axe API integration with Jest and Puppeteer: https://github.com/WordPress/gutenberg/pull/13241. This is set of tools for accessibility static analysis which we want to integrate with e2e tests to ensure that we can catch regressions early on.
  • Extracted test utils to their own @wordpress/e2e-test-utils package: https://github.com/WordPress/gutenberg/pull/13228. It will allow some code reuse for those who would like to start writing e2e tests for their WordPress sites, plugins or themes.
  • Moved tests to their own @worpress/e2e-tests package: https://github.com/WordPress/gutenberg/pull/12465. There are now located in packages/e2e-tests/specs folder.

@gziolo plans to continue working on enabling a11y support to e2e tests in Gutenberg next. In order to start reusing the e2e setup in WordPress core, quite some configuration is still needed in WordPress core. This is tracked in https://core.trac.wordpress.org/ticket/45165. @adamsilverstein agreed to explore this further.

Agenda: PropTypes and React Doc Generation

Slack Conversation

@ajitbohra proposed to add PropTypes to components in Gutenberg, in order to allow automated documentation generating and have type checking for components.

There was interest in the idea but also some concerns were raised:

  • There is some uncertainty of PropTypes’ future, considering that Facebook doesn’t use them and there exist other type systems which supersede them (Flow, TypeScript). PropTypes seems like a good solution for what we need right now, but in terms of type system, there might be better solutions available.
  • If they’re added, we need to make sure they are added as part of a proposal which also includes how they are going to be used, ie. for auto-documentation.

For now, we decided to avoid to add complexity without clearly understanding the merit. More exploration is needed on auto-documentation and the benefits of strong typing.

#core-js, #javascript, #meeting-notes, #summary