JavaScript chat summary, April 16th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Closing the Loop: TypeScript

Slack Conversation | Previous Conversation

Question: What decision do we arrive at based on the previous discussion and comments?

Context: It had been an agenda topic for a meeting last month to consider whether to maintain and accept pull requests proposing to include TypeScript definitions in the project. As previously discussed, it was generally agreed upon to not maintain these in the project. Additional time was allotted to allow for asynchronous feedback. Since then, the topic had not been revisited.

Decision: TypeScript definitions will not be maintained in the Gutenberg repository.

Follow-up: In an effort to support those who may find benefit in these definitions, we should at least consider documenting third-party resources.

Action items:

  • Explain decision and close the related pull request. (Owner: @aduth)
  • Open a new documentation issue to outline the desired resources, and invite those from the affected pull request to provide feedback as to what specific information would most benefit interested developers and require the least ongoing maintenance. (Owner: @aduth)

Future of Block Registration

Slack Conversation | Previous Conversation

An update was shared on a proposed Webpack plugin discussed during the previous week’s meeting, which would help provide automation for the tedious and error-prone task of manually maintaining script dependencies. (Note: The pull request has since been merged)

Subsequent discussion was two-fold:

  • Could this plugin be used to help solve the unanswered question around asset management for the ongoing Blocks Registration RFC discussion? And if so, what would that look like?
    • There was some consideration about whether the manifest output by this tool, when used in combination with an explicit or implicit entry point to a block, could be sufficient to derive all necessary information to register and load a script and its dependencies.
  • Would this or its impact on the Blocks Registration RFC impact (for better or worse) an existing issue with load order of scripts and the challenge it poses to plugins who seek to extend blocks?
    • It was not considered to be directly related. However, there was some follow-up discussion about the use of filters generally, and whether the Blocks Registration RFC could have an impact in considering the registered block type to be aggregate of a series of patches (merging the block manifest, the client-side definition, and any third-party modifications).
    • Action Item: Continue discussion on the associated issue.