JavaScript chat summary, February 19th, 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: NPM Mono-Repo Subdirectory Declaration

https://github.com/npm/rfcs/blob/latest/implemented/0010-monorepo-subdirectory-declaration.md

@adamsilverstein quoted @aduth‘s note that we should consider implementing the npm monorepo declaration in the WordPress npm packages.

@aduth added that implementing this declaration would be a straightforward task that would help make npm more “aware” of where to find the specific source for a package in a mono-repository, hopefully improving links.

The idea was well received.

@aduth has created issues related to this task:

Feel free to share your thoughts and provide feedback related to this subject in the issues.

Agenda: Feature Flags

https://github.com/WordPress/gutenberg/pull/13324

Feature flags were merged in the Gutenberg repository. Quoting @gziolo:

feature flags in Gutenberg, it’s very simple approach which will allow us to enable new features only for the plugin while keep it completely removed from WordPress core using dead code elimination.

We went into more detail of what feature flags are and what they allow.

@atimmer noted that most commonly feature flags allow to enable or disable specific features while Gutenberg feature flags apply to a whole set of features e.g.: “phase 2 features”.

@aduth referred that the reason behind this decision may be related at least partly to the objective of simplifying dead code removal.
More information can be found at https://github.com/WordPress/gutenberg/pull/13324.

@adamsilverstein shared that he wants to introduce a feature in the hooks package whose code should only be included when the SCRIPT_DEBUG flag is set. Any feedback to this is welcome and can be provided in https://github.com/WordPress/gutenberg/pull/12038.

During the discussions, it was referred that, although dead code removal is a common and used by famous libraries like React, there are no good resource/references available online to help developers understand how dead code removal works.
If you know any good resource feel free to share the link in the comments or the core-js channel.

Agenda: Build support for wordpress/scripts

Relevant PR’s:

According to @gziolo both PR’s are almost ready, but they need additional testing given the complexity of running the scripts with default configuration in various external projects.

@adamsilverstein noted that webpack setup is a significant barrier to entry for new developers and the more we can improve our tools the better.

@gziolo referred that a tutorial was already created and it will be simplified after latest changes are published.

Open floor

@nerrad referred that he would like to use the new version of React, more specifically React hooks, and asked when a React upgrade should be considered and when a WordPress release will contain the next version of React.

Answering to @nerrad, @aduth noted that upgrading React should be a non-issue although we may need some scrutiny on what is exposed. Regarding the WordPress releases, @aduth expects that anything merged to Gutenberg repository between now and mid-March should be part of the WordPress 5.2 release, but this specific subject will be clarified during the next #core-editor meeting https://make.wordpress.org/core/2019/02/19/editor-chat-agenda-february-20th/.

@nosolosw announced that in the past days the first auto-generated API documentation was merged to the Gutenberg repository: https://github.com/WordPress/gutenberg/pull/13856.
The tool that autogenerated the documentation is proposed in https://github.com/WordPress/gutenberg/pull/13329.
The next package/component that will be used as a testbed for the tool is not yet decided and every suggestion is welcome.

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

REST API Chat Summaries: Jan 31, Feb 7

This post summarizes the weekly REST API chat meetings on January 31, 2019 and February 7, 2019. (agenda/notes, Jan 31 Slack transcript, Feb 7 Slack transcript). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

February 14 meeting agenda

Have a topic for discussion for today’s meeting on February 14 2019 18:00 UTC? Leave a suggested edit on the agenda document.

5.1: Dev Note needs?

  • The new rest_post_search_query filter could be called out in Other Changes.
  • changeset 44625 (update wp_die() to handle JSON contexts) could also be called out in Other Changes.

5.2 Tickets: Owners Needed

Gutenberg Widgets Endpoint

  • WordPress/gutenberg#13511: POC for a legacy widget block. @jorgefilipecosta requests input from REST API contributors.
    • Feedback provided around endpoint structure and parameter access
    • @kadamwhite proposes that user stories or use-cases for how these widgets will be consumed and displayed in the editor and rendered posts should be written for new endpoints, to inform implementation.

Authentication

  • All present agree we have a strong need for a core authentication solution. Existing plugins like the OAuth2 or JWT-Auth plugins work and are used on numerous sites, but need UX improvements and more documentation / example clients to be truly broadly applicable. OAuth2 in particular is seen as too complex / difficult to implement as a client developer.
  • Discussion on core auth since WCUS has centered on supporting basic authentication (only over SSL) (#42790), as the simplest path forward.
    • The main weakness of basic auth is that it ties all authorized applications to the user’s account name and password, so apps cannot be individually authorized or disconnected without creating new site accounts (not workable for e.g. the core mobile applications).
  • @koke thinks a JWT-based solution could be workable from the mobile applications.
  • The way CGI environments mutate authorization headers complicates any core-wide solution. A custom header may be necessary.
  • @espellcaste has volunteered to reach out to authors of existing plugin directory REST API auth solutions to get their input on what is best for core.

Upcoming Meetings

What can the REST API do for you? Join an upcoming meeting to help shape the future of this component!

#core-restapi, #meeting-notes, #rest-api

JavaScript chat summary, February 5th, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agendaSlack Transcript) Please excuse the delay!

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

Agenda: Changelogs

Slack Conversation

In a previous discussion a need surfaced to improve Semver for JS packages and better understand the changes we are syncing into WordPress core when we update the JS packages. For this, better changelogs are needed. @aduth has been working on a PR to enforce better changelog management. It explores adding a pre-commit githook which verifies that the contents of the pending commit include a CHANGELOG.md revision if applicable.

Some concerns were raised about the potential unwanted friction a githook could give and false positives that could occur when ie. committing typo fixes. A possible alternative is to make the check part of the Travis build for PR’s. On the other hand, the direct feedback gotten through the githook contains higher educational value and minimizes loss of context.

We agreed the current githook proposal was worth exploring further in order to see if false positives can be prevented.

Agenda: Code owners

Slack Conversation

A pull request which adds an initial implementation of a CODEOWNERS file in Gutenberg was merged.

You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.

Github Help

Contributors are invited to PR the file if they feel they would like to be added as a code owner for specific paths in the Gutenberg repository. When accepted, they will receive pull request notifications and review requests for these parts of the codebase.

The main goal is to alleviate some review pressure for the Gutenberg team and help distribute notifications and help requests better over more contributors. It was argued it could be good to have some guidelines for approving / merging PRs in order to allow new contributors and code owners to review with more confidence. The use is expected to further evolve and be evaluated in the coming weeks.

Agenda: Registry selectors

Slack Conversation

For a while now we’ve had the option to register multiple stores across multiple registries using the core/data package. But how can we create selectors which derive data across multiple stores / registries? A PR to tackle selecting data over multiple stores has been created by @youknowriad. Input and feedback is requested.

An effort that depends on this is a PR which tries to make the editor module more generic so it can be reused outside of WordPress. We need to be able to respect backwards-compatibility while moving selectors and action dispatchers from one module to another. See also: https://github.com/WordPress/gutenberg/pull/13088

Open floor: React hooks

Slack Conversation

React hooks has been included in the latest release of React. There is a PR on Gutenberg which explores the possible advantages of this new API: https://github.com/WordPress/gutenberg/pull/11161. Since Gutenberg relies heavily on React, it could be worthwile checking out the API and the ways it could be leveraged in Gutenberg.

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

REST API Chat Summary: January 24, 2019

This post summarizes the weekly REST API chat meeting on January 24, 2019. (agenda/notes, Slack transcript). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

Have a topic for discussion for the next meeting on January 31, 2019 18:00 UTC? Leave a suggested edit on next week’s agenda.

5.1 Tasks

  • One open Docs task: #45486 needs review (PHPDoc)
  • Awaiting Review ticket list needs triage & grooming but nothing currently stands out as a 5.1 priority

Tickets Awaiting Review

  • @desrosj to lead a bug scrub for this list next week, on Tuesday January 29, 18:00 UTC
  • As time permits prior to Tuesday, contributors may review that list and assign the Future Release milestone to any valid issues to show they have been triaged

5.2 Priorities

  • 6 tickets currently milestoned for 5.2. @desrosj proposes that every ticket assigned to a numbered release have an assigned owner.
  • Milestoned Tickets needing owner or review:
    • #41305 – Lazy String Evaluation: assigned to @timothybjacobs to investigate invalidating cache when locale changes within a request lifecycle
    • #39953 – Avoid updating date when modifying a “date floating” post (Related to #44975): needs owner
    • #44983 – Needs review
    • #45611 – Needs patch update to remove unused method

Gutenberg Priorities

  • content.rendered is not used by Gutenberg, and filtering the content for a large post slows down the editor load speed. @aduth suggests extending ?_fields= support to permit “deep” filtering, which the posts controller could then use to skip filtering post content where not needed, and raised the issue last week in the REST API component channel.
  • Delivering on this performance improvement within the block editor is architecturally complex, but implementing the nested _fields handling is tracked in #42094 and that ticket is now milestoned for 5.2 to lay the necessary groundwork.

Upcoming Meetings

What can the REST API do for you? Join an upcoming meeting to let the component team know!

#meeting-notes, #rest-api

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

Javascript Chat Summary – December 4, 2018

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: Holiday / WCUS scheduling

Slack Conversation

We agreed to cancel the #core-js meetings for December 11th (post-WCUS travel), December 25th (Christmas), and January 1st (New year). @aduth posted a cancellation notice here: https://make.wordpress.org/core/2018/12/04/javascript-weekly-chats-wordcamp-us-holiday-scheduling/

Agenda: Linting

Slack Conversation

A PR which extracts Gutenberg’s ESlint config to its own package by @gziolo has been merged. It’s set to be published to NPM as @wordpress/eslint-config. Publication is currently blocked by the 5.0 RC freeze, but is expected to land around contributor day together with a post outlining revisions to the JavaScript coding standards prepared by @aduth

We also discussed how to manage custom eslint rules. Some linting rules might not be useful outside of the context of WordPress core or Gutenberg. We decided for now to go the same path as the Jest eslint package. For the time being we will have one package with multiple configs, which will allow consumers to select the configs they need. 

Agenda: 5.0 Script Changes

Slack Conversation

With WordPress 5.0, a few vendor scripts (like lodash) are being included in core. For these scripts in particular, there is a chance for conflict if a plugin or theme registers their own copy of the dependency with the same un-prefixed name. There is a greater likelihood if there is a large version mismatch between the registered scripts.

Different approaches to prevent this were discussed. @aduth is working on a devnote to help integrators prevent these kinds of conflicts from happening.

#javascript, #meeting-notes #summary

JavaScript chat summary – November 20th

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.

We tried to keep the meeting succinct as many people are pushing out a Gutenberg release.

Correcting Package Global Names

Relevant context in a previous Slack discussion. Question: Should we “deprecate” wp.escapeHtml to wp.escapeHTMLwp.tokenList to wp.TokenList?

There was a bit of a back and forth whether this should be something that is addressed now. At the end we concluded to add this to the list to address in a 5.0.x release.

Npm packages publishing workflow

From last week, we discussed this very briefly to keep it in our mind space. Link to the relevant issue on the Lerna repository.

#chats, #javascript, #meeting-notes

REST API Team Meeting Notes, 2016-10-17

As a reminder, in just 30 minutes there is a meeting in #core to decide whether the REST API Content Endpoints will be merged as a part of WordPress 4.7! See the ongoing discussion of this proposal here. Note that the OAuth server is no longer proposed for merge at this time, but authentication options will be a primary focus area for the API project during the 4.8 development cycle.

The REST API Content Endpoints provide a new foundation upon which the WordPress developer community can build themes, plugins, and core feature. They represent a common standard and consistent interface across WordPress’s core content data types, and provide robust support for custom post types and meta values. These endpoints lay the foundation upon which future releases will add remote authentication options, even deeper querying abilities, and broader endpoint coverage for site management. This iterative approach fits WordPress’s development model and philosophy, advancing the project’s long-term goal of opening WordPress up to a wider developer audience and helping to ensure continued work on the REST API in the release cycles and years to come.

Meeting Notes

At today’s weekly API team meeting in core-restapi (agenda here) the team resolved all outstanding decisions milestoned for the REST API 2.0 / WordPress 4.7 merge candidate:

  • The ?filter query parameter will be removed from the REST API plugin prior to core merge, a breaking change that improves the consistency of querying the API and eliminates a set of parameters that could introduce backwards compatibility issues were they to be committed to WordPress core. A separate plugin will be published to reinstate the `filter` parameter on a strictly opt-in basis.
  • Comments on password-protected posts are being deferred as a future enhancement until a robust solution is proposed that permits the API to adequately mirror existing functionality.
  • The unfiltered_html capability should be respected by the API, and a patch will be submitted to bring the API’s behavior in line with core’s.

There are 29 tickets left in the 2.0 milestone, several of which have open pull requests already. These issues represent a mix of outstanding bugs, documentation needs and improvements that will be moved to trac should the merge proposal be accepted.

The REST API team leads would like to recognize that the content endpoints plugin now has 95 contributors: thank you and welcome to all of the new participants who have joined the project in the past week!

#4-7, #meeting-notes, #rest-api

Core Dev chat notes for Feb 17

Agenda

Schedule Notes, Status Updates, Open Floor

Schedule Notes

  • Today is the feature plugin merge deadline!
  • Customizer Responsive Preview was merged. Thanks to everyone who helped out there!
  • The first beta is scheduled for release next week! This means that any remaining features/enhancements need to land before then.
  • @chriscct7 has been leading daily scrubs of these tickets; ticket owners should post an updates on the ticket status.

Status Updates

  • Image Improvements: @joemcgill
    • Improving the performance of wp_uploads_dir() (#34359). @azaozz committed this and left the ticket open for possible function name changes or additional tests.
    • PDF Thumbnails (#31050) are close. Creates a thumbnail version of uploaded PDFs. Feedback would be welcome, particularly from UI focused folks and around how the PDF thumbs’ meta is stored. This needs careful consideration as it would be a model for any other thumbnails for non-image types. The intent for this release is to improve the editor experience a bit, which the thumbnails would achieve.
    • Improving default image compression (#33642): Looks like we should be able to reduce the default compression quality and see big improvements in file sizes without a perceptible loss in image quality. Look for a blog post requesting feedback later this week to make sure core is ok with changing the default quality for intermediate sizes.
  • Customizer: @westonruter, @celloexpressions
    • Published a post on Make Core that detailed Selective Refresh in the Customizer. Hoping to get feedback on the implementation for nav menus and widget, on the framework for theme/plugin authors to register their own partials for selective refresh, and also for a general code audit for security and docs. In the process right now of creating that core patch and will attach to the ticket #27355. I’m also in the middle of writing unit tests, but help there would be appreciated.
  • Multisite/WP_Site: @jeremyfelt
    • No big updates. Started making progress on a few tickets today. Nothing negative or breaking with the new `WP_Site`, though we’ll continue to keep testing and looking for ways to improve. @spacedmonkey has also submitted a ticket for `WP_Site_Query` which will be fun.
  • Editor: @azaozz, @iseulde
    • Thinking and testing if the inline link dialog should have two fields, URL and link text, like the modal. Seems the more streamlined version with just the URL is better.
    • Another change that’s coming is to add autocomplete to the modal instead of the infinite scroll at the bottom. That gives plugins some more space to add additional “advanced” settings and simplifies it/makes it consistent with the inline dialog.

Open Floor

  • @mike Wanted to discuss Theme Logo Support (#33755).  @obenland was kind enough to do a port of the feature from Jetpack, and there’s been good conversation happening on the ticket. It needs testing. Can be tested with Twentysixteen and a patch and with any theme that supports Jetpack site logos. Needs work on this suggestion.
  • @ocean90 raised Unifying permission error messages (#34521). Right now we use a variety of  language for error messages and this ticket is about unifying and clarifying that language. @ocean90 asked for opinions about the best language to inform users they are not allowed to perform some action. Extensive discussion ensued and Sorry, you are not allowed to… seemed to be the top choice.

Full meeting log available in Slack.

 

#4-5, #dev-chat, #meeting-notes

Core Dev chat notes for Feb 10

Agenda:

Schedule Notes, Status Updates, Open Floor

Schedule Notes

  • Today is the feature plugin decision deadline: Responsive Preview and Selective Refresh will be merged.
  • Next Wednesday (Feb 17) is the deadline for merge for these, with beta scheduled for the week after, on Feb 24.
  • Reminder: once beta ships, no more enhancements can be committed, so anything that is left or close to finished needs to be shored up in the next two weeks. Enhancements mile-stoned for 4.5 need attention to make it into the release in time.
  • Any help triaging the 4.5 milestone is definitely appreciated.
  • The REST API team’s proposal is to merge the four main endpoints when they are ready, and they are not ready for 4.5. As such, no endpoints are targeted for WordPress 4.5. A summary of last week’s chat is on make/core: leave feedback there or in the #core-restapi Slack channel.

Status Updates:

  • Image Improvements: @joemcgill
    •  Cache output of `wp_upload_dir()` to improve performance (#34359) is about ready to go in after some unit test updates )
    • Making progress on Improving Imagick file sizes (#33642) and Better animated GIF handling (#28474)
    • @markoheijnen made some interesting progress on generating thumbnails of PDFs in the media library and could use some feedback if you’re interested #31050.
  • HTTPS Improvements: @johnbillion
    • Plan is enforcing HTTPS on a per-feature basis (eg. enqueued assets, post content, redirects, canonical, links).
    • HTTPS-by-default on install will be something to aim for for 4.6, but we’ll see what happens over this next week.
  • Customizer: @westonruter, @celloexpressions
    • Pushed out the new version of the Customize Partial Refresh plugin. Needs testing!
    • Introduces a framework for registering partials (refreshable regions) with complete rewrites of nav menu partial refresh and re-implementation of widget partial refresh to use the new framework.
    • Going to write a Make Core post about it, documenting the API.
    • Biggest question is whether widgets should opt-in for selective refresh by default. Widgets that use JavaScript for their display will need get updated to work with selective refresh.
    • Responsive Preview (#31995) @valendesigns:  need to add unit tests and address any remaining issues
  • Multisite/WP_Site: @jeremyfelt
    • 15 tickets on the 4.5 milestone. Hoping to establish readiness for these over the next week and get some stuff in.
    • Going to start focusing more multisite related energy toward the REST API’s site (and meta) endpoints.
  • Editor: @azaozz, @iseulde
    • No updates this week: planning to get paste shortcuts in and work on mce views.

Open Floor

#4-5, #dev-chat, #meeting-notes