Conversation
webpack.config.js
Outdated
| resolver.plugin( 'module', ( request, callback ) => { | ||
| // Find entry root which contains the requesting path | ||
| const resolvePath = entryRoots.find( ( entryRoot ) => { | ||
| return request.path.startsWith( entryRoot ); |
There was a problem hiding this comment.
If I'm understanding this correctly, it would break if you had two directories named like prefix and prefix-and-more-stuff - there should be a test for a path separator somewhere.
|
I'm surprised that something like this doesn't exist yet. It seems like it would be pretty useful as a standalone plugin. As a step in that direction, I think it would be good to pull the class out into a separate file in this PR. This also seems complicated enough that it would benefit from some test cases (for example, for the case I described in #386 (comment)). Have you given much thought to how difficult that would be to achieve (probably easier if it's packaged as a standalone library)? I found this article on the subject: https://blog.iansinnott.com/testing-webpack-plugins/ |
|
@nylen Thanks for the feedback. I think I'm going to pull this out as a separate module and give a go at incorporating at least some basic testing. |
|
Extracted the Webpack plugin to an external module and updated the branch accordingly. https://github.com/aduth/resolve-entry-modules-webpack-plugin |
Closes: #380
This pull request seeks to enable importing by assuming a root path of each entry in the Webpack configuration. This turned out to be hilariously difficult to achieve, eventually resulting in the implementation of a custom Webpack plugin, currently inlined in the Webpack configuration.
Example:
Before
After:
Open questions:
resolve.modules = [ 'editor', 'i18n', 'element', 'blocks', 'node_modules' ], with the downside being that it becomes possible toimport Editable from 'components/editable';(ablockscomponent) from theeditorpath.Testing instructions:
Verify that
npm run buildresults in no module resolution errors.