JavaScript Chat Summary: March 31, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Many thanks to @cbravobernal for compiling these notes!

TypeScript Types from Packages

(Slack conversation)

WordPress packages will now ship with their own first-party TypeScript types!

Pull request: https://github.com/WordPress/gutenberg/pull/18942

The types (declaration files) will be published with the packages, so folks using the packages via npm will have access without doing anything else.

The type generation is built into the existing package build/publish flow, so things should remain largely the same from the perspective of Gutenberg development (hopefully with better information in our IDEs!)

npm run build:package-types is the script that generates them.

Awesome job! Kudos!

Action:

JSX support for wordpress/scripts

(Slack conversation)

Link to the issue

PR proposing it for formatting command.

There is a small discussion about seeing if it is necessary to discourage or not jsx files. Noticing that changes to accept jsx are quite simple. And are even accepted in some code already. There are different opinions, so the team prefer to continue the discussion.

Action: 

Open Floor

Updating Jest Error

@gziolo had issues upgrading Jest with the last version. See pull request. Asks if is it a good reason to refactor them to use the React Testing Library?

@aduth comments that is Enzyme related issue. That expects a DOM to exist.

Airbnb transferred the project to the community. Seems that everyone is going to switch away from Enzyme.

Also they comment that Jest, Babel and Puppeteer should be upgraded, and would be nice to have some strategya arount all that. The project seems to have too many dependencies.

Action:

  • No action defined.

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.

#core-js, #javascript

JavaScript Chat Summary – March 24, 2020

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: Date module dateI18n gmt parameter (added by @davilera)

Slack | Pull Request

This is a pull request that has been around for a while and David has addressed all the feedback given so it’s ready for merge.

Action: @iandunn pinged to verify the latest round of changes and that it tests good.

Agenda: Module naming and deprecations (added by @aduth)

Slack | Github and Comment including links to previous discussions

Topic concerns aligning naming conventions for wp globals on package exports.

Actions:

  • Merge pull #18722 that documents how to use ServerSideRender from the wp.serverSideRender export. (Done)
  • Create an issue to track the broader effort of “fixing” the names for these globals. (Done)

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad

Other Random Stuff

#javascript, #meeting-notes

JavaScript Chat Summary: March 17, 2020

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 Items

JSDoc Documentation Standards

(Slack conversation)

Question: Does it make sense to document changes to a function over time, and if so, how?

Context: https://github.com/WordPress/gutenberg/pull/20427#discussion_r386396607

The current JavaScript documentation standards restrict the @since tag to include only the version number:

@since x.x.x: Should always be 3-digit (e.g. @since 3.6.0).

This is in contrast to the PHP documentation standards, which include guidelines around using @since as a changelog:

If significant changes have been made to a function, hook, class, or method, additional @since tags, versions, and descriptions should be added to provide a changelog for that function.

Proposal: Incorporate some adaptation of the PHP since changelog guidelines into the JavaScript inline documentation standards.

Discussion Points:

  • @nerrad asks if this could be used to pull documentation automatically from the source code. This is quite possible, and is likely exactly what is done with the PHP source code documentation (example documentation and source).

Action Items:

  • Update the JS documentation standards, assuming there is no opposition presented in the coming days.
  • Disable the JSDoc since format validation for Gutenberg in the related changelog (already done)

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad

Other Random Stuff:

#core-js, #javascript

JavaScript Chat Summary: March 10, 2020

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.

News roundup proposal

(Slack conversation)

@nerrad as been kind enough to offer to share an aggregate of news relevant in the Gutenberg and general JavaScript ecosystem, to include in the summary notes for each week’s meeting.

Discussion:

  • There was an agreement that it’s a great idea.
  • The plan is to add this as an extra section in our JavaScript chat summary starting from this week.

Action items:

  • New agendas should be structured to include separate sections “Agenda Topics” and “News Roundup”
  • Note-takers should aim to include these items in the published summary notes.
  • Update “Note Takers” document guidelines.

ESLint “prefer-const” relaxation proposal

(Slack conversation)

@aduth added a pull request about a potential revision to our default ESLint configurations (i.e. coding standards) at https://github.com/WordPress/gutenberg/pull/20737. He just wanted to bring it to attention, since any of these sorts of coding standards changes are good to highlight. There’s been some positive feedback already on the pull request that was echoed in the chat.

Visual regression testing tools

(Slack conversation)

@isabel_brison created a ticket https://core.trac.wordpress.org/ticket/49606 to introduce visual regression testing in the WordPress core, so we can clean up some of the old CSS with confidence. She was wondering if this type of testing has been discussed or explored at all for core or Gutenberg. Also, would there be value in adding it for Gutenberg, too?

Discussion:

There’s no visual regression testing in Gutenberg as of today, but there are parts of the tooling that could make it possible, like taking screenshots with the headless browser via Puppeteer. At least with the ticket as presented, it seems primarily focused on existing screens which may not be expected to change, and thus primarily with the aim of preventing regressions while doing CSS refactoring.

The tests themselves are minimal, but the reference images are not insignificant though and need to be updated periodically. The biggest concern is the size of the assets that would have to be maintained and how to ensure they don’t pollute repositories with source code.

There is an existing prototype in the Gutenberg repository (https://github.com/WordPress/gutenberg/pull/18797) that uses 3rd party service percy.io that can be used as a reference when exploring the final implementation.

Introduce a common API to style Button from both web and mobile

(Slack conversation)

There is a pull request that explores primitive UI components that can be used both in native mobile apps and in the browser: https://github.com/WordPress/gutenberg/pull/19104. There was no specific discussion item attached to this, but it was requested that anyone interested take a look and provide any feedback they have to drive further development.

News roundup

A few links to Gutenberg and JavaScript related news (curated by @nerrad).

WordPress 5.4 dev notes

Other random stuff

#core-js, #javascript

JavaScript Chat Summary: February 25, 2020

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.

Unit testing revisited

(Slack conversation)

The current tooling used for component testing in Gutenberg was observed to not support support React portals. An implementation of a new testing utility module was originally proposed, then later resubmitted as an incremental approach to adopt React Testing Library.

Discussion:

  • Is this about limitations of the tooling for fundamental React features, or about our approach to testing? It appears to be a little of both.
  • The conversation evolved into a discussion of how we want to test components, essentially distilled to a distinction between white-box and black-box testing.
  • There was some unclarity around what impact React Testing Library would have on our existing tools. @hazdiego joined the conversation, pointed to an earlier GitHub comment contrasting the solutions, and clarified that while it has feature parity to support replacing existing tools, it also comes opinionated with integration-style testing.

Action items:

Open Floor

WordPress 5.4 Deadlines

(Slack conversation)

@adamsilverstein made note that the WordPress 5.4 release is quickly approaching and that any work not addressed soon would need to be punted to a future release.

@aduth mentioned that a polyfill fix for URL will be needed, and that he would appreciate attention on the corresponding patch at #49360.

Webpack Build

(Slack conversation)

@gziolo mentioned that changes to the Webpack build were introduced with #48154, where one asset file is created containing all JavaScript entry points. This generated file is used to iterate and register all core scripts output from the Webpack build.

@gziolo mentioned a desire to improve upon this with better handling between development and production environments. He gave an example of the wp-warning package, which should be considered unnecessary for production, since it is a noop in that environment. Due to time constraints, this is planned to be discussed further in next week’s meeting.

#core-js, #javascript

JavaScript Chat Summary: January 28, 2020

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.

Create block package

(Slack conversation)

New @wordpress/create-block package was merged in the past week: https://github.com/WordPress/gutenberg/pull/19773. The package is meant to help plugin developers scaffold new blocks with a single command npm init @wordpress/block.

It is already available on NPM. It was published today as part of the next Gutenberg plugin release process that started on Monday.

Playwright vs Puppeteer

(Slack conversation)

Last week, Microsoft announced its new “Playwright” tool, which is very much like Puppeteer and created by many of its original contributors. The main draw here is that it supports multiple browsers, whereas we’ve always been limited to just Chrome using Puppeteer.

We discussed whether we should consider migration from Puppeteer to Playwright but we decide to postpone the decision for some time. The reason for that is the uncertainty about how those two projects evolve. The fact that the Puppeteer team has just released a new version that supports the Firefox browser makes it even more interesting. We plan to revisit this topic in the future.

#core-js, #javascript, #summary

JavaScript Chat Summary: January 21, 2020

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.

New “create-block” package

@gziolo has opened a pull request to propose a new “create-block” package, intended to be used by plugin authors to scaffold new blocks. This is the result of work which had been previewed during a previous meeting’s open floor.

Discussion points:

  • Separate package vs. part of the existing scripts package?
    • Needs to be separate to be usable as an npm init initializer.
    • We could decide later to add something to scripts which “proxies” commands to the separate package
  • Differences from the existing WP-CLI scaffold script?
    • Embraces build tooling, vs. intention of WP-CLI script to be run-and-done
    • Can be run outside a WordPress environment
  • Future goals

Action Items:

Open Floor

  • @epiqueras shared a problem which has surfaced in development of the block editor relating to values in inner blocks contextual to their ancestor blocks. He has worries about the performance impact of the current approaches, and has proposed an idea for a solution to improve the block API in a way which creates a shared context for block values.
  • @davilera raised an ongoing discussion regarding date function inconsistencies. This was also discussed during last week’s meeting. As an action item, he would like for a decision on the desired behavior and function signatures. We want to avoid backwards-incompatible changes. The pull request in its current form is sufficient for fixing an existing bug. After some discussion, a plan emerges that changes toward a more desirable API can and will be made within the current pull request without introducing breaking changes.

#core-js, #javascript

JavaScript Chat Summary: January 14, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript). Thanks to @cbravobernal for compiling these notes.

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

Date package

(Slack conversation)

@davilera mentions in the pull request issues a developer might face when using the date package and proposed how to solve them. Namely, source timezone, target timezone, and possible translation of the final date. People noticed that the package is not considering timezone.

Regarding PHP side, date_i18n() is remarked to be “illogical, incompatible with Unix timestamps, and in order to be deprecated”.

Action:

  • Identifying the minimum changes required to fix the original issue that PR tried to solve
  • Open a new issue where a discussion on if and how to refactor the package
  • Look at the current PHP implementation and trying to reconcile the two

Dropdown rendering with modals

(Slack conversation)

At first, the dropdown wasn’t rendering properly. But once the positioning was fixed, two more issues arose:

  • In a dropdown with multiple fields (such as, for instance, the one you get when using DateTimePicker), tabbing from one field to the other doesn’t work, as the focus moves away from the dropdown, back to the modal. This is an accessibility issue.
  • Dropdowns should be closed when one clicks outside of them. But this only works if you click outside of both the dropdown and the modal. Clicking on the modal doesn’t close the dropdown. Dunno what kind of issue this one is.

The mechanism that are affecting this behaviour is the SlotFill system 

@itsjonq says that the mechanism that are affecting this behaviour is the SlotFill system, and currently @hazdiego is working on an (unrelated) PR to start refactoring it:

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

After a little discussion about how hard is to work on focus, modals, dropdowns…

Action:

Open Floor: Markdown linter

(Slack conversation)

@mkaz announce that he introduced a lint-md script that lints code blocks inside markdown. This uses a new .eslintrc-md.js config in scripts package to turn down some of the noise due to documentation being snippets of code.

Right now you need to run manually, we can fine tune and adjust the config before automating further. Try it out using: npm run lint-md [your-file] or if no file specified it runs across all markdown documents. 

Removing ES5 snippets is discussed also.

Action:

  • Try out the new script lint-md especially if writing or updating any markdown and source and we can see how it goes

Open Floor: NPM publishing

(Slack conversation)

@gziolo propose to grant npm permissions to @jonsurrell and Bernie Reiter so they could help with releases. Also talk about automate CHANGELOG file updates on the release day.

Action:

  • Grant NPM accesses (owned by @aduth)
  • Keep working on improving release workflow.

#core-js, #javascript

Javascript Chat Summary – January 7th, 2020

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: WordCamp Asia Contributor Booth

Slack | WCAsia Request

WordCamp Asia team is asking if folks from the #core-js team will be coming to the contributor day. From those at this week’s meeting, the following indicated they will be there:

Some topics that were suggested as things to work on during this day:

  • TypeScript
  • Storybook
  • Unit tests
  • Automating project management

The contributor table will be co-lead by @adamsilverstein, @aduth, @gziolo , @epiqueras (in some way, split between the Gutenberg and core-js tables)

Open Floor: Prettier Update

Slack | Github

Question: Is the goal to eventually run prettier on our existing codebase?

Answer: Yes, the goal is to run Prettier on the whole Gutenberg codebase and keep it formatted.

Open Floor: Move Some Build Tests to Github Actions

Slack | Github

@netweb recently added a Github Action to the Gutenberg Examples repository for doing a npm run build and jest tests. @gziolo thought it’d be good to do something similar in the Gutenberg repo to free up Travis jobs and get better feedback.

Open Floor: Use CSS-JS more widely?

Slack

@itsjonq asked:

I would love to know if using Emotion (or some CSS-in-JS method) is a strategy folks are comfortable with.

comfortable enough for some refactors to happen with the primitive components.

Initial big convo on CSS-in-JS was discussed in this github pull.

There was some discussion in the meeting about this with points ranging from strong reservations against using CSS-in-JS, to it being a good fit for @wordpress/components.

While it’s not clear there was a definite decision at the meeting, there seemed to be some consensus around this final point made by @youknowriad:

My personal opinion is that I’m fine with it being explored if it’s only for @wordpress/components for now without impact on external API

#javascript, #meeting-notes

Javascript Chat Summary: Tuesday, December 17, 2019

Below is a 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 the next chat agenda.

Next Javascript meeting is January 7th, 2020.

Because of a lot of people being AFK for their holidays we’ll skip the next two meetings.

Prettier

@aduth introduce the topic by saying:

There’s been quite a bit happening this past week, both in the comments of the revisions proposal post, and in the original pull request.

Post: https://make.wordpress.org/core/2019/12/09/proposed-javascript-coding-standards-revisions-for-prettier-compatibility/

Pull request: https://github.com/WordPress/gutenberg/pull/18048 

I think we’re in a position to make a decision on how to proceed here. From the feedback to the post, there are some general thoughts around improvements to the standard, but not any reluctance to Prettier specifically (quite the opposite, in fact!)

It would seem to me that most people are on board with this. Does anyone have any last-minute thoughts on this, or would it be fair to say we can move forward with adopting Prettier?

Based on the comments of the PR and the conversation in the chat, it seems we are in a position to merge this work.

@jsnajdr referred that the PR adds a format-js script to wp-scripts, and provides support for IDE integrations. Well-behaving Prettier editor integrations should pick up the config and the fork binary automatically.

@mkaz proposed a PR that documents these changes at https://github.com/WordPress/gutenberg/pull/19074.

The conversation went on @jsnajdr noted that the PR does not yet format the code, but we can easily format it with `wp-scripts format-js`.

@gziolo showed availability to collaborate/discuss with @jsnajdr how format-js will operate after the PR is merged.

@gziolo noted that having prettier code formatting will alow inline snapshots on the test cases https://jestjs.io/docs/en/snapshot-testing#inline-snapshots.

@aduth proposed the following action items:

  1. Merge @jsnajdr‘s pull request.
  2. Review, merge @mkaz developer tools documentation.
  3. Submit standards revisions changes.

After @jsnajdr‘s pull request is merged:

  1. Create a pull request to apply formatting to the entire codebase
  2. Explore options for automated formatting.

Participants agreed on the plan.

Block Scaffolding

@gziolo shared the following GIF showing block Scaffolding working:

Block Scaffolding Tool

@gziolo managed to implement ESNext template support with wp-scripts integration and is wondering if this scaffolding mechanism should be part of the Gutenberg repository.

Participants started discussing if this solution is part of the Gutenberg repository, what will happen to the current “official” scaffolding solution offered in WP-CLI. There are technical restrictions in making something equivalent to the solution @gziolo proposed on WP-CLI because WP-CLI should not depend on node.

@gziolo will continue iterating on the new scaffolding solution and, once tested, will import it into Gutenberg.

SVGR support in wp-scripts

@mkaz started the topic by saying:

I have a PR that adds SVG support to it which is a handy addition, but not sure if we want to add it without having the same support in core Gutenberg: https://github.com/WordPress/gutenberg/pull/18243 

For core blocks, we don’t inline SVG, we always code them, so this mechanism would not be used by core blocks, but it may be helpful for third party block developers.

@gziolo said Parcel 2 is heading in the direction of supporting CSS and SVG imports. @aduth said Parcel faces a similar challenge, and it may be a useful reference of how to address this problem.

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