JavaScript chat summary, April 9th, 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.

Agenda: Administrative

@aduth requested an update to the meeting time displayed in — the time being shown was wrong and it should be corrected to be one hour later.
@sergeybiryukov performed the update.

Agenda: Feature: Add webpack plugin to externalize and extract script dependencies

A pull request was proposed to implement a new module to help automate some of the processes around assigning webpack externals.

@aduth provided some context:

A problem we have today is we have the package.json each package which lists these, then they need to be duplicated again into lib/package-dependencies.php, which sometimes does not occur

The pull request was generally well received, people participating in the meeting noted that it may be a step to eliminate the need for maintaining dependencies in PHP for plugin developers utilizing webpack or wp-scripts build workflow.

@aduth referred that the broader problem of from just a JavaScript file figuring out the dependencies may not be possible to solve.
If someone reading this has any idea that would work in the majority of cases feel free to comment.

@youknowriad referred he would prefer to have the mechanism implemented as a babel plugin instead of a webpack plugin as babel is more “universal” tool to read JS and transform it, and would allow the mechanism to work in plugins using other bundle systems like Parcel. But reinforced that he is not against a first version using a webpack plugin.

Agenda: Filterable translation functions

@swissspidy proposed a pull request that makes all gettext functions from the i18n package filterable.

There was some consensus that although the filters may not have a big overhead during a gettext function call, the function is a hot path and may be called many times during the application usage.

The discussion went forward and people analyzed some tradeoffs of the following potential alternatives:

  • Apply the filters on the server.
  • Add a labels property to the editor setting that developers may change.
  • Provide developers a simple way to extend an i18n file with another file containing their customizations.

Ultimately it seemed people were not able to decide on a solution because there is a lack of knowledge of the high level need a plugin wanting to use a gettext filter may have.

@nerrad suggested the following action item:

experiment with actual benchmarking metrics for the filter approach using concrete examples

@swissspidy volunteered to find some concrete examples/use cases.

If anyone has some concrete examples please provide them as it would allow to decide the best path forward and would allow to have real-world measures of the performance.