Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Tooling: Generate asset file in PHP format with the list dependencies #17298

Merged
merged 13 commits into from Sep 16, 2019

Conversation

@gziolo
Copy link
Member

commented Sep 2, 2019

Description

This is still work in progress but I'm looking for early feedback.

I'm seeking a way to make assets registration much easier and more automated when you use wp-scripts build. At the moment we have:

wp_register_script( string $handle, string|bool $src, array $deps = array(), string|bool|null $ver = false, bool $in_footer = false )

https://developer.wordpress.org/reference/functions/wp_register_script/

and

wp_register_style( string $handle, string|bool $src, array $deps = array(), string|bool|null $ver = false, string $media = 'all' )

https://developer.wordpress.org/reference/functions/wp_register_style/

They both are very similar and we could further simplify them in some way with a wrapper or by changing its internal implementation:

wp_register_asset( 'my/path/to/script.js' );

where WordPress would load the file with .asset.php (or .asset.json) extension and handle all params based on what Webpack generates.

The goal is to make npm run build to generate a PHP file [file].asset.php by default with the object defined as a return statement as described in https://github.com/WordPress/gutenberg/blob/master/docs/rfc/block-registration.md#wordpress-context (handle, dependencies and version).

I have dependencies and version covered. JSON is still the default format but this seems like we could offer plain PHP file which can be loaded and cached without any internal processing.

JSON example:

{ "dependencies": [ "a", "b" ], "version": "abc" };

PHP potential example:

<?php
return array( "dependencies" => array( "a", "b" ), "version" => "abc"  );

Open questions

  1. What is the best way to format PHP asset file and how core and plugins should consume it?
  2. Should we support JSON format only and assume that json_decode is fast enough?
  3. How to auto-generate handles for scripts to prefix them with the plugin name of wp- for core?

How has this been tested?

  • npm test
  • npm run dev
  • npm run build

Types of changes

Breaking change for:

  • @wordpress/dependency-extraction-webpack-plugin
  • @wordpress/scripts

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.

@gziolo gziolo requested a review from sirreal Sep 2, 2019

@gziolo gziolo requested a review from TimothyBJacobs as a code owner Sep 2, 2019

@gziolo gziolo self-assigned this Sep 2, 2019

@gziolo gziolo requested review from mcsf, pento, ntwb, WordPress/gutenberg-core and nerrad Sep 2, 2019

@nerrad

This comment has been minimized.

Copy link
Contributor

commented Sep 2, 2019

It's unclear to me what the purpose is behind doing this. Is it for performance reasons so that php runtime doesn't have to decode json from the original *.deps.json file? If so, it'd probably be good to do some performance metrics to give rationale for why we'd want to do this?

@TimothyBJacobs

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

I don't think this would improve performance since it is using unserialize. It'd be better to generate the file as actual PHP code. Then we'd get the benefits from not having to separately read and json_decode/unserialize and it'd be cached by opcache.

I ended up doing exactly this by making a simple PHP script to dump JSON input as PHP.

<?php

if ( 'cli' !== php_sapi_name() ) {
	die( 1 );
}

if ( ! isset( $argv[1] ) ) {
	die( 1 );
}

$json = $argv[1];

if ( ! $decoded = json_decode( $json, true ) ) {
	die( 1 );
}

ksort( $decoded );

fwrite( STDOUT, var_export( $decoded, true ) );
die( 0 );
@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 2, 2019

It's unclear to me what the purpose is behind doing this. Is it for performance reasons so that php runtime doesn't have to decode json from the original *.deps.json file? If so, it'd probably be good to do some performance metrics to give rationale for why we'd want to do this?

I'm seeking a way to make assets registration much easier and more automated when you use wp-scripts build. At the moment we have:

wp_register_script( string $handle, string|bool $src, array $deps = array(), string|bool|null $ver = false, bool $in_footer = false )

https://developer.wordpress.org/reference/functions/wp_register_script/

and

wp_register_style( string $handle, string|bool $src, array $deps = array(), string|bool|null $ver = false, string $media = 'all' )

https://developer.wordpress.org/reference/functions/wp_register_style/

They both are very similar and we could further simplify them in some way with a wrapper or by changing its internal implementation:

wp_register_asset( 'my/path/to/script.js' );

where WordPress would load the file with .asset.php (or .asset.json) extension and handle all params based on what Webpack generates.

There are a couple of considerations here:

  • the list of dependencies is not enough here
  • I added version already
  • it would be great to have a way to generate the handle of the asset
  • depending on implementation we can also include the type of asset - script or style

I'm fine with doing some benchmarks to find the best possible format which core and plugins would consume. @sirreal, did you verify it when integrating with Jetpack. I think we discussed that PHP format would work better here. We could try also to find a way to generate a PHP file which returns an array but there is this challenge how to make it secure.

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 2, 2019

I don't think this would improve performance since it is using unserialize. It'd be better to generate the file as actual PHP code. Then we'd get the benefits from not having to separately read and json_decode/unserialize and it'd be cached by opcache.

Yes, that would be the best possible solution. Do you know how to do the same trick using Node.js? :D

@nerrad
Copy link
Contributor

left a comment

Ahh that explanation makes things much clearer 👍.

On the wp core side of things, we'd probably want an api like this:

function wp_register_asset( $asset_path, $handle = '', $dependencies = [], $asset_config_path = '' ) {
  /**
   * If `$asset_config_path` is empty, then try deriving the `*.asset.php` configuration file from the `$asset_path` value.
   * If `$handle` is empty, then generate from `$asset_path`.
   * `$dependencies` would still be needed in case there are additional dependencies that don't get picked up via build process.
   **/
}
.digest( 'hex' ),
} )
.replace( /\.js$/i, '.deps.json' );
.replace( /\.js$/i, '.asset.' + outputFormat );

This comment has been minimized.

Copy link
@nerrad

nerrad Sep 2, 2019

Contributor

This will be a breaking change for any code relying on deps.json currently right?

This comment has been minimized.

Copy link
@gziolo

gziolo Sep 2, 2019

Author Member

Yes, totally. We could make it backward compatible with some flag but I think for CLI tools it's fine to introduce breaking changes.

@TimothyBJacobs

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

Yes, that would be the best possible solution. Do you know how to do the same trick using Node.js? :D

What did was call the PHP executable from node.

function serialize( data ) {
	const out = spawn( 'php', [
		path.resolve( __dirname, 'json-to-php.php' ),
		JSON.stringify( data ),
	] );

	if ( out.status !== 0 ) {
		throw Error( 'Failed to generate PHP manifest.' );
	}

	return `<?php return ${ out.stdout };`;
}

I found a library at one point for generating the PHP in nodejs, but I wasn't very confident in it. And I'm now of course completely failing to find the name of it.

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 2, 2019

What did was call the PHP executable from node.

You would need to have PHP installed to make it work. Ideally, it's all Node-based.

@nerrad

This comment has been minimized.

Copy link
Contributor

commented Sep 2, 2019

Might need to generate the php similar to how the pot-to-php.js script does things

@TimothyBJacobs

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

@sirreal

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

I'm fine with doing some benchmarks to find the best possible format which core and plugins would consume. @sirreal, did you verify it when integrating with Jetpack. I think we discussed that PHP format would work better here.

I recall discussing PHP as the output format and speculation that it might have better performance, but I haven't done any benchmarking and don't expect to in the near future. Jetpack is using the JSON serialized output.

There was some related conversation here: #15124 (comment)

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2019

@aristath shared this nice npm package https://www.npmjs.com/package/json2php on WordPress Slack:
https://wordpress.slack.com/archives/C02RQBWTW/p1567435208465800

I used it in d0a983f.

This was the library, https://github.com/aliaksandr-master/grunt-json2php

@TimothyBJacobs - this library is nearly identical but it has more cases in the switch statement :)They use this trick in this grunt lib where they serialize to JSON and parse back to JS object which I applied as well to increase the likeliness that it would work properly with some code added through the Webpack plugin advanced options.

Example output:

edit-post in Gutenberg

<?php return array('dependencies' => array('lodash', 'wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-editor', 'wp-element', 'wp-hooks', 'wp-i18n', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-nux', 'wp-plugins', 'wp-polyfill', 'wp-url', 'wp-viewport'), 'version' => '8ccda406e48392e355b4551433d635a1');
@sirreal
Copy link
Member

left a comment

This is nice to see, I left some thoughts.

Are you planning to add a handle to the asset file as well?

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2019

Are you planning to add a handle to the asset file as well?

Yes, it would be great to have it automated for all parties involved: Gutenberg, core, and plugins.

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2019

@swissspidy - do you think it would make sense to put a flag in this asset file which indicates whether this file contains translation? At the moment in WordPress core, we have a hardcoded list of scripts which contain translations:

https://github.com/WordPress/wordpress-develop/blob/00b03f2a6f2c21ebf9975c9c08976358681400ba/src/wp-includes/script-loader.php#L496-L508

It would be great to be able to automate it as well :)

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 4, 2019

Are you planning to add a handle to the asset file as well?

Yes, it would be great to have it automated for all parties involved: Gutenberg, core, and plugins.

I did some initial coding and I think this PR is big enough. Let's tackle it separately. I will update documentation, add CHANGELOG entries and we can land code changes in the current shape. I want to make sure it's included in the next npm release so we can simplify packages handling in WordPress core. At the moment the biggest struggle is the necessity to keep versions and lists of dependencies for each package up to date in PHP files.

@gziolo gziolo force-pushed the update/webpack-asset-php branch from 237464e to 4a1843f Sep 4, 2019

@gziolo gziolo requested a review from ajitbohra as a code owner Sep 4, 2019

@senadir

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

will this affect other plugins and libraries or is it only scoped to Gutenberg core & dependency extraction plugin?

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 14, 2019

will this affect other plugins and libraries or is it only scoped to Gutenberg core & dependency extraction plugin?

It's going to be handy for all parts involved: Gutenberg, core, and plugins.

@mcsf
Copy link
Contributor

left a comment

This looks cool! I don't know if you'd rather postpone this or wait for someone else's input. I almost pressed the Approve button. :)

What is the best way to format PHP asset file and how core and plugins should consume it?

The current one, if we keep PHP as a format, seems apt. Do you see any risks?

Should we support JSON format only and assume that json_decode is fast enough?

That is a great question. It would be interesting to have someone stress-test this, or see if there's any optimisations that could be done based on filesystem information on the assets.

lib/client-assets.php Show resolved Hide resolved
@senadir

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2019

That is a great question. It would be interesting to have someone stress-test this, or see if there's any optimisations that could be done based on filesystem information on the assets.

Straight out reading is always better than reading and then parsing, but then again, I'm afraid we're going to lose a huge portability (JSON files) if we go the PHP way for what might be a premature optimization, the file will never have more than a handful of depencepcaties so I'm not sure here.

However, the code seems right to me and is ready to merge? do you think it's good thing to produce here?

cc @nerrad @TimothyBJacobs

@nerrad
nerrad approved these changes Sep 16, 2019
Copy link
Contributor

left a comment

Let's merge this:

  • There's still the option to export as json for those that want that format.
  • We gain version hash generation here 🎉which is great!

Summarizing what can be iterated on in future pulls:

  • flagging what assets have translations (likely can be done by detecting @wordpress/i18n as a dependency)
  • generating/returning the handle to use for registering the asset (essentially that is already the case for the dependency arrays)
  • potentially introducing a new asset php api for registering assets using these generated files (wp_register_asset?).

Great work @gziolo!

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 16, 2019

Straight out reading is always better than reading and then parsing, but then again, I'm afraid we're going to lose a huge portability (JSON files) if we go the PHP way for what might be a premature optimization, the file will never have more than a handful of depencepcaties so I'm not sure here.

We still offer 2 formats for folks to pick from. Can you think of any use case outside of WordPress where that script handles might be useful in any way? I decided to optimize for the most common use case which is WordPress env.

The current one, if we keep PHP as a format, seems apt. Do you see any risks?

I can't think of any.

That is a great question. It would be interesting to have someone stress-test this, or see if there's any optimisations that could be done based on filesystem information on the assets.

I guess it's something you can take for granted given that including PHP file is going to be always faster than reading a file and parsing its content. I can run some tests later just for the sake of confirming my thinking :)

Summarizing what can be iterated on in future pulls:

  • flagging what assets have translations (likely can be done by detecting @wordpress/i18n as a dependency)
  • generating/returning the handle to use for registering the asset (essentially that is already the case for the dependency arrays)
  • potentially introducing a new asset php api for registering assets using these generated files (wp_register_asset?).

Exactly, all of that will make it even better, but what we have at the moment is essential to make ie less painful to navigate through beta and RC releases of WordPress. I'll open a follow up based on your great summary.

@gziolo gziolo force-pushed the update/webpack-asset-php branch from ad87d77 to a0dd11b Sep 16, 2019

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 16, 2019

This is my script I embedded in Gutenberg to test it:

		$asset_file   = substr( $path, 0, -3 ) . '.asset.json';
		$time_json = microtime( true );
		for ($i = 0; $i < 100; $i++) {
			$asset = file_exists( $asset_file )
				? json_decode( file_get_contents( $asset_file ) )
				: null;
		}
		$execution_time = microtime( true ) - $time_json;
		print $asset_file . ': ' . $execution_time . '<br />';

		$asset_file   = substr( $path, 0, -3 ) . '.asset.php';
		$time_php = microtime( true );
		for ($i = 0; $i < 100; $i++) {
			$asset = file_exists( $asset_file )
				? require( $asset_file )
				: null;
		}
		$execution_time = microtime( true ) - $time_php;

Here are results:

/var/www/src/wp-content/plugins/gutenberg/build/a11y/index.asset.json: 0.20905303955078
/var/www/src/wp-content/plugins/gutenberg/build/a11y/index.asset.php: 0.021572113037109
/var/www/src/wp-content/plugins/gutenberg/build/annotations/index.asset.json: 0.20719003677368
/var/www/src/wp-content/plugins/gutenberg/build/annotations/index.asset.php: 0.021773099899292
/var/www/src/wp-content/plugins/gutenberg/build/api-fetch/index.asset.json: 0.20702815055847
/var/www/src/wp-content/plugins/gutenberg/build/api-fetch/index.asset.php: 0.021097898483276
/var/www/src/wp-content/plugins/gutenberg/build/autop/index.asset.json: 0.19571208953857
/var/www/src/wp-content/plugins/gutenberg/build/autop/index.asset.php: 0.021183967590332
/var/www/src/wp-content/plugins/gutenberg/build/blob/index.asset.json: 0.21241402626038
/var/www/src/wp-content/plugins/gutenberg/build/blob/index.asset.php: 0.021059989929199
/var/www/src/wp-content/plugins/gutenberg/build/block-directory/index.asset.json: 0.21259689331055
/var/www/src/wp-content/plugins/gutenberg/build/block-directory/index.asset.php: 0.021985054016113
/var/www/src/wp-content/plugins/gutenberg/build/block-editor/index.asset.json: 0.2052218914032
/var/www/src/wp-content/plugins/gutenberg/build/block-editor/index.asset.php: 0.02251410484314
/var/www/src/wp-content/plugins/gutenberg/build/block-library/index.asset.json: 0.20576000213623
/var/www/src/wp-content/plugins/gutenberg/build/block-library/index.asset.php: 0.023792028427124
/var/www/src/wp-content/plugins/gutenberg/build/block-serialization-default-parser/index.asset.json: 0.21394395828247
/var/www/src/wp-content/plugins/gutenberg/build/block-serialization-default-parser/index.asset.php: 0.022719860076904
/var/www/src/wp-content/plugins/gutenberg/build/block-serialization-spec-parser/index.asset.json: 0.21512913703918
/var/www/src/wp-content/plugins/gutenberg/build/block-serialization-spec-parser/index.asset.php: 0.021649122238159
/var/www/src/wp-content/plugins/gutenberg/build/blocks/index.asset.json: 0.21497106552124
/var/www/src/wp-content/plugins/gutenberg/build/blocks/index.asset.php: 0.023571014404297
/var/www/src/wp-content/plugins/gutenberg/build/components/index.asset.json: 0.21689105033875
/var/www/src/wp-content/plugins/gutenberg/build/components/index.asset.php: 0.022634983062744
/var/www/src/wp-content/plugins/gutenberg/build/compose/index.asset.json: 0.22077703475952
/var/www/src/wp-content/plugins/gutenberg/build/compose/index.asset.php: 0.022778034210205
/var/www/src/wp-content/plugins/gutenberg/build/core-data/index.asset.json: 0.19814896583557
/var/www/src/wp-content/plugins/gutenberg/build/core-data/index.asset.php: 0.020949840545654
/var/www/src/wp-content/plugins/gutenberg/build/data-controls/index.asset.json: 0.21083498001099
/var/www/src/wp-content/plugins/gutenberg/build/data-controls/index.asset.php: 0.022100210189819
/var/www/src/wp-content/plugins/gutenberg/build/data/index.asset.json: 0.21387696266174
/var/www/src/wp-content/plugins/gutenberg/build/data/index.asset.php: 0.02294397354126
/var/www/src/wp-content/plugins/gutenberg/build/date/index.asset.json: 0.22469711303711
/var/www/src/wp-content/plugins/gutenberg/build/date/index.asset.php: 0.022562026977539
/var/www/src/wp-content/plugins/gutenberg/build/deprecated/index.asset.json: 0.21234202384949
/var/www/src/wp-content/plugins/gutenberg/build/deprecated/index.asset.php: 0.022023916244507
/var/www/src/wp-content/plugins/gutenberg/build/dom-ready/index.asset.json: 0.21053194999695
/var/www/src/wp-content/plugins/gutenberg/build/dom-ready/index.asset.php: 0.021248817443848
/var/www/src/wp-content/plugins/gutenberg/build/dom/index.asset.json: 0.21238899230957
/var/www/src/wp-content/plugins/gutenberg/build/dom/index.asset.php: 0.02059006690979
/var/www/src/wp-content/plugins/gutenberg/build/edit-post/index.asset.json: 0.21182203292847
/var/www/src/wp-content/plugins/gutenberg/build/edit-post/index.asset.php: 0.022536039352417
/var/www/src/wp-content/plugins/gutenberg/build/edit-widgets/index.asset.json: 0.23678803443909
/var/www/src/wp-content/plugins/gutenberg/build/edit-widgets/index.asset.php: 0.028978824615479
/var/www/src/wp-content/plugins/gutenberg/build/editor/index.asset.json: 0.24442601203918
/var/www/src/wp-content/plugins/gutenberg/build/editor/index.asset.php: 0.025237083435059
/var/www/src/wp-content/plugins/gutenberg/build/element/index.asset.json: 0.23711705207825
/var/www/src/wp-content/plugins/gutenberg/build/element/index.asset.php: 0.027673959732056
/var/www/src/wp-content/plugins/gutenberg/build/escape-html/index.asset.json: 0.24959492683411
/var/www/src/wp-content/plugins/gutenberg/build/escape-html/index.asset.php: 0.02747917175293
/var/www/src/wp-content/plugins/gutenberg/build/format-library/index.asset.json: 0.24972105026245
/var/www/src/wp-content/plugins/gutenberg/build/format-library/index.asset.php: 0.026243925094604
/var/www/src/wp-content/plugins/gutenberg/build/hooks/index.asset.json: 0.2450270652771
/var/www/src/wp-content/plugins/gutenberg/build/hooks/index.asset.php: 0.026225805282593
/var/www/src/wp-content/plugins/gutenberg/build/html-entities/index.asset.json: 0.24460220336914
/var/www/src/wp-content/plugins/gutenberg/build/html-entities/index.asset.php: 0.025669097900391
/var/www/src/wp-content/plugins/gutenberg/build/i18n/index.asset.json: 0.25499582290649
/var/www/src/wp-content/plugins/gutenberg/build/i18n/index.asset.php: 0.027352094650269
/var/www/src/wp-content/plugins/gutenberg/build/is-shallow-equal/index.asset.json: 0.25012183189392
/var/www/src/wp-content/plugins/gutenberg/build/is-shallow-equal/index.asset.php: 0.026401996612549
/var/www/src/wp-content/plugins/gutenberg/build/keycodes/index.asset.json: 0.24977898597717
/var/www/src/wp-content/plugins/gutenberg/build/keycodes/index.asset.php: 0.026311874389648
/var/www/src/wp-content/plugins/gutenberg/build/list-reusable-blocks/index.asset.json: 0.25093507766724
/var/www/src/wp-content/plugins/gutenberg/build/list-reusable-blocks/index.asset.php: 0.02651309967041
/var/www/src/wp-content/plugins/gutenberg/build/media-utils/index.asset.json: 0.24833512306213
/var/www/src/wp-content/plugins/gutenberg/build/media-utils/index.asset.php: 0.025299072265625
/var/www/src/wp-content/plugins/gutenberg/build/notices/index.asset.json: 0.2518470287323
/var/www/src/wp-content/plugins/gutenberg/build/notices/index.asset.php: 0.027045011520386
/var/www/src/wp-content/plugins/gutenberg/build/nux/index.asset.json: 0.24950695037842
/var/www/src/wp-content/plugins/gutenberg/build/nux/index.asset.php: 0.029812812805176
/var/www/src/wp-content/plugins/gutenberg/build/plugins/index.asset.json: 0.25040698051453
/var/www/src/wp-content/plugins/gutenberg/build/plugins/index.asset.php: 0.026450157165527
/var/www/src/wp-content/plugins/gutenberg/build/priority-queue/index.asset.json: 0.25751614570618
/var/www/src/wp-content/plugins/gutenberg/build/priority-queue/index.asset.php: 0.025552988052368
/var/www/src/wp-content/plugins/gutenberg/build/redux-routine/index.asset.json: 0.25923609733582
/var/www/src/wp-content/plugins/gutenberg/build/redux-routine/index.asset.php: 0.026318073272705
/var/www/src/wp-content/plugins/gutenberg/build/rich-text/index.asset.json: 0.25325202941895
/var/www/src/wp-content/plugins/gutenberg/build/rich-text/index.asset.php: 0.027011156082153
/var/www/src/wp-content/plugins/gutenberg/build/server-side-render/index.asset.json: 0.24976086616516
/var/www/src/wp-content/plugins/gutenberg/build/server-side-render/index.asset.php: 0.025624990463257
/var/www/src/wp-content/plugins/gutenberg/build/shortcode/index.asset.json: 0.24687385559082
/var/www/src/wp-content/plugins/gutenberg/build/shortcode/index.asset.php: 0.025692939758301
/var/www/src/wp-content/plugins/gutenberg/build/token-list/index.asset.json: 0.24648094177246
/var/www/src/wp-content/plugins/gutenberg/build/token-list/index.asset.php: 0.025548934936523
/var/www/src/wp-content/plugins/gutenberg/build/url/index.asset.json: 0.24396300315857
/var/www/src/wp-content/plugins/gutenberg/build/url/index.asset.php: 0.025406122207642
/var/www/src/wp-content/plugins/gutenberg/build/viewport/index.asset.json: 0.24664902687073
/var/www/src/wp-content/plugins/gutenberg/build/viewport/index.asset.php: 0.025645971298218
/var/www/src/wp-content/plugins/gutenberg/build/wordcount/index.asset.json: 0.24460196495056
/var/www/src/wp-content/plugins/gutenberg/build/wordcount/index.asset.php: 0.026274919509888

I didn't do in depth analysis as it's evident that PHP version is on average 10 times faster!

@gziolo gziolo merged commit c43c0ac into master Sep 16, 2019

4 of 7 checks passed

pull-request-automation
Details
Header rules - gutenberg-playground No header rules processed
Details
Pages changed - gutenberg-playground All files already uploaded
Details
Redirect rules - gutenberg-playground No redirect rules processed
Details
Mixed content - gutenberg-playground No mixed content detected
Details
Travis CI - Pull Request Build Passed
Details
netlify/gutenberg-playground/deploy-preview Deploy preview ready!
Details

@gziolo gziolo deleted the update/webpack-asset-php branch Sep 16, 2019

@gziolo gziolo added this to the Gutenberg 6.5 milestone Sep 16, 2019

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 16, 2019

Thank you all for all valuable feedback, commits, suggestions and making it happen :)

Let's iterate further as noted in #17454.

@swissspidy

This comment has been minimized.

Copy link
Member

commented Sep 17, 2019

@gziolo Is my assumption correct that this is not in v5 of the scripts package? The changelog says so.

@gziolo

This comment has been minimized.

Copy link
Member Author

commented Sep 17, 2019

I forgot to update CHANGELOG files yesterday. I'll try to do it today :)

It's referencing @wordpress/dependency-extraction-webpack-plugin v2.0.0 in:
https://unpkg.com/browse/@wordpress/scripts@5.0.0/package.json

I can see changes from this PR published in:
https://unpkg.com/browse/@wordpress/dependency-extraction-webpack-plugin@2.0.0/index.js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.