Javascript Chat Summary – September 11th

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.

Announcements

  • WordPress packages are using Babel7 and the @wordpress/babel-preset-default has been updated to support it.
  • The packages do not include the polyfills by default anymore. It’s the responsibility of the consumer to add the required polyfills to their applications or bundles. The context for this change can be found on this issue.
  • WordPress (via Gutenberg) exposes a new script wp-polyfill-ecmascript (and will be simplified soon as just wp-polyfill) that you can add as a dependency to your script to ensure the polyfills are loaded.

Discussions

  • Having a separate polyfill script even without conditional polyfill loading is still a decrease in bundle size (Gutenberg is 118.64kb smaller).
  • We also discussed whether to include “web” polyfills in the wp-polyfill-ecmascript instead of including them per dependency. A decision was made to have a unique wp-polyfill script you can depend on and use all the polyfills made available by WordPress. This script would include both ECMAScript polyfills and also different Web Standards that require polyfills such as window.fetchor element.closest. This results in a better developer experience as it’s not always easy to know what polyfill is needed for per script.

Action items

#core-js, #javascript, #summary

Javascript Chat Summary – September 4th

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: Deprecation policy

Slack Conversation

Gutenberg has a policy where deprecated functionality is kept for two additional minor versions to allow time for plugin developers to move away. As we start deprecating functionality in the published npm modules, the idea of tying to Gutenberg version doesn’t make a whole lot of sense, as these packages could be used independently of Gutenberg or WordPress.

It was raised by many that our packages should just follow semver. The most likely scenario for the 5.0 merge will be that the JavaScript will still be maintained on Github and included in WordPress through npm. The aforementioned deprecation policy is mostly something that applies to the Gutenberg / WordPress context then. The initial idea in terms of flow looks somewhat like this:

  • Packages follow semver, so something could be removed in a major version, ie. 3.0
  • Then the package adds a deprecation warning in a minor version before that, ie. 2.x
  • The deprecated call as used by packages wouldn’t include anything specific about Gutenberg, but somehow Gutenberg extends the message it logs (by filter), analyzes the generic deprecation version (the npm SemVer) and maps it back to an equivalent Gutenberg / WordPress release.

Actions

  • Explore extensibility of deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad)
  • (Re-)consider how and where to define boundaries between packages and core-specific JavaScript (proposal by @atimmer, @omarreiss)

Open floor: Also allow building in src

Slack Conversation

The build step that was introduced in #43055 seems to cause quite some friction for PHP development, since now you also need to build to see a change in the PHP reflected. This turns out to be a weird experience for PHP development, since there’s no real reason why it needs to be built. A solution that allows for building with symlinked PHP files was pursued in #44492, but seems to run into a dead end. @omarreiss is now working on a grunt build:dev task which allows to build into src after all and asked if anyone had any input / objections.

It was raised that some PHP files (ie. formatting.php) need to be built right now and this is really confusing. Since PHP is a dynamic server language, we should look if we can avoid any PHP from being built statically. Apart from this there seemed to be no objections to the approach.

Actions

@omarreiss will work on a patch.

Open floor: Guidelines for including WP packages

Slack Conversation

Currently it’s not clear if plugin developers should consume WordPress packages through the wp global or by importing them from the @wordpress/ namespace. Documentation and guidelines about this are currently lacking. It was raised that different approaches are probably needed in different scenario’s. Factors that play a role are:

  • if the plugin author needs to backport these API’s or not in order to support classic editor.
  • If the plugin author uses ES2015 or older versions of JS.
  • If the plugin author uses a build proces.

Actions

@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.

Dev Chat Agenda: September 5th (4.9.9 Week 4)

This is the agenda for the weekly devchat meeting on September 5, 2018 at 20:00 UTC:

  • 4.9.9 planning
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

#4-9-9, #agenda, #core, #dev-chat

Javascript Chat Summary – August 28th

Below is a summary of the discussion from 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: Preparing for Gutenberg Merge

Slack Conversation

What tasks do we need to complete on the core side to be ready for Gutenberg Merge?

Prior Work

Remaining Tickets

Actions

What? Who?
Experiment with the following steps to see how this works:

WordPress side:

– Gutenberg packages stay where they are
– Gutenberg’s PHP (script registration and bootstrapping) move to core.
– Webpack config to alias wp.* to npm dependencies moves to Core’s webpack config.

Gutenberg side:

– Kept as plugin for ease of maintenance, updates.
– Plugin re-register’s the scripts (overriding wp’s registrations)
– No more php bootstrapping in the Gutenberg repository.

Some experimentation could involve consuming packages in WordPress core.

Example: Usage of shortcodes.js could be replaced with @wordpress/shortcodes

edit-post needs to be moved to a package.
Resolve componentsand block-library which have some code that lives outside packages.

Agenda: Hooks

Slack Conversation | Context

The following things were discussed:

  • Standards for naming/namespacing hooks
  • Criteria for adding/accepting a new hook
  • Expanding documentation for available hooks (including inline documentation)
  • “All” hooks.

No clear resolution to the above points was made in the meeting.

Agenda: Babel 7 & Polyfills

Slack Conversation | Context

Actions:

What? Who?
Decision: Ship packages without any polyfills, then bundle all polyfills in WordPress core.  Documentation will include something like this:

This package assumes that your code will run in an ES2015+ environment. If you’re using an environment that has limited or no support for ES2015+ such as lower versions of IE then using core-js or @babel/polyfill will add support for these methods. Learn more about it in Babel docs.
@gziolo 

Agenda: Converting from lodash to lodash-es for distributed packages

Slack Conversation | Context

Actions:

What? Who?
Continue discussion on the related issue.  

PHP Meeting Recap – August 20th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • We continued reviewing the content of the Update PHP page, which is available in this Google document.
  • We specifically looked at the closing section that acts as a summary, wondering whether it could be highlighted more or whether it is even needed. In the end it was decided to keep it as it is, as web readers typically expect a conclusion to occur at the end of a resource. Furthermore it leaves them with a positive attitude about their (future) achievement.
  • There were two comments about redundancy of paragraphs describing what would be the topic of the respective next section, since they are followed by a heading telling the same thing. However, as linking paragraphs they improve the reading flow and therefore should remain present.
  • A couple of minor wording improvements were discussed and applied.
  • It was agreed that the only outstanding change is the removal of all the hosting-specific tutorial links. They should be replaced with a single link to an external resource containing those links, similar how it is in the current live version of the page. A long list of links would distract readers, furthermore a single external resource allows for more flexibility on how this is managed. For now, the single link should point to the hosting-specific tutorials list in the Servehappy resources repository. Once this change is present, the content of the Google document can go live, replacing the current Update PHP page content.
  • Before the meeting, at WordCamp Brighton, a new idea of coming up with a documentation pattern and distributing it to hosts in order to get them provide guides on how to update PHP on their environment was discussed. The idea was appreciated by everyone. While an involved task, it will iterate on the already present crowd-sourced resources repository.
  • It would make sense to use GitHub Pages for such a repository. Pointing to a repository directly would easily confuse non-technical users, and a simple website fetching the content from GitHub Markdown files would improve that greatly.
  • A consideration is the URL to use for that. GitHub Pages URLs for organization repositories contain both the organization name and the repository name, so for the servehappy resources directory, it would be WordPress.github.io/servehappy-resources, which is not very obvious for what it contains. A repository named update-php or update-php-resources would be a better alternative. Alternatively, a custom domain could be used. This needs to be carefully evaluated.

Next week’s meeting

  • Next meeting will take place on Monday, August 27th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Further discuss the approach for streamlining hosts’ PHP update tutorials and using GitHub Pages (or possible alternatives) for those resources.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summary

Dev Chat Agenda: August 22nd (4.9.9 Week 2)

This is the agenda for the weekly devchat meeting on August 22, 2018 at 20:00 UTC:

  • 4.9.9 planning
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

#4-9-9, #agenda, #core, #dev-chat

REST API chat summary: August 9

This post summarizes the REST API component team chat from August 9 (agenda, Slack archive).

5.0 Priorities

The REST API team’s primary goal for the next major release is to support the Gutenberg team. There are still a number of REST API-related issues open in the Gutenberg merge proposal milestone; we always welcome assistance in getting these taken care of.

Issues that were raised as needing eyes and opinions:

  • #44758 (handling user’s locale in REST API responses)
  • #39953 (handling dates on draft posts)
  • gutenberg#8683 and gutenberg#2457 (supporting Gutenberg use with custom controllers and REST routes outside of the wp/v2 namespace)

Outside of Gutenberg, the two major areas of development we aim to tackle are

  • further improvements to the API’s support for meta,
  • and authentication.

Meta Handling

Following the register_meta improvements in 4.9.8, we wish to continue improving the state of meta handling and registration within the REST API.

  • @flixos90 will be re-opening the discussion around how to register complex meta values (e.g. permitting associative arrays instead of just integers, strings and the like). See #43392.
  • #43941 (support default values for registered meta) has clear potential benefits to users and will also be prioritized.
  • @spacedmonkey and others are driving additional tickets which could benefit meta handling, including #44387 & #44238.

Authentication

We aim to release a tested version of the OAuth 2.0 plugin to the plugin repository by the end of the year. This will greatly assist application developers who wish to integrate their WordPress site with external applications. We are also interested in pursuing a basic auth solution within core (see discussion in #42790).

As @rmccue is currently unavailable to lead development in this area, we are opening a call for a lead contributor to the REST API authentication plugins. We need somebody to own the vision for how external applications should authenticate with WordPress.

Agenda for today’s meeting

The REST API team will be meeting shortly (now, in fact…) in #core-restapi for our regular weekly meeting at 2018-08-16T17:00 UTC. As always, if you have a REST API related ticket you would like to bring to the component team’s attention, please join us or leave a note in the #core-restapi channel. Hope to see you all later today!

PHP Meeting Recap – August 13th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • The content of the Update PHP page was further discussed. There is a Google document available where @alexdenning has been working on revised copy. It is open for comments if you have suggestions.
  • As a reminder, the goal is to shorten the copy by removing unnecessary technical details and thus more positively encouraging the user to update. At the same time, we must not omit that there may be issues and, most importantly, we have to educate about the prerequisite steps necessary to roll back in case a problem occurs that cannot be fixed quickly.
  • As most problems actually need technical assistance to solve, we should not go into too much detail there, but point out that they might want to get help from a developer in such a case. However, basic suggestions as finding a replacement plugin in case a plugin is incompatible should remain, as we still want to encourage users who would be unable or unwilling to hire a third person.
  • At the same time, with the improvements being made in #44458 we can actively encourage the update because, even in case of errors, the site owner will still be able to log in to the site to provide short-term fixes at least.
  • Over the course of the meeting, we made a couple comments on the document with the items we discussed. Please refer to the Google doc linked above for details.
  • We also briefly picked up discussion on visual assets for the page. While that should preferably happen after the copy is in place, it doesn’t hurt thinking about it already, especially since some pieces might be relatively independent of what the final copy will be like. These are ideas we have been considering:
    • Timeline of PHP versions and their end of lifes (dynamic including the passed PHP version, or not)
    • Graphic of the relation between server, PHP, website, WordPress (possibly also including plugins and themes)

Next week’s meeting

  • Next meeting will take place on Monday, August 20th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Further discuss the Update PHP page copy and visual assets to use.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summary

Javascript Chat Summary – August 14

Below is a summary of the discussion from 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.

This week we discussed WordPress packages and how to optimize their distribution using npm. As of today, Gutenberg is built of 41 packages where each of them can be used independently by every plugin and theme developer in their projects.

Duplication concerns over independent versioning

Slack Conversation

Problem: An issue was raised about our independent versioning of packages, and how this can lead to duplication which, for packages like data which behave as a singleton, can result in some pretty undesirable outcomes. Related comments on GitHub:

Discussion: 

  • This is not specific to @wordpress/data, and could affect anything which behaves in a global / singleton fashion: @wordpress/hooks@wordpress/filters@wordpress/blocks.
  • The issue is mitigated but not eliminated by moving away from Lerna independent versioning (toward fixed versioning) because the chance for differing versions still exists.
  • This shouldn’t be an issue in WordPress context at all. This seems to be an issue for external apps which consume WordPress packages directly from npm.

Decision: Avoid “globals” behavior, where a consumer must define and operate with its own registry (specific to @wordpress/data).

Action items:

How required built-ins should be polyfilled

Slack Conversation

Problem: The current npm packages that being built for Gutenberg polyfill usage of some browser features that are not available on older browsers. This polyfill is global and affects any client who uses WordPress npm packages. This is unexpected and can alter the runtime environment in surprising ways. More details in the related issue.

Decision: corejs flag should be set to false when generating distribution version for packages and set to 2 when bundling with Webpack. In addition, we should inform developers consuming WordPress packages to install proper polyfills on their own.

Guidelines for releases

Slack Conversation

Proposal: We have a documentation proposal to improve guidelines for creating, managing and publishing packages.

Observations: The versioning recommendations are very oriented toward deprecations which seems to be the right approach.

Action item: Add section about managing changelogs based on the discussion from last week.

Dev Chat Agenda: August 15th (4.9.9 Week 1)

This is the agenda for the weekly devchat meeting on August 15, 2018 at 20:00 UTC:

  • 4.9.8 feedback
  • 4.9.9 planning
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

#4-9-8, #4-9-9, #agenda, #core, #dev-chat