Document which packages are compatible with Dependency Extraction Webpack Plugin

[helgatheviking]

Description

I have the dependency extraction webpack plugin enabled in my webpack.config.js

const defaultConfig                     = require( '@wordpress/scripts/config/webpack.config' );
const DependencyExtractionWebpackPlugin = require( '@wordpress/dependency-extraction-webpack-plugin' );
const path                              = require( 'path' );

module.exports = {
	...defaultConfig,
	plugins: [
		...defaultConfig.plugins.filter(
			( plugin ) =>
				plugin.constructor.name !== 'DependencyExtractionWebpackPlugin'
		),
		new DependencyExtractionWebpackPlugin(),
	],
};

But in my block I am attempting to import an icon from @wordpress/icons

import { title as icon } from '@wordpress/icons';

and when I run npm run start I get the following error that icons cannot be resolved.

Module not found: Error: Can't resolve '@wordpress/icons'

Step-by-step reproduction instructions

1. Install the dependency extraction webpack plugin
2. configure it in your webpack
3. try to import an icon from @wordpress/icons somewhere in your scripts

Screenshots, screen recording, code snippet

No response

Environment info

Gutenberg Version 17.8.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.

No

[Mamaduka]

I believe that's an intentional choice. See #19809.

[helgatheviking]

Ok, that's interesting. I would not ever have guessed that.

[Mamaduka]

Based on the conversation in the original PR, I'll close this as "won't fix" for now.

[helgatheviking]

Is there a list of packages we should expect the dependency extraction plugin to work on? If not, could we add that to docu ?

[Mamaduka]

Here's the current list:

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

Lines 3 to 12 in 99b8ea6

	// !!
	// This list must be kept in sync with the same list in tools/webpack/packages.js
	// !!
	const BUNDLED_PACKAGES = [
	'@wordpress/dataviews',
	'@wordpress/icons',
	'@wordpress/interface',
	'@wordpress/sync',
	'@wordpress/undo-manager',
	];

[helgatheviking]

Can that be added to the readme then?

And that can't be the full list? What about data, elements, components, etc?

[Mamaduka]

Oh, sorry. That's the list of the packages that aren't handled by dependency extraction and need to be bundled with your code. The script will handle every other package included in the editor.

Can that be added to the readme then?

Do you want to update the title and description of the issue? Let's re-open it as a documentation update request.

cc @gziolo, @ryanwelcher

[gziolo]

The packages that are bundled are considered private. That's the design decision. For example, after a long period of testing the assumptions made about @wordpress/interfece might get removed completely in the near future, and the functionality moved to other packages.

Let's document the list of supported packages and related WP script handles in the documentation of the package.

[swissspidy]

Correct me if I'm wrong, but regardless of which packages are private or not, if you import a package like @wordpress/icons in your project, it should be installed and listed in your project's package.json. So the error message here is simply indicating that the package is not installed.

Even if a package is properly externalized, having the dependencies installed locally helps with IDE integration (autocomplete, etc.)

[gziolo]

Correct me if I'm wrong, but regardless of which packages are private or not, if you import a package like @wordpress/icons in your project, it should be installed and listed in your project's package.json. So the error message here is simply indicating that the package is not installed.

In case it's externalized, then webpack will ignore the import and replace it with wp.* global, so technically you don't need it for the build.

Even if a package is properly externalized, having the dependencies installed locally helps with IDE integration (autocomplete, etc.)

However, I agree with the reasoning that installing the package locally will vastly improve the development workflow.

[rafaucau]

Correct me if I'm wrong, but regardless of which packages are private or not, if you import a package like @wordpress/icons in your project, it should be installed and listed in your project's package.json. So the error message here is simply indicating that the package is not installed.

I encountered this issue recently. I have the @wordpress/* packages installed as devDependencies to have autocomplete in the IDE. But in the CD I use npm ci --production to speed up deployment.
It would be worth mentioning in the documentation of such packages that they require bundling to avoid such situations.

[swissspidy]

They should probably be installed as regular dependencies then. Icons will then be bundled while the rest won‘t

[rafaucau]

It doesn't make sense to install packages in deployment that are not needed, as it significantly impacts the installation speed. Only the Icons should be installed as a regular dependency.
Therefore, it would be helpful to include in the documentation that Icons require bundling and should not be installed solely for IDE autocomplete purposes, to avoid such issues.