Tag Archives: core-js

Omar Reiss 11:39 am on March 28, 2019
Tags: core-js, , ,   

JavaScript chat summary, March 26th, 2019

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: Building JavaScript

Slack Conversation

A post was published on the core Make blog titled Building JavaScript. It explains how to set up an ESNext development environment using the new WordPress scripts package. This provides an easy and standard method for building blocks and JavaScript heavy plugins.

The discussion continued towards a potential followup task: to offer a scaffolding package that would help to create your first block. This could then in turn be utilized by the wp scaffold command in WP CLI, to allow scaffolding blocks directly with WP CLI. The discussion continues on Github here: https://github.com/WordPress/gutenberg/issues/10629.

Agenda: Coding Guidelines

Slack Conversation

Coding guideline changes have been proposed for CSS naming and Experimental / Unstable JS API’s in Gutenberg. Feedback is welcome!

Agenda: Gutenberg Playground

Slack Conversation

A standalone Gutenberg playground environment has been merged. As we’re expanding the usage of Gutenberg outside of edit-post and also talking about cross-CMS usage and external usage (in the broad sense), we need a way to run the block editor in a context independent from WordPress Admin.

The playground allows us to test Gutenberg as a standalone editor. For example, we can use it to test that our components don’t rely on WP Admin styles to be present, that core blocks can be used without necessarily requiring a post object.

This is only a first step. The playground could evolve to contain examples of reusable components, and it could also serve as a contributor-tool to help developers discover API’s.

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

Marcus Kazmierczak 1:04 pm on March 25, 2019
Tags: , core-js,   

Building JavaScript

The Gutenberg Handbook shows JavaScript examples in two syntaxes: ES5 and ESNext. These are version names for the JavaScript language standard definitions. You may also see elsewhere the names ES6, or ECMAScript 2015 mentioned. See the ECMAScript Wikipedia article for all the details.

ES5 code is compatible with WordPress’s minimum target for browser support. It can run straight in your browser and does not require an additional build step. In many cases, it will be perfectly fine to follow the same approach to start experimenting with your plugin or theme quickly. As soon as your codebase grows to hundreds of lines, it might be a good idea to take advantage of all the great JavaScript features included in ESNext syntax.

With the release of Gutenberg 5.3, the @wordpress/scripts package was updated to include webpack and Babel configurations. The update makes setting up an ESNext development environment much easier for building blocks and creates a standard method for developers to set up their plugin.

The documentation in the JavaScript tutorial and the ESNext examples in the gutenberg-examples repository are both updated to include the new process.

Here is a quick overview of how to set up an environment. First, you need to install @wordpress/scripts package:

npm install --save-dev @wordpress/scripts

You can then update the scripts section of your package.json to include:

"scripts": {
    "start": "wp-scripts start",
    "build": "wp-scripts build"
}

No webpack config (e.g., webpack.config.js) or Babel config (e.g., .babelrc) is needed.

The scripts expect the source file to be found at src/index.js and will output the build to build/index.js. So if you are migrating an existing plugin, you will need to move your source and enqueueing to these new locations.

With the setup in place, the standard workflow is:

  • Install dependencies: npm install
  • Start development builds: npm start
  • Develop. Test. Repeat.
  • Create production build: npm run build

In general, the package should be used with the set of recommended config files. While it is possible to override every single config file provided, if you have to, it means that your use case is more complicated than anticipated. We’d love hearing about it as we’d like to iterate on the current setup and offer more flexibility in the future. At the moment, our recommendation would be to use the underlying tools (webpack, Babel) directly.

See the JavaScript Build Setup documentation for a full explanation and walk through, and see the scripts package documentation for all the details.

Props to @gziolo and @nosolosw for their efforts.

#core-editor, #core-js, #javascript

Darren Ethier (nerrad) 3:04 pm on March 19, 2019
Tags: core-js,   

Javascript Chat Summary – March 19, 2019

Below is a 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: Reconciling WordPress and Gutenberg Script Handles

Context | Previous Effort | Slack

Some points there seemed to be consensus on:

  • As needed, existing scripts in WP core will be pulled into the GB repository, exposed as their own package, and then re-registered for use in core.
  • Old handles will still be present for back-compat, but redirect to new handles.

Initial effort regarding this will happen for:

  • shortcode package: https://core.trac.wordpress.org/ticket/44987
  • a11y package: https://core.trac.wordpress.org/ticket/45066

Agenda: How should uncaught errors be handled

Context | Slack

There was much discussion on not only the specific issue (see context) that triggered this agenda but also how this might be generalized. In conclusion, there was some consensus to explore something along the lines of [this solution](https://gist.github.com/aduth/f464f2d549a80716127a7e0d575b102f) in concert with implementing error boundaries in withSelect to see how they interact and work. So short-term focus will be on fixing the immediate issue with errors in subscriber listeners.

Further discussion effort on this will be done in the pull request @aduth will own this issue (in collaboration with others who help).

Agenda: Reusable Scripts

Context: here and here | Slack

This is work towards making the Javascript build setup for plugins much more simplified.

We reached the point where we exposed every tool Gutenberg uses adjusted for external plugins development

@gziolo

Related packages will be published soon.

Action Items:

  • update repository (once package is updated on npm) (@gziolo)
  • dev note about the package linking to the docs and repository (@gziolo)

#core-js, #javascript

Anton Timmermans 12:59 pm on March 13, 2019
Tags: core-js,   

JavaScript Chat Summary, March 12th, 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.

Daylight savings time

Slack Conversation

@aduth proposed to not move the meeting time this instance, because for some people having the meeting an hour later means they can attend. If you have any feedback on this proposal, please leave a comment.

Default webpack configuration

Slack conversation

A default webpack configuration pull request has been merged to wp-scripts. So plugin authors can now do wp-scripts build and that will build their JavaScript into a bundle for the browser.

There was a brief discussion on whether or not the build command should accept a custom webpack configuration. For now this will stay possible. In the longer term the default configuration should be good enough for a lot of users and the Gutenberg webpack config should align with the default config as much as possible.

Pull request for typescript definitions

Slack conversation

The Gutenberg repository received a pull request with TypeScript definitions. This raised the broader question whether these pull requests should be accepted, because these definitions also need to be maintained.

In the chat the consensus was that it is only worth merging these kinds of PRs if the maintainability burden is very low. Given that is not the case it is probably better to not merge the given PR.

This will be decided on next week, please comment here with your ideas on this.

Removing grunt dependency from grunt-patch-wordpress

Slack conversation

@jorbin wants to make the grunt-patch-wordpress tool a general command-line utility that runs without a grunt dependency. Everyone agreed that this is a good idea. The new package will be located inside the monorepo like all other JavaScript packages.

#core-js, #javascript

Grzegorz (Greg) Ziółkowski 3:34 pm on March 6, 2019
Tags: core-js,   

JavaScript Chat Summary, March 5th, 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.

repository.directory

Slack Conversation

Following up from the previous week’s agenda item about the newrepository.directory field in package.json file. @greatislander was successful in having his enhancement merged into the upstream npm-package-json-lint package. He also followed up with a pull request to use it in Gutenberg.

Npm package release process

Slack Conversation

Right now the timeline for publishing npm packages is strictly tied to WordPress releases. Moving forward, the idea is they would be published more frequently as proposed by @youknowriad in this pull request. It is expected to start using the revised workflow soon after Gutenberg 5.2 release is out which is planned for Wednesday.

Docgen

Slack Conversation

@nosolosw merged a pull request with the first iteration of the @wordpress/docgen package, which will be used to auto-generate public API documentation from JSDoc comments. The idea is that the npm run docs:build command will re-generate the package’s README when something changes in the JSDoc comments. There is a master issue opened where follow-up tasks will be tracked. It’s expected to have a massive number of pull requests created which add public API documentation to most of the existing packages.

#core-js, #javascript

Andrew Duthie 3:16 pm on February 26, 2019
Tags: core-js,   

JavaScript Chat Summary, February 26th, 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.

Progress Updates

Slack Conversation

@greatislander finished adding repository.directory fields for each published package, and opened an upstream pull request to the npm-package-json-lint project so that can better enforce this for new packages introduced in the future.

@gziolo and @nosolosw completed work on extracting a reusable Webpack configuration which can be used by developers (e.g. plugin authors) to easily adopt a Gutenberg build workflow into their own projects. @nosolosw mentioned that work continues to use this configuration as the default when running wp scripts build if no explicit configuration is provided.

Package Releases Feedback and Enhancements

Slack Conversation

@youknowriad shared a summary of the current workflow for publishing npm packages, the shortcomings therein, and proposed a revision to the workflow which better supports more regular publishing accommodating WordPress minor releases.

I propose we update our workflow to the following: (assuming the version number of the packages are major.minor.patch)
– Rename the current g-minor branch (the branch from which the npm releases are made) to wp/trunk
– Every time a new plugin version is released (using our current plugin release workflow), merge this version into wp/trunk, do an npm package release by bumping at least the « minor » version number (or major but not patch)
– Every time, the WordPress SVN trunk is branched (to create WordPress 5.1, WordPess 5.2… branches) — this happens in general when the WordPress major RC version is created —, create a corresponding wp/5.1, wp/5.2 etc… in Github based on wp/trunk.
– This wp/x.x branch will serve to release package releases used in Minor and security versions of WordPress. All package releases happening from these branches will bump only the patch version number of the package.


Special cases:
– Sometimes WordPress trunk is closed (in general it last 2 to 3 weeks) between beta and RC. During this period, we’ll have a Gutenberg plugin release that is not going to be released as npm packages directly until WordPress trunk is open again.
– For previous WordPress versions that contain packages (5.0 and 5.1) we didn’t have enough room for package version upgrades for security and patch versions that might be needed in the future. For these particular cases, we’ll use the « build metadata » version modifier supported by npm. Example 1.2.4+sec.1

Discussion followed this proposal, clarifying details of the revised workflow. There was general consensus that the proposal was agreeable.

As a next step, @youknowriad plans to open a pull request proposing revisions to the current release workflow document.

Open Floor

Slack Conversation

@greatislander requested an update on when the jest-puppeteer-axe package would be made broadly available, as its unavailability is a blocker to the accessibility team being able to implement front-end tests for themes. In mind of the above release workflow proposal revisions, it was suggested that it could be published this week if the workflow changes are adopted.

#core-js, #javascript

Jorge Costa 10:28 am on February 20, 2019
Tags: , core-js, ,   

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

Omar Reiss 9:05 pm on February 10, 2019
Tags: core-js, ,   

JavaScript chat summary, February 5th, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agenda, Slack 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

Darren Ethier (nerrad) 3:47 pm on January 29, 2019
Tags: core-js,   

Javascript Chat Summary – January 29, 2019

Below is a 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: Unstable APIs

Slack Conversation

There was a conversation recently on Github where it became evident that marking an API as unstable is not sufficient enough in its own right to scare people away from using them (and subsequently being frustrated that they’re not documented).

This was a lively discussion around whether there are programmatic ways to make it harder for people to use things marked __unstable .

Due to the fact there aren’t a lot of occurrences of __unstable in the code currently, the general consensus seems to be that if people are using __unstable that is a risk they are taking and there shouldn’t be worry about removing it because it’s purpose is clear.

However, this could be revisited in the future if we see usage pick up and ideas mentioned in the meeting may be explored further then.

So readers, TAKE NOTE – use anything prefixed with __unstable at your own risk. Expect your code to break in the future if you are implementing it!

Agenda: New ESLint Rule

Slack Conversation|Related Github Issue

A new rule was introduced, no-unused-vars-before-return

Agenda: Yarn future (fyi)

Slack Conversation | Related Yarn Github Issue | Related Earlier Slack Discussion

Some discussion around some potential benefits this roadmap could have should yarn be adopted for WordPress builds in the future:

  • Yarn as an API (which could open the door to controlling some things from a GUI). This could allow for building easier developer tools.
  • Yarn as a package manager platform – which means there could potentially be one package manager for both npm and packagist.
  • Improvements to mono-repo management (in terms of managing both js and php packages)

This was mostly presented just to get on everyone’s radar. There’s nothing actionable at the moment.

As an aside: if you become aware of interesting developments in the javascript world, please do include them as fyi’s in #core-js meeting agendas!

Agenda: Package alignment with core

Slack Conversation | Related Make Post

@desrosj presented how looking at this trac ticket got him thinking about how we can better align package versions with Core to prevent issues like what popped up there.

Summary of what could become a proposal:

  • In simplest form, change version constraints in the package.json
  • When a major WordPress version is released (say 5.1), the versions of each package become restricted to only minor and patch updates to @wordpress/* packages and dependencies. This allows someone to run npm update when preparing a WP minor release (5.1.1) for beta.
  • When a new major WordPress version is prepared, a new major version of the Gutenberg packages would be released (if necessary), and WP core would be updated to use that new version. This next WP version (5.2) would be locked to that next version’s patch and minor updates only.
  • From a process standpoint, this would require the Gutenberg branches to somewhat match core’s. There would need to be a 5.1 branch after that is released. Instead of cherry picking changes by using package versions, we could only back port the appropriate changes to that branch and publish the X.X or X.X.X versions of those NPM packages

The difference between what is currently being done and what is being proposed is that whenever there is a major release of WordPress, all versions of packages will be bumped with major or minor (as opposed to patch).

One reason this was brought up is concern for how security patches etc will be back-ported to earlier WordPress versions in the future

Next Steps

  • Tighten up semver in @wordpress/* packages which means enforcing proper usage of CHANGELOG.md and properly differentiating between minors and patches. (No owner currently)
  • Explore more automation of the package management/updates in WordPress core (No owner currently)
  • This does need revisited in future meetings. Work should be done on identifying clearly the problems needing solved.

#javascript

Omar Reiss 10:50 am on January 23, 2019
Tags: core-js, , ,   

JavaScript chat summary, January 22nd, 2019

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