New block created with @wordpress/scripts@28 don't show up on wordpress

[originaliko]

Description

I tried to create a new plugin / block with create-block and the block is not available in the back-end. There's no build error, php error or javascript error.

Step-by-step reproduction instructions

1 : Create a new wordpress plugin "npx @wordpress/create-block test-plugin"
2: cd test-plugin
3 : npm start
3 : activate plugin test-plugin
4 : edit a new page in wp-admin
5 : try to add the new block "/test-plugin"
6: nothing append

step to correct

• edit package.json set devedepencies "@wordpress/scripts" to "^27.9.0"
• npm install
• npm start
• refresh and edit a page
• add the new block "/test-plugin"

Screenshots, screen recording, code snippet

No response

Environment info

Wordpress 6.53.
@wordpress/scripts": "^28.0.0"
node 22.2

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[balazske96]

+1

However if you put the block inside a template html file with it's block name it appears on the front end.

[t-hamano]

Thanks for the report. I was able to reproduce this issue.

I built the block with scripts version 27 and 28 and found a difference in the contents of index.asset.php. react has been replaced with react-jsx-runtime.

version 27.9:

<?php return array('dependencies' => array('react', 'wp-block-editor', 'wp-blocks', 'wp-i18n'), 'version' => 'd97fdb9bbdb79e4913a4');

version 28.0:

<?php return array('dependencies' => array('react-jsx-runtime', 'wp-block-editor', 'wp-blocks', 'wp-i18n'), 'version' => 'b0e4f78143cfbd1f56d2');

If I manually change this to react, the block can be inserted into the editor, but a critical error occurs.

[realthemes]

With v28 scripts all my blocks in my custom block theme stop working, was there any drastic change that I had to take into account when moving from 27 to 28?

[erikyo]

Same here, after updating to v28 custom blocks completely disappeared.

node v20.13.1
npm 10.3.0

reverting to "@wordpress/scripts": "27.8.0" (my last know working version) fixes the issue

--- edit ---
As noticed by @t-hamano, it seems that the JSX development runtime is required but never enqueued in the editor. For that reason, the block will never be registered.

I just noticed that removing those lines:

gutenberg/packages/dependency-extraction-webpack-plugin/lib/util.js

Lines 46 to 48 in ceb8949

	case 'react/jsx-runtime':
	case 'react/jsx-dev-runtime':
	return 'ReactJSXRuntime';

solves the issue. Maybe this is something related to the-new-jsx-transform?

[akawsar711]

same problem here. If i replace pacakage-lock.json with 27.9.0 the block works but with 28.0.0 it disappears.

[mrleemon]

Same problem here. I downgraded to 27.9.0 to make my blocks work again.

[swissspidy]

cc @youknowriad @Mamaduka who worked on / reviewed the original PR.

The way it's currently built is not compatible with WP < 6.6

[gziolo]

The way it's currently built is not compatible with WP < 6.6

The problem is going to exist for quite some time because many plugins target older major versions of WordPress. In WP 6.5 and older there is no react-jsx-runtime so there is no automatic way to declare react as a dependency. I think it’s what happens for folks if they don’t reference React directly.

[youknowriad]

Thanks for creating the issue and sharing your concern. It's clear that we overlooked a bit the impact of this change. Especially for the create-block package.

That said, the solution her is to actually stick to the old version of wp-scripts in the build tooling. Dev Tools and Production dependencies don't need to be updated at the same time. Plugin authors that already have a build tool in place don't need to touch their dependencies.

I think there's a couple of things we should do here:

1- First one is to fix @wordpress/create-block and stick to an old version of @wordpress/scripts in the generated code. At least until the release of WP 6.6 but maybe better until the release of WP 6.7 (Ensure the plugin support at least two WP versions)

2- Write a post on make/core that serves as a dev note quickly to explain the change and the potential impact on build tools.

[justlevine]

@youknowriad might I also suggest updating the CHANGELOG.md file?

[youknowriad]

@justlevine The CHANGELOG already mentions the breaking change. Would you like to seem something else there?

[swissspidy]

Use React's automatic runtime to transform JSX in the changelog doesn't really make it clear what the implications are when it comes to WordPress versions. It could link to the dev note or something.

[justlevine]

@justlevine The CHANGELOG already mentions the breaking change. Would you like to seem something else there?

If the minimum required WP version is changing to 6.6 (as I understood your comment to mean), this should be noted directly. Even if it was included in the PR description, I'd recommend this - more so since it seems to be a side effect that isnt called out explicitly in #61692

[anomiex]

It's not just @wordpress/scripts. Updating @wordpress/dependency-extraction-webpack-plugin to v6 in existing projects breaks too.

I don't know whether updating the other packages but keeping @wordpress/dependency-extraction-webpack-plugin locked to v5 will break anything.

[stefanfisk]

I also had to downgrade @wordpress/dependency-extraction-webpack-plugin because 6.0.0 broke my script deps. I'm using a plain @wordpress/babel-preset-default Babel config so I was quite surprised that the latest versions of these packages are not compatible with the latest version of WordPress.

[gziolo]

The same issue is also being discussed on WordPress Slack (link requires registration at https://make.wordpress.org/chat/): https://wordpress.slack.com/archives/C02QB2JS7/p1717340775169699.

[acicovic]

In the same vein, what should package consumers do regarding @wordpress/babel-preset-default 8.0.0, which has the same Use React's automatic runtime to transform JSX changelog entry?

From some quick testing, it doesn't seem to break anything by itself, at least in our case.

[youknowriad]

I've opened #62265 to add a clearer note to the different impacted packages per the discussion above. Thanks for the suggestions.

[erikyo]

To address this issue, it would be nice to create a postinstall script that checks the current versions of the installed packages.

What is needed is the post install script that parses the package.json and something akin to the engines field in package.json as described in the npm documentation, which specifies the versions of wordpress core and gutenberg that your package is compatible with.

In this case if I had specified in my package.json

wp:{ gutenberg: 17.7, core: 6.5 }

it should have thrown an error and said it is not compatible with my version of wp

What do you think? I think it would be easy to implement and would be extremely beneficial.

[justlevine]

I guess that's not clearly defined.

@youknowriad What currently is defined/documented (and where) regarding JS packages versioning, breaking changes, and forward/back-compatibility?

[youknowriad]

There's some details here https://developer.wordpress.org/block-editor/contributors/code/backward-compatibility/

[gziolo]

JSX in WordPress 6.6 got published with the clarification about the challenges with dev tooling around the upcoming major WP release.

I also closed #62327 as a duplicate as it contains similar reports as above.

[Mamaduka]

Do we need to do the package release to fix issue with npx @wordpress/create-block@latest?

[youknowriad]

@Mamaduka yes, I thought this would happen as part of the beta/RC backports.

[kstcovflw]

I am having the same error; my temporary walkaround to update wordpress to 6.6 Beta.

Here is how:

Follow this to install the plugin.

on wp-admin page, if I install WordPress Beta Tester, then update WordPress version, I can see the plugin.

If i go to edit a page:

[thelovekesh]

Instead of downgrading the packages, add a polyfill for WP versions below 6.6. This will be necessary anyway when upgrading to React 19 and ensuring compatibility with older WP versions.

Add the config to bundle the JSX runtime (webpack example here):

const reactJSXRuntimePolyfill = {
	entry: {
		'react-jsx-runtime': {
			import: 'react/jsx-runtime',
		},
	},
	output: {
		path: path.resolve(__dirname, 'assets/js'),
		filename: 'react-jsx-runtime.js',
		library: {
			name: 'ReactJSXRuntime',
			type: 'window',
		},
	},
	externals: {
		react: 'React',
	},
        // Other config...
};

module.exports = [ reactJSXRuntimePolyfill ];

and later register the script for WP < 6.6 with react as a dependency.

wp_register_script(
	'react-jsx-runtime',
	'path/to/react-jsx-runtime.js',
	[ 'react' ],
	'18.3.0',
	true
);

[youknowriad]

Great suggestion @thelovekesh that's indeed a valid solution as well. Would you mind sharing it as a comment on the dev note here https://make.wordpress.org/core/2024/06/06/jsx-in-wordpress-6-6/

I'm going to close this issue for now. Thanks all.

[thelovekesh]

Thanks @youknowriad. I have added a comment on the devnote - https://make.wordpress.org/core/2024/06/06/jsx-in-wordpress-6-6/#comment-46779.

[TobiasBg]

To add on to @thelovekesh's code suggestion:
I wrapped the wp_register_script() in a wp_script_is() check, to not have to compare WordPress versions:

if ( ! wp_script_is( 'react-jsx-runtime', 'registered' ) ) {
	wp_register_script(
		'react-jsx-runtime',
		'path/to/react-jsx-runtime.js,
		[ 'react' ],
		'18.3.1',
		true
	);
}

I'm now running this in my plugin's action hook handler for the enqueue_block_editor_assets hook (for supporting blocks in the editors) and in my script registration routine for my plugin's admin screens that use React with WordPress components.

[l-schwitzkowski]

@thelovekesh I am sorry, which path is meant here?
path: path.resolve(__dirname, 'assets/js'),

since path and dirname where undefined I put in some hardcoded paths by try&error e.g. to the plugin, to my custom theme etc) but I always end up with "module is not defined" and I am really stuck. can you please explain what to do exactly?
The Block is built with create-block@latest.

[TobiasBg]

@l-schwitzkowski: You should be able to replace that line by

path: `${ __dirname }/assets/js`,

and just the path for the file. ${ __dirname } will be a reference to the main folder (which usually is where your webpack.config.js lives and from which you call your build process).

[l-schwitzkowski]

@TobiasBg Thank you, I really do appreciate any help at this point.
Downgrading didnt help, so I really need to figure that out.
The problem is that I dont have a webpack.config.js.
I have a relatively clean wordpress environment (6.5.4, Node 21.5.0, npm 10.2.5 and React 18.2.0) with not more than one custom theme and that test-plugin. So I have one package.json in root that is just for tailwind for the templates, one in theme and one in the plugin.
The plugin is just a test since many things have changed in Gutenberg, so i just did this cli-command from wp tutorial: npx @wordpress/create-block@latest copyright-date-block --variant=dynamic ( https://developer.wordpress.org/block-editor/getting-started/tutorial/ )
I didnt change anything else, so the only dependency is wp/scripts.
So this is the default build command in my plugin: "build": "wp-scripts build --webpack-copy-php",
I really dont know about that --webpack-copy-php and it leads somewhere to wp-core.

[TobiasBg]

@l-schwitzkowski: Sorry, I don't have experience with using a manual build step like that. I use wp-scripts with a webpack.config.js, where I could then make the code changes from above.

[l-schwitzkowski]

@TobiasBg Thanks anyway :) Using wordpress 6.6 beta (1) solved the issue for now

[TobiasBg]

@l-schwitzkowski: Yes, that will work, but remember that files created that way now will not be able to run with WP < 6.6, without the polyfill.

[l-schwitzkowski]

@TobiasBg That is absolutely fine as its a new side-project. Still we are trying to figure out a solution to make our monolithic main project work within 6.6+ in the future. Until now i didnt have time to check the workarounds within this environment but hopefully there will be a solution until needed.