Omit these files which offer little value since the VIPS library is primarily inlined WASM. Saves ~30MB total from the build output.
Props swissspidy, westonruter, adamsilverstein, berislav.grgicak, knutsp.
Fixes: #64734.
Built from https://develop.svn.wordpress.org/trunk@61794
git-svn-id: http://core.svn.wordpress.org/trunk@61100 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Esprima is no longer maintained, and it does not support the latest JavaScript features in ES11, as Espree does.
- **New Linter Integration:** Introduces `src/js/_enqueues/vendor/codemirror/javascript-lint.js` using `espree` for parsing and error reporting, replacing the dependency on `jshint` and `esprima` scripts.
- **Script Modules:** Registers `espree` as a script module and leverages the `module_dependencies` argument in `wp_register_script()` to ensure `espree` is available as a dynamic import.
- **Editor Settings:** Updates `wp_get_code_editor_settings()` to use ES11 (ECMAScript 2020) defaults and synchronizes JSHint settings from `.jshintrc` for compatibility.
- **Editable Extensions:** Adds `.mjs` to the list of editable file extensions for plugins and themes.
- **Deprecations:** Marks `esprima` and `jshint` script handles as deprecated.
- **Build Tools:** Updates Webpack configuration to bundle `espree` as a module and use the new local `javascript-lint.js`.
Developed in https://github.com/WordPress/wordpress-develop/pull/10806
Follow-up to [61587], [61544], [61539], [42547].
Props westonruter, jonsurrell.
See #64562, #61500, #48456, #42850.
Fixes#64558.
Built from https://develop.svn.wordpress.org/trunk@61611
git-svn-id: http://core.svn.wordpress.org/trunk@60922 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows classic scripts to declare dependencies on script modules by passing `module_dependencies` in the `$args` param for `wp_register_script()` or `wp_enqueue_script()`. The `WP_Script_Modules::get_import_map()` method is updated to traverse the dependency tree of all enqueued classic scripts to find any associated script module dependencies and include them in the `importmap`, enabling dynamic imports of modules within classic scripts.
A `_wp_scripts_add_args_data()` helper function is introduced to consolidate argument validation and processing for `wp_register_script()` and `wp_enqueue_script()`, reducing code duplication. This function validates that the `$args` array only contains recognized keys (`strategy`, `in_footer`, `fetchpriority`, `module_dependencies`) and triggers a `_doing_it_wrong()` notice for any unrecognized keys. Similarly, `WP_Scripts::add_data()` is updated to do early type checking for the data passed to `$args`. The script modules in `module_dependencies` may be referenced by a module ID string or by an array that has an `id` key, following the same pattern as dependencies in `WP_Script_Modules`.
When a script module is added to the `module_dependencies` for a classic script, but it does not exist at the time the `importmap` is printed, a `_doing_it_wrong()` notice is emitted.
Developed in https://github.com/WordPress/wordpress-develop/pull/8024
Follow-up to [61323].
Props sirreal, westonruter.
See #64229.
Fixes#61500.
Built from https://develop.svn.wordpress.org/trunk@61587
git-svn-id: http://core.svn.wordpress.org/trunk@60898 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset improves the Gutenberg build integration to simplify the developer workflow and reinstore a flow similar to how package dependencies worked before the Gutenberg checkout-and-build approach was introduced.
Key improvements:
* Automatic rebuild on ref change: Adds a new `gutenberg:sync` script that stores a hash of the built ref in `.gutenberg-hash` and only rebuilds when the ref changes.
* Full integration on `npm install`: Running `npm install` now produces a fully working development environment with Gutenberg assets in `src/`.
* Clean Gutenberg checkout: Restores Gutenberg's `package.json` after the build completes.
* Stops copying `.js.map` files to `wp-includes/js/dist` since they reference non-existent paths.
* Remove package.json files from the build folder.
* Avoid closures and use prefixed functions.
* Updates build checks to use `jquery.js` instead of `edit-post.js` as the build indicator.
Props youknowriad, ellatrix, mcsf, dmsnell, ntsekouras, jorgefilipecosta, tobiasbg, peterwilsoncc.
Fixes#64393.
Built from https://develop.svn.wordpress.org/trunk@61492
git-svn-id: http://core.svn.wordpress.org/trunk@60803 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes WordPress Core's Gutenberg integration from npm packages to checking out and building Gutenberg directly. Instead of syncing individual npm packages, Core now checks out the Gutenberg repository, builds it, and copies the build artifacts.
This enables Core to use Gutenberg's advanced features like route-based navigation, full-page rendering, and the Font Library, while also streamlining future updates.
New commands:
* `npm run gutenberg:checkout` - Clones Gutenberg at a specified ref
* `npm run gutenberg:build` - Runs Gutenberg's build process
* `npm run gutenberg:copy` - Copies and transforms build output to Core
* `npm run gutenberg:integrate` - Runs all three steps
Main changes:
* Removes webpack configs replaced by Gutenberg's build (blocks.js, packages.js, script-modules.js, development.js, vendors.js)
* Adds Font Library page (`/wp-admin/font-library.php`)
* Adds copy scripts to transform Gutenberg plugin paths to Core paths
* Moves vendor copy step from webpack to Gruntfile
New year, new process. Happy New Year!
Props youknowriad, ellatrix, sirreal, westonruter, desrosj, tellthemachines.
Fixes#64393.
Built from https://develop.svn.wordpress.org/trunk@61438
git-svn-id: http://core.svn.wordpress.org/trunk@60750 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Uses the `wp_script_attributes` filter to add a `data-wp-router-options` directive with a `loadOnClientNavigation: true` property for all the interactive blocks that are compatible with client-side navigation to let the Interactivity API router determine which modules it can safely load during client-side navigation.
Props luisherranz, westonruter.
Fixes#64122.
Built from https://develop.svn.wordpress.org/trunk@61019
git-svn-id: http://core.svn.wordpress.org/trunk@60355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This brings API parity with `WP_Scripts` by implementing opt-in support for printing in the footer via an `in_footer` argument. This argument can be supplied via the `$args` array passed to `wp_enqueue_script_module()` or `wp_register_script_module()`, alongside the existing `fetchpriority` key introduced in #61734. It can also be set for previously-registered script modules via `WP_Script_Modules::set_in_footer()`. This is not applicable to classic themes since modules are enqueued while blocks are rendered after `wp_head` has completed, so all script modules are printed in the footer anyway; the `importmap` script must be printed after all script modules have been enqueued.
Script modules used for interactive blocks (with the Interactivity API) are automatically printed in the footer. Such script modules should be deprioritized because they are not in the critical rendering path due to interactive blocks using server-side rendering. Script modules remain printed at `wp_head` by default, although this default should be revisited since they have deferred execution (and they are printed in the footer for classic themes already, as previously noted). Moving a script module to the footer ensures that its loading does not contend with the loading of critical resources, such as the LCP element's image resource, and LCP is improved as a result.
This also improves specificity of some PHP types, it ensures that script modules can't be registered with an empty ID, and it prevents printing script modules with empty `src` URLs.
Developed in https://github.com/WordPress/wordpress-develop/pull/9867
Follow-up to [60704].
Props b1ink0, westonruter, jonsurrell, peterwilsoncc, vipulpatil, mindctrl.
See #61734.
Fixes#63486.
Built from https://develop.svn.wordpress.org/trunk@60999
git-svn-id: http://core.svn.wordpress.org/trunk@60335 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This introduces a "fetchpriority bumping" mechanism for both classic scripts (`WP_Scripts`) and script modules (`WP_Script_Modules`). When a script with a higher `fetchpriority` is enqueued, any of its dependencies will have their `fetchpriority` elevated to match that of the highest-priority dependent. This ensures that all assets in a critical dependency chain are loaded with the appropriate priority, preventing a high-priority script from being blocked by a low-priority dependency. This is similar to logic used in script loading strategies to ensure that a blocking dependent causes delayed (`async`/`defer`) dependencies to also become blocking. See #12009.
When a script's `fetchpriority` is escalated, its original, registered priority is added to the tag via a `data-wp-fetchpriority` attribute. This matches the addition of the `data-wp-strategy` parameter added when the resulting loading strategy does not match the original.
Developed in https://github.com/WordPress/wordpress-develop/pull/9770.
Follow-up to [60704].
Props westonruter, jonsurrell.
Fixes#61734.
Built from https://develop.svn.wordpress.org/trunk@60931
git-svn-id: http://core.svn.wordpress.org/trunk@60267 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Allow scripts and script modules to be registered with a `fetchpriority` of `auto` (default), `high`, `low`:
* When registering a script, add a `fetchpriority` arg to go alongside the `strategy` arg which was added for loading scripts with the `defer` and `async` loading strategies. See #12009.
* For script modules, introduce an `$args` array parameter with a `fetchpriority` key to the `wp_register_script_module()`, and `wp_enqueue_script_module()` functions (and their respective underlying `WP_Script_Modules::register()` and `WP_Script_Modules::enqueue()` methods). This `$args` parameter corresponds with the same parameter used when registering non-module scripts.
* Also for script modules, introduce `WP_Script_Modules::set_fetchpriority()` to override the `fetchpriority` for what was previously registered.
* Emit a `_doing_it_wrong()` warning when an invalid `fetchpriority` value is used, and when `fetchpriority` is added to a script alias.
* Include `fetchpriority` as an attribute on printed `SCRIPT` tags as well as on preload `LINK` tags for static script module dependencies.
* Use a `fetchpriority` of `low` by default for:
* Script modules used with the Interactivity API. For overriding this default in blocks, see [https://github.com/WordPress/gutenberg/issues/71366 Gutenberg#71366].
* The `comment-reply` script.
* Improve type checks and type hints.
Developed in [https://github.com/WordPress/wordpress-develop/pull/8815 GitHub PR], with [https://github.com/WordPress/gutenberg/pull/70173 companion for Gutenberg].
Props westonruter, jonsurrell, swissspidy, luisherranz, kraftbj, audrasjb, dennysdionigi.
Fixes#61734.
Built from https://develop.svn.wordpress.org/trunk@60704
git-svn-id: http://core.svn.wordpress.org/trunk@60040 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[59083] introduced an issue where Script Modules registered src does not correctly respect the includes path.
Before that change, script modules were registered using includes_url. The patch used a hard-coded path which breaks when sites are not served from the root, e.g. the site root is https://example.com/wp instead of https://example.com/.
Follow-up to [59083].
Props nendeb55, jonsurrell, cbravobernal.
Fixes#62146.
Built from https://develop.svn.wordpress.org/trunk@59154
git-svn-id: http://core.svn.wordpress.org/trunk@58549 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is a companion to https://github.com/WordPress/gutenberg/pull/65460 that requires syncing in WordPress Core. Namely, the block-library changes require registration with their updated script module IDs so that the blocks continue to work correctly.
They key improvement is script modules registration is handled in one central place, and a combined asset file is used to improve the performance by avoiding multiple disk operations for every individual file.
Props jonsurrell, gziolo, wildworks, noisysocks.
See #60647, #59462.
Built from https://develop.svn.wordpress.org/trunk@59083
git-svn-id: http://core.svn.wordpress.org/trunk@58479 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Renames all mentions to "module" with "script module", including function names, comments, and tests.
Follow up to [57269]
The list of functions renamed are:
- `wp_module()` -> `wp_script_module()`.
- `wp_register_module()` -> `wp_register_script_module()`.
- `wp_enqueue_module()` -> `wp_enqueue_script_module()`.
- `wp_dequeue_module()` -> `wp_dequeue_script_module()`.
- `WP_Script_Modules::print_enqueued_modules()` -> `WP_Script_Modules::print_enqueued_script_modules()`.
- `WP_Script_Modules::print_module_preloads()` -> `WP_Script_Modules::print_script_module_preloads()`.
It also adds PHP 7 typing to all the functions and improves the types of the `$deps` argument of `wp_register_script_module()` and `wp_enqueue_script_module()` using `@type`.
Props luisherranz, idad5, costdev, nefff, joemcgill, jorbin, swisspidy, jonsurrel, flixos90, gziolo, westonruter, bernhard-reiter, kamranzafar4343
See #56313
Built from https://develop.svn.wordpress.org/trunk@57327
git-svn-id: http://core.svn.wordpress.org/trunk@56833 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds a new API for WordPress, designed to work with native ES Modules and Import Maps. It introduces functions such as `wp_register_module`, and `wp_enqueue_module`.
The API aims to provide a familiar experience to the existing `WP_Scripts` class, offering similar functionality. However, **it's not intended to duplicate the exact functionality of `WP_Scripts`**; rather, it is carefully tailored to address the specific needs and capabilities of ES modules.
For this initial version, **the current proposal is intentionally simplistic**, covering only the essential features needed to work with ES modules. Other enhancements and optimizations can be added later as the community identifies additional requirements and use cases.
== Differences Between WP_Script_Modules and WP_Scripts
=== Dependency Specification
With `WP_Script_Modules`, the array of dependencies supports not only strings but also arrays that include the dependency import type (`static` or `dynamic`). This design choice allows for future extensions of dependency properties, such as adding a `version` property to support "scopes" within import maps.
=== Module Identifier
Instead of a handle, `WP_Script_Modules` utilizes the module identifier, aligning with the module identifiers used in JavaScript files and import maps.
=== Deregistration
There is no equivalent of `wp_deregister_script` at this stage.
== API
=== `wp_register_module( $module_identifier, $src, $deps, $version )`
Registers a module.
{{{
// Registers a module with dependencies and versioning.
wp_register_module(
'my-module',
'/path/to/my-module.js',
array( 'static-dependency-1', 'static-dependency-2' ),
'1.2.3'
);
}}}
{{{
// my-module.js
import { ... } from 'static-dependency-1';
import { ... } from 'static-dependency-2';
// ...
}}}
{{{
// Registers a module with a dynamic dependency.
wp_register_module(
'my-module',
'/path/to/my-module.js',
array(
'static-dependency',
array(
'id' => 'dynamic-dependency',
'import' => 'dynamic'
),
)
);
}}}
{{{
// my-module.js
import { ... } from 'static-dependency';
// ...
const dynamicModule = await import('dynamic-dependency');
}}}
=== `wp_enqueue_module( $module_identifier, $src, $deps, $version )`
Enqueues a module. If a source is provided, it will also register the module.
{{{
wp_enqueue_module( 'my-module' );
}}}
=== `wp_dequeue_module( $module_identifier )`
Dequeues a module.
{{{
wp_dequeue_module( 'my-module' );
}}}
== Output
- When modules are enqueued, they are printed within script tags containing `type="module"` attributes.
- Additionally, static dependencies of enqueued modules utilize `link` tags with `rel="modulepreload"` attributes.
- Lastly, an import map is generated and inserted using a `<script type="importmap">` tag.
{{{
<script type="module" src="/path/to/my-module.js" id="my-module"></script>
<link rel="modulepreload" href="/path/to/static-dependency.js" id="static-dependency" />
<script type="importmap">
{
"imports": {
"static-dependency": "/path/to/static-dependency.js",
"dynamic-dependency": "/path/to/dynamic-dependency.js"
}
}
</script>
}}}
== Import Map Polyfill Requirement
Even though all major browsers already support import maps, an import map polyfill is required until the percentage of users using old browser versions without import map support drops significantly.
This work is ongoing and will be added once it's ready. Progress is tracked in #60232.
Props luisherranz, idad5, costdev, neffff, joemcgill, jorbin, swissspidy, jonsurrell, flixos90, gziolo, westonruter.
Fixes#56313.
Built from https://develop.svn.wordpress.org/trunk@57269
git-svn-id: http://core.svn.wordpress.org/trunk@56775 1a063a9b-81f0-0310-95a4-ce76da25c4cd
