Conversation
| { | ||
| test: /\.m?js$/, | ||
| resolve: {fullySpecified: false} | ||
| }, |
There was a problem hiding this comment.
Reading webpack docs on rules, these are nested under a oneOf block, and so I would expect that only the first matching rule would be applied. I believe this means that this rule would never get hit for .mjs files given the rule above. Do we want to add the same {fullySpecified: false} to the first rule in the list to cover mjs files?
Also, to the bigger point, I'm not sure how to interpret the comment "Handle non-esModules from within esModules without specifying their file extension" - can you help remind me what this is changing / fixing?
Our top-level resolve block has the list of extensions.
I see in the docs that this fullySpecified option is (weirdly?) called out only within the rules section - https://webpack.js.org/configuration/module/#resolvefullyspecified - but then I don't see it within the top-level docs for resolve - https://webpack.js.org/configuration/resolve/#resolve
I don't really know what to make of that, and I'm struggling to understand what the docs are saying here. Don't we get the behavior from the top-level block where any imports will match files with extensions in the list? What does this new directive do differently? What issue are we hitting with dev-utils that this overcomes?
| { | ||
| test: /\.js$/, | ||
| enforce: "pre", | ||
| use: ["source-map-loader"], |
There was a problem hiding this comment.
How will we hit this new rule, given the oneOf block it's nested underneath? I would expect any js file to be captured and processed by the second rule in the array, and would not think that anything would hit this new rule.
Did you see any effect from it?
2 participants
No description provided.