dependency-extraction-webpack-plugin should warn on improperly imported @wordpress packages

[JEbertPrime]

What problem does this address?

This might be a unique problem to my team, but occasionally in the block development process, a bug slips through like this:

1. Autocompletion incorrectly imports a component like InnerBlocks from the wrong place ("@wordpress/block-editor/build/components" instead of "@wordpress/block-editor")
2. The block builds correctly because the component can be imported from that place, and all the standard linting rules in place find no problems
3. dependency-extraction-webpack-plugin matches the import from an @WordPress package with the wildcard match it uses for all the wordpress packages, but improperly externalizes the dependency (appending the "/build/components" to the handle)
4. the block's editorScript is not enqueued because of (i think, but maybe this isn't how enqueue_script works) missing dependencies

Again, maybe this is a unique problem to my team's setup, and possibly the solution is in the linting step.

What is your proposed solution?

I see one of two solutions:

1. Update the eslint-plugin package with rules that will catch these incorrect imports, or
2. Fix the webpack plugin so that it either warns when an import is incorrect, or just cuts off the extra subdirectories from the dependency handle so that the script makes it past the check for dependencies

[JEbertPrime]

Reproduction here

[gziolo]

Example usage found in the file:
https://github.com/JEbertPrime/wordpress-reproduction-webpack/blob/c94338a5e37f8fd6a02e37d4950f2899a29645a9/copyright-date-block/src/edit.js#L7

What's the reason for importing from @wordpress/block-editor/build/components? It should be @wordpress/block-editor as it exposes all publicly available components that can be correctly externalized and consumed directly from WordPress core.

[JEbertPrime]

There's no practical reason - but it happens because the official plugin for JS autocompletions in VS Code tries to import it from that folder instead of the root of the package, so I'm assuming others have run into the same issue (or will). But I think this should probably just be a linting rule, just so long as there's something in the process that can catch a mistake like this