Exploration to support Modules and Import Maps

As the web continues to evolve, so does our approach to building and managing JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. in WordPress. Looking to the future, a collaborative effort is underway to explore native support for modern JavaScript modules and import maps within the WordPress ecosystem. This exploration is geared towards enhancing the developer experience by embracing the capabilities of modern browsers.

Introduction

JavaScript modules have transformed the way developers write and organize JavaScript code. They provide a cleaner and more modular architecture, making code easier to maintain, test, and reuse across projects. Today, the vast majority of web browsers offer native support for JavaScript module syntax, offering performance benefits and unlocking new possibilities in how we develop and manage client-side scripts.

In this realm, it becomes essential for WordPress to keep pace with these advancements and start experimenting with the addition of native support for registering and enqueueing JavaScript modules — including generating an import map directly within WordPress.

The primary objectives of this initiative are:

  • To leverage the native JavaScript module system available in modern browsers.
  • To streamline the development process in WordPress using JavaScript modules.
  • To determine the most efficient and effective methods for handling dependencies and optimizing loading times.

Prior discussions and experiments

The following links are some preliminary discussions and experiments that touch upon JavaScript modules and related approaches to script loading within the WordPress ecosystem:

However, the journey toward a modern, module-friendly WordPress is still in its early stages, and the next steps will be instrumental in deciding how best to integrate module support in a way that benefits developers and users alike, without disrupting the stability and familiarity of the current WordPress experience.

The experimentation phase

The current plan involves conducting initial experiments within the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. By exploring within this semi-contained environment, contributors will gain practical insight into constructing modules that are compatible with WordPress’ existing infrastructure. This experimentation will help make informed decisions on several fronts:

  • Deciding whether to extend the existing wp_enqueue_script function or introduce a distinct APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (like wp_enqueue_module).
  • Evaluating whether to maintain dependencies on the server vs relying completely on the client’s native resolution.
  • Establishing best practices for module identifiers, dependency registration, inline modules, preloading optimizations, and more.
  • Assessing integration challenges and ensuring backward compatibility.

It’s worth noting that while the experimentation will be kicked off using a separate API for simplicity’s sake, this doesn’t necessarily predetermine the final form of the proposal.

After conducting experiments, collecting insights, and incorporating the feedback received, an update that will outline a more specific implementation plan will be provided.

Potential enhancements such as dependency auto-detection and additional performance optimizations could be incrementally introduced later on.

Your input is important

Your perspective is crucial to the success of this initiative. Whether you are a plugin author, theme developer, coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. contributor, or anyone interested in the future of JavaScript in WordPress, join us in shaping a robust and forward-looking solution.

Get involved!

You are invited to participate in this exploratory phase and contribute your ideas, concerns, and suggestions. Below are some prompts to get the conversation started:

  • How do you currently manage JavaScript modules within your WordPress projects?
  • What challenges have you faced with the existing script enqueueing system?
  • In what ways can native support for JavaScript modules improve your development workflow?
  • Are there specific use cases or scenarios where you feel this proposal could greatly benefit you or the WordPress community?

Please share your thoughts in the comments below, on Trac, or participate in the ongoing discussions and experiments on GitHub. Your engagement is invaluable to work together toward a more modern, module-friendly WordPress.

Thanks to @youknowriad, @bph, @annezazu, @juanmaguitar, and @webcommsat for reviewing this post, and to the many contributors who have participated in the discussion around this enhancement already.

#core, #core-js, #javascript, #performance

Enhancing the Scripts API with a loading strategy

Overview

This post outlines a proposal to add a script loading strategy enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s existing Scripts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..  

The underlying goal of this effort is to make it easier for WordPress pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme developers and core to use “modern” loading approaches for JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. (like defer and async), which will help WordPress sites load faster and operate more smoothly, giving users a better experience.

Why add a loading strategy?

Data from the Web Almanac project (query) indicates that render blocking JavaScript is a significant problem on the web, with 77% of mobile pages having render-blocking scripts in the document <head> . This query shows that approximately 40% of WordPress sites stand to benefit from deferring additional scripts. Adding defer or async to script tags enables script loading without “blocking” the rest of the page load, resulting in more responsive sites overall better user experience.

Currently WordPress core as well as plugins and themes register scripts with the wp_enqueue_script and/or wp_register_script functions. Although these functions include the ability to control the placement of the script (with the in_footer parameter), they don’t include support for adding modern attributes such as defer or async to script tags. 

To add async or defer today, developers must resort to less flexible and more fragile approaches, such as directly filtering the tags at the point of output (using  the script_loader_tag filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.), or handling the tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) output directly using wp_print_script_tag and the wp_script_attributes filter.

Using the first approach and directly filtering the tag can easily break: for example if two plugins both try to filter a tag, or if a tag has unexpected attributes already (eg. adding defer to a tag that already has async). Using the the second approach developers must carefully handle dependencies and output manually – things that that the Scripts API usually helps take care of.

How the loading strategy works

Developers specify a loading strategy when registering or enqueueing a script. For example, a defer strategy can be specified when the script isn’t required immediately during the page load cycle. WordPress will then determine which scripts can actually use a strategy based on logic for each strategy. For example, to ensure that scripts are executed in the order they are enqueued, defer can only be used on a script if every script that depends on that script can also be deferred. Inline script tags added with wp_add_inline_script would also be considered to ensure proper execution order.

The implementation would come with several initial built-in loading strategies: defer, async, and the default blocking behavior.

Out of scope for this feature

The loading strategy does not enable direct control of script tag attributes. This idea was originally proposed 10 years ago in #22249 and several approaches were considered on that ticketticket Created for both bug reports and feature development on the bug tracker. including a script attribute filter. This proposal takes a step back and aims to solve the script loading strategy aspect more comprehensively and directly while avoiding exposing the potential complications of direct attribute control.

It is worth noting that it is already possible to control attributes on wp_enqueue_script tags directly using the script_loader_tag filter. However, this is a bit of a “brute force” approach which is limited and fragile because it doesn’t consider dependencies and multiple plugins can take conflicting actions on the same tag. 

What are potential concerns with this feature?

One big concern with adding this feature to the WordPress Script API is potentially introducing a breaking change. wp_enqueue_script is a fundamental API in WordPress core, and any breaking changes could have widespread implications. Possible breakage is a possible reason that adding custom attributes as proposed in #22249 was never added to core.

This new proposal aims to ensure that there is 100% backwards compatibility, resulting in zero risk of breakage. The loading strategy will ensure that all existing uses continue to function as expected; for example, passing the boolean in_footer attribute will still control script placement. In addition, it will ensure that scripts continue to be executed in the order they are enqueued – as described above in the “How the loading strategy works” section.

Conclusion and Next Steps

Giving developers the ability to specify a loading strategy will enable them to use more advanced JavaScript loading methods while still ensuring that enqueued scripts are executed in the correct order. A “strategy” approach is also forward thinking: as the web evolves, new strategies can be developed and made available to WordPress developers. After gathering feedback, we will proceed to discussing the implementation approach and, ultimately, proposing a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..

Have you tried using defer or async with WordPress (or do you already)? How do you think this enhancement would change that? Please leave your feedback about this proposal in the comments below and if you can, join us at our weekly performance team chats, where we are likely to discuss this proposal in the future.

Thanks to @flixos90, @tweetythierry and @mxbclang for help writing and reviewing this post and for the many contributors who have added to the discussion around this enhancement already.

#core, #feature-projects, #javascript, #performance, #proposal

WordPress packages publish to npm every two weeks

This is a follow-up update to the post from last year: Publishing WordPress packages to npm. It’s worth reminding that we maintain a collection of over 80 npm packages under the WordPress organization.

TLDR; We made WordPress packages publishing to npm more predictable by synchronizing it with bi-weekly GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party RC1 release. We no longer have to keep the process tightly coupled with WordPress major releases.

Revised branching strategy for npm publishing

The Gutenberg repository still follows the WordPress SVN repository’s branching strategy for every major WordPress release. In addition to that, there are two other special branches that control npm publishing workflows and they are used as follows:

  • The wp/latest branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". contains the same version of packages as those published to npm with the latest distribution tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.). The goal here is to have this branch synchronized with the last Gutenberg plugin release, and the only exception would be unplanned Standalone Bugfix Package Releases (read more below).
  • The wp/next branch contains the same version of packages as those published to npm with the next distribution tag. It always gets synchronized with the trunk branch. Projects should use those packages for development or testing purposes only.
  • A Gutenberg branch wp/* (example wp/6.0) targeting a specific WordPress major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. (including its further minor increments) gets created based on the wp/latest Gutenberg branch just after the last Gutenberg release planned for inclusion in the next major WordPress release.

Release types and their schedule:

  • Synchronizing Gutenberg Plugin (latest dist tag) – publishing happens automatically every two weeks based on the newly created release/* (example release/12.8) branch with the RC1 version of the Gutenberg plugin.
  • WordPress Releases (patch dist tag) – publishing gets triggered manually from the wp/* (example wp/6.0) branch. Once we reach the point in the WordPress major release cycle (usually after BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1) where we only cherry-pick commits from the Gutenberg repository to the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., we use wp/* branch (created from wp/latest) for npm publishing with the patch dist-tag. It’s also possible to use older branches to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. bugs or security fixes to the corresponding older versions of WordPress Core.
  • Development Releases (next dist tag) – it is also possible to perform development releases at any time when there is a need to test the upcoming changes.

There is also an option to perform Standalone Bugfix Package Releases at will. It should be reserved only for critical bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes or security releases that must be published to npm outside of regular cycles.

The complete documentation is available in the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor Handbook.

Running npm publishing with GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ workflows

While the npm publishing got configured to happen automatically every two weeks as part of the Gutenberg plugin release workflow, there might still be cases when other release types need to be executed. To start the process, go to Gutenberg’s GitHub repository’s Actions tab, and locate the “Publish npm packages” action. Note the blue banner that says “This workflow has a workflow_dispatch event trigger.”, and expand the “Run workflow” dropdown on its right-hand side.

There are three ways to publish packages to npm depending on the their type:

  • WordPress major release – select wp from the “Release type” dropdown and enter X.Y (example 5.9) in the “WordPress major release” input field.
  • Development release – select development from the “Release type” dropdown and leave “WordPress major release” input field empty.
  • Bugix release – select bugfix from the “Release type” dropdown and leave “WordPress major release” input field empty.

Finally, press the green “Run workflow” button. It triggers the npm publishing job, which needs then to be approved by a Gutenberg Core team member.

Testing JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. code from a specific major WordPress version

An interesting bonus got included with the revised workflow for npm publishing related to WordPress major releases. It’s now possible to quickly install a version of the individual WordPress package used with a given WordPress version using distribution tags (example for WordPress 5.8.x):

npm install @wordpress/block-editor@wp-5.8

It’s also possible to update all WordPress packages in the project with a single command:

npx @wordpress/scripts packages-update --dist-tag=wp-5.8

There is support for switching WordPress packages to versions that fully align with the following major WordPress versions: 5.7, 5.8, 5.9 and 6.0.


Thank you to @annezazu and @priethor for their feedback shared while compiling this post.

#core-js, #javascript, #npm-packages

Proposal: Changes to JavaScript Coding Standards for Full Prettier Compatibility

I propose switching to the original version of the Prettier code formatting tool in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project and updating it to the most recent 2.5 version. Consequently, we should apply the necessary changes to the existing WordPress JavaScript Coding Standards around spacing to respect Prettier’s capabilities.

Code formatting challenges

It’s worth reminding that this topic was discussed several times, beginning in 2017 when the initial exploration of using Prettier started with WordPress/gutenberg#2819. Throughout all that time, the Prettier maintainers didn’t change their mind about adding support for spaces between parens (()) and brackets ([]) despite many requests shared in prettier/prettier#1303 from users (including the WordPress community). That’s why we decided to apply the first batch of JavaScript Coding Standards revisions two years later to use the forked version of Prettier developed by developers at Automattic. It allowed us to remain aligned with the coding style conventions used for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher in the WordPress codebase. In particular, to follow these rules:

Use spaces liberally throughout your code. “When in doubt, space it out.”

The WordPress JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. standards prefer slightly broader whitespace rules than the jQuery style guide. These deviations are for consistency between the PHP and JavaScript files in the WordPress codebase.

The issue is that we ended up with an outdated fork of Prettier in the Gutenberg project that didn’t get any updates for more than a year. The only motivation behind using a custom version of Prettier remains its additional functionality overriding formatting behavior for spaces around parens and brackets. In the meantime, there were three minor releases of Prettier with a long list of new features in the last year:

The Gutenberg project no longer uses only JavaScript for development. Some parts of the codebase use TypeScript, which we agreed upon a few months back. It means we can’t use improvements added for newer versions of the TypeScript language and potentially for future additions to the JavaScript language. A deprecation was also added to one of the config options we use in the shared Prettier config that the community uses. It turns out that it prevents using the @wordpress/prettier-config package with the most recent version of Prettier in 3rd party projects, as explained in WordPress/gutenberg#37516. Finally, we had multiple reports in WordPress/Gutenberg#21872 from the community members using @wordpress/scripts or @wordpress/eslint-plugin packages that the forked version of Prettier doesn’t install correctly in their projects. The good news is that switching to the original Prettier will resolve all of the above!

It quickly became noticeable that the automatic code formatting saves you so much time and energy when trying to keep a consistent coding style in the project. This is why we also started using Prettier to format other types of files it supports in the Gutenberg project, like JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., YAML, Markdown. We also consider doing the same for CSSCSS Cascading Style Sheets. and SCSS next.

RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. to JavaScript Coding Standards

I propose we apply all the necessary changes to the WordPress JavaScript Coding Standards to switch to the latest available version of Prettier (2.5 as of writing). The excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. of the most significant revisions is included below.

-Some whitespace rules differ, for consistency with the WordPress PHP coding standards.
+Some whitespace rules differ, for consistency with the [Prettier](https://prettier.io) formatting tool.
-All new or updated JavaScript code will be reviewed to ensure it conforms to the standards, and passes JSHint.
+All new or updated JavaScript code will be reviewed to ensure it conforms to the standards, and passes [ESLint](https://eslint.org).
-Use spaces liberally throughout your code. “When in doubt, space it out.”
-Any ! negation operator should have a following space.*
+Any ! negation operator should not have a following space.
-Always include extra spaces around elements and arguments:
-array = [ a, b ]; 
-foo( arg );
-foo( 'string', object );
-foo( options, object[ property ] );
-foo( node, 'property', 2 );
-prop = object[ 'default' ];
-firstArrayElement = arr[ 0 ];
+Never include extra spaces around elements and arguments: 
+arg = [a, b]; 
+foo(arg);
+foo('string', object);
+foo(options, object[property]);
+foo(node, 'property', 2);
+prop = object['default'];
+firstArrayElement = arr[0];
-var i;
-
-if ( condition ) {
-   doSomething( 'with a string' );
-} else if ( otherCondition ) {
-    otherThing( {
-        key: value,
-        otherKey: otherValue
-    } );
-} else {
-    somethingElse( true );
-}
- 
-// Unlike jQuery, WordPress prefers a space after the ! negation operator.
-// This is also done to conform to our PHP standards.
-while ( ! condition ) {
-    iterating++;
-}
- 
-for ( i = 0; i < 100; i++ ) {
-    object[ array[ i ] ] = someFn( i );
-    $( '.container' ).val( array[ i ] );
-}
- 
-try {
-    // Expressions
-} catch ( e ) {
-    // Expressions
-}
+var i;
+
+if (condition) {
+	doSomething('with a string');
+} else if (otherCondition) {
+	otherThing({
+		key: value,
+		otherKey: otherValue,
+	});
+} else {
+	somethingElse(true);
+}
+ 
+while (!condition) {
+	iterating++;
+}
+
+for (i = 0; i < 100; i++) {
+	object[array[i]] = someFn(i);
+	$('.container').val(array[i]);
+}
+
+try {
+	// Expressions
+} catch (e) {
+	// Expressions
+}

You can preview the impact on the Gutenberg codebase on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ in the exploratory Pull Request. The same changes would impact the tooling recommended for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. development like @wordpress/create-block and @wordpress/scripts.

When will a decision be made?

Let’s plan for making a decision three five (updated on Jan 25th) weeks from the date of publication of this post. That should give enough time for discussion and questions.

#coding-style, #codingstandards, #javascript

Finalizing the native TypeScript proposal

Hi folks! I’m back again with an update on the TypeScript proposal. Previously in the follow-up post I said that after two weeks we would make a decision about it. It’s been several months since then, so it’s about time to make that decision!

While there was some feedback to the proposal, nothing was raised that seemed to blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. the integration of native TypeScript into the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project. Indeed, some packages (like compose and components) have seen a great deal of native TypeScript introduced. In fact, compose today is fully typed and this would not be the case if it were not for native TypeScript support in Gutenberg.

Therefore, I’d like to officially announce that the Gutenberg project supports native TypeScript. We will continue to follow the guidelines laid out in the follow-up proposal, reproduced here for posterity.

For existing code:

  • The default is to use JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.
  • When it is possible to type something simply with JSDoc, use JSDoc
  • If there are complex types, but JSDoc is still sufficient generally for consuming those types, you may extract the complex types into a types-only types.ts file to be imported into the JSDoc
  • If it is not possible to express the types using JSDoc or if the JSDoc will vastly over-complicate the ability to type a function, convert it to TypeScript

For new code:

Use TypeScript when working in a “low-level package” (as defined below) for new code. Otherwise, follow the same pattern laid out for the existing code.

Low level packages:

A low level package is a package that:

  1. Provides a public APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.; and
  2. Is not frequently contributed to.

The coding guidelines for Gutenberg will be updated to reflect this approach to TypeScript.

#javascript

Changes to Core JavaScript Office Hours

Attendance at the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. Office hours has been low for the last few weeks so at the most recent chat those that were present decided that we’d move to a bi-weekly cadence for now. Here’s a quick summary of what is happening:

  • Core JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. office hours will be bi-weekly at the same time slot (15:00UTC) with the next meeting happening July 27th.
  • Items can still be suggested/added to the open rolling agenda here.
  • Whenever there is something requiring more attention, the suggestion is to schedule a dedicated meeting for interested parties to gather together in the #core-js SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel to have the discussion.

A reminder that the #core-js channel and office hour chats are intended to cover JavaScript across all of WordPress core, all JavaScript infrastructure, tools that build, lint, or test JavaScript code and higher-level discussions about coding styles, libraries used, etc. So has some distinction (even though there can be some overlap) from the kinds of discussions that happen within the #core-editor Slack instance which focuses predominately on the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project and its implementation within WordPress.

#javascript

Follow up to the native TypeScript proposal

The proposal to intentionally integrate native TypeScript into the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository has garnered overwhelmingly positive feedback so far. However there have been some responses that express concerns over introducing a new technology that will be difficult for contributors to understand. This follow up will hopefully address some of those concerns by refining and clarifying some of the ideas in the original proposal.

In this proposal, nothing changes for consumers of Gutenberg packages (like blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. developers). JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. remains the primary way of interacting with the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. If block developers opt-in to use TypeScript for their own projects, we will gradually improve the tools and typings to make their experience better.

Okay, let’s answer the question: when will TypeScript be used in the repository? To answer this question, we must first keep in mind that we do not refactor without a good reason and certainly not for refactoring’s sake alone: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/#code-refactoring

“Code refactoring should not be done just because we can”

Let’s remember why it’s important to introduce TypeScript and strongly typed functions:

  • A better developer experience via automatic code completion (like Intellisense) and other related tools
  • More confidence in our code through better static analysis of function internals and their usages

When to use TypeScript for existing code

So, with that in mind, I’d like to propose @gziolo’s method for approaching when to use TypeScript for existing files:

  • The default is to use JavaScript
  • When it is possible to type something simply with JSDoc, use JSDoc
  • If there are complex types, but JSDoc is still sufficient generally for consuming those types, you may extract the complex types into a types-only types.ts file to be imported into the JSDoc
  • If it is not possible to express the types using JSDoc or if the JSDoc will vastly over-complicate the ability to type a function, convert it to TypeScript

This, of course, only applies to the places that support native TypeScript anyway which is currently limited to mostly lower level packages, which are the primary initial targets for typing. This falls in line with the original proposal’s statement that “the majority of Gutenberg will probably forever remain as plain old JavaScript.”

It does not cover the case for fully new code in existing packages or new code in the form of completely new packages.

When to use TypeScript for new code

Therefore, for the now rare occasion when a fully new package is added, if all the dependencies are typed, I would like to propose that these should be added in native TypeScript. Likewise, packages that are fully typed or are currently being worked on towards full typing (see #18838 for the list of typed and in-progress packages) and fall into the categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of “lower level packages” as described here and in the next section should have new code added in TypeScript.

Otherwise, new code should follow the the same logic laid out above for existing files, essentially only using TypeScript when absolutely necessary, preferring JSDoc typed JavaScript.

Lower level packages

A note about “lower level packages.” We can refine this definition slightly by stating that a low level package is a package that:

  1. Provides a public API; and
  2. Is not frequently contributed to.

Summary

In summary, I’d like to propose the following:

  • When refactoring existing code to add types, follow the script above.
  • For new packages, use native TypeScript when a) all the packages dependencies are typed and b) when they fall into the category of “lower level packages” as defined above.
  • For new code in existing packages, follow the same script above as for refactoring existing code.

If this is accepted by the community then I will open a PR to update the JavaScript coding guidelines in the repository to reflect this. The update will include the script set out above.

When will a decision be made?

I’d like to aim for making a decision 2 weeks from the date of publication of this follow up post. That should give ample time for discussion and questions.

#javascript

Publishing WordPress packages to npm

The WordPress project has started publishing its packages to npm – the largest package repository – over 4 years ago. As of today, there is a collection of nearly 80 actively maintained packages under the WordPress organization.

The latest updates to the process were documented on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ in PR#29028. I wanted to share some details about the latest addition to the process and summarize the overall strategy for publishing.

Development releases

WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. can be closed or in “feature-freeze” mode. Usually, this happens during the WordPress ongoing release cycle (like now with WordPress 5.7), which takes several weeks. It means that packages don’t get any enhancements and new features during the ongoing WordPress major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. process.

Another type of release was introduced to address the limitation mentioned earlier and unblock ongoing development for projects that depend on WordPress packages. It takes advantage of package distribution tags that make it possible to consume the future version of the codebase according to npm guidelines:

By default, the latest tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) is used by npm to identify the current version of a package, and npm install <pkg> (without any @<version> or @<tag> specifier) installs the latest tag. Typically, projects only use the latest tag for stable release versions, and use other tags for unstable versions such as prereleases.

npm documentation

In this case, the next distribution tag is used for publishing the devolvement version of the packages. Developers can install a package in their project by typing:

npm install @wordpress/components@next

The release process is fully automated via a single command:

 ./bin/plugin/cli.js npm-next

The person in charge of the release needs only to run the script, and everything else happens through interactions in the terminal.

Behind the scenes, the wp/next branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". is synchronized with the latest release branch (release/*) created for the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. To avoid collisions in the versioning of packages, we always include the newest commit’s sha, for example, @wordpress/block-editor@5.2.10-next.645224df70.0.

Release types and their schedule

It’s worth clarifying that the Gutenberg plugin consumes the local copy of WordPress packages because they are developed inside the same repository. It’s a completely different story for the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that consumes the packages from the npm registry.

The following list includes the full list of supported release types for publishing WordPress packages to npm:

  • Synchronizing WordPress Trunk (latest dist tag) – when there is no “feature-freeze” mode in WordPress Core, then publishing happens every two weeks based on the new stable version of the Gutenberg plugin. Otherwise, only bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes get manually included and published to npm before every next betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). version of the following WordPress release. There is a script that automates the process: ./bin/commander.js npm-latest.
  • Minor WordPress Releases (patch dist tag) – only when bug fixes or security releases need to be backported into WordPress Core. It’s a manual process that requires cherry-picking individual commits and ends with executing npm run publish:patch command.
  • Development Releases (next dist tag) – at least every two weeks when the RC version for the Gutenberg plugin is released. There is a script that automates the process: ./bin/commander.js npm-next.

There is also an option to perform Standalone Package Releases at will. It should be reserved only for critical bug fixes or security releases that must be published to npm outside of a regular WordPress release cycle. It’s a manual process with many steps required that ends with executing npm run publish:prod command.


We are constantly seeking feedback to improve the processes around npm packages. The workflow for the WordPress core works quite well, and we didn’t discover any major issues when backporting the changes applied to the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor in the Gutenberg plugin. Let us know what else we can do to improve the experience for projects that consume WordPress packages from npm.

#core-js, #javascript, #npm-packages

JavaScript Core Chat Summary: 21 July 2020

This is a recap of the JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat held on Tuesday, July 21, 2020, 14:00 UTC. You can read the full meeting discussion here in Slack.

If you have an item you would like to discuss at the next meeting, please add it to the next agenda document.

@psykro hosted

There were no agenda items for today, so @psykro moved straight to the open floor

Open floor:

  • @itsjonq was having some problems with his laptop crashing when using a Docker local development environment.
    • If anyone has any other suggestions, please let him know.

@psykro closed meeting after 30 minutes.

Next chat is on Tuesday, July 28, 2020, 14:00 UTC in the #core-js channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. If you have anything you would like to discuss, please add it to the agenda document.

Weekly JavaScript news round up

WordPress 5.5 related

A number of dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and posts related to what’s coming in WordPress 5.5 (for the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor and JavaScript were shared this week). I thought it’d be handy to group them all together in this week’s issue of the roundup.

  • The Dashicons library receives it’s final update in WordPress 5.5. If you’re using it in any products, it will still be available in WordPress, however its good switch to using the @wordpress/icons package instead (if suitable).
  • The register theme feature API is landed. This allows custom theme features to be registered and exposed on the theme features support REST endpoint.
  • In WordPress 5.5, images will be lazy loaded by default. Some great work here in preventing layout shifting.
  • An overview of all that is landing in WordPress 5.5 around Block Patterns.
  • New and modified REST API endpoints landing in WP 5.5. Includes notes on: wp/v2/block-types, wp/v2/plugins, wp/v2/block-directory, wp/v2/media/10/edit, block renderer route changes, and majority of theme headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. information is now being returned on the wp/v2/themes endpoint.
  • There are also some REST API Paramater and JSON Schema changes coming. In particular, the work that has gone into improving the options for more defined schema’s is sweet.
  • createInterpolateElement is landed. This is particularly useful for translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. string interpolation in ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. components.

dotOrg news

#javascript, #meeting-notes

JavaScript Core Chat Summary: 14 July 2020

This is a recap of the JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat held on Tuesday, July 14, 2020, 14:00 UTC. You can read the full meeting discussion here in Slack

@adamsilverstein hosted

There were no agenda items for today, so @adamsilverstein moved straight to the open floor

Open floor:

  • @adamsilverstein plans to publish the JavaScript Core team blogblog (versus network, site) post this week
    • You an view this post on ASBlocks here
    • The plan is for this to be “evergreen” and linked from our meeting record and slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. room
  • @mkaz shared in issue he’s been trying to figure out here. Any feedback or suggestions to resolve it are welcome.

@adamsilverstein closed meeting after 25 minutes.

Next chat is on Wednesday, July 21, 2020, 14:00 UTC in the #core-js channel on Slack.

Weekly JavaScript news round up

#javascript, #meeting-notes