Import names aren't validated before writing dependency file

[iandunn]

Describe the bug

dependency-extraction-webpack-plugin doesn't validate import names. If an invalid name is used, the parent script will silently fail to load, which can be confusing and time-consuming to fix.

Expected behavior

The watch script should throw an error to the console, to alert the dev that they used an invalid dependency.

To reproduce

1. Enqueue a script that depends on a deps.json file. e.g.,

wp_enqueue_script(
	'foo',
	plugins_url( 'dist/foo.js', __FILE__ ),
	json_decode( file_get_contents( __DIR__ . '/dist/foo.deps.json' ) ),
);

2. Make a type in an import statement. e.g.,

import { Button } from '@wordpress/component'; // missing an `s` at the end

2. Load the page where the script should be enqueue, notice that it's no longer there.

[gziolo]

It seems like this should be handled on the linter side instead. Well, at least this is what we introduced in Gutenberg lately with “import/no-extraneous-dependencies” rule in #16969. It’s handled per package and only for non-test files in Gutenberg but it might be a good idea to set it in recommended config of ESLint and override in the project as Gutenberg is a special case here. @nerrad, @ntwb, and @swissspidy what do you think?

[nerrad]

Ya I agree, linter. A couple IDE's I've used will also warn on invalid imports.

[gziolo]

My attempt to enable ESLint rule in #20905 didn’t work as expected 🙁

It looks like the bug was fixed and it has landed in Gutenberg. Next step is to move it to the ESLing plugin.

[ocean90]

@gziolo Was it expected that we now have to add every @WordPress package used in block scripts as a dev dependency? Asking because the rule now produces these errors:

/wordpress-plugin-boilerplate/assets/js/src/blocks.js
  4:35  error  Unable to resolve path to module '@wordpress/blocks'  import/no-unresolved

/wordpress-plugin-boilerplate/assets/js/src/blocks/example/index.js
  4:20  error  Unable to resolve path to module '@wordpress/i18n'  import/no-unresolved

[gziolo]

Yes. It might be too strict though. We can exclude those dependencies that are listed as webpack externals and resolved as globals in WordPress. I had a similar discussion on WordPress Slack. What do you think about it? I didn't anticipate it being problematic.

By the way, @wordpress/create-block installs all dependencies used in the code. It should follow whatever we decide next.

[ocean90]

Not sure, I think they should be excluded but I also see the benefit of having them explicitly defined as a dependency. One issue I see is the versioning because they version installed might not match the version included in the minimum supported WordPress version. With automated package updates (Dependabot) it's too easy to install a new version.
Might also be not be so nice to install all the dependencies which aren't actually used just to make a rule happy while it's technically a false-positive.

Could you link to the Slack discussion please?

[nerrad]

Here's a link to the discussion that happened in Slack: https://wordpress.slack.com/archives/C5UNMSU4R/p1612354700163900