fix custom webpackChunkName for aggressive import #552
Conversation
|
Your PR looks good, but I honestly don't know why loadable tries to manage all magic comments. |
|
Firstly, it can be kept backward compatible, and secondly it is consistent with code |
|
When can this PR be processed? @theKashey |
|
PR is ok, but if you are really want to use this feature without breaking in the future I urge you to add a non-snapshot based test as in the example above. |
|
@theKashey Non-snapshot test? Add to that file? |
|
@theKashey Can you describe it in more detail? |
|
@theKashey The enhanced test feels redundant to me because the snapshot is clear enough. However, I followed your advice and enhanced the key position test. |
|
Snapshot is big, detailed, and not self explanatory. As well as fragily. How many times I did just A small check after snapshot is pointing on what is REALLY IMPORTANT. |
| const result = testPlugin(` | ||
| loadable(props => import(/* webpackChunkName: "pages/[request]" */ \`./pages/\${props.path}\`)) | ||
| `) | ||
|
|
There was a problem hiding this comment.
could you add here expect(result).toEqual(expect.stringContaining('/* webpackChunkName: "pages/[request]"'')) to as long as snapshot based tests are hard to track things. Ie you cannot infer the expected behavior from the test itself.
There was a problem hiding this comment.
@kaysonwu - this advice.
| function getChunkNamePrefix(chunkName) { | ||
| if (typeof chunkName !== 'string') return '' | ||
| const match = chunkName.match(/(.+?)\[(request|index)\]$/) | ||
| return match ? match[1] : '' | ||
| } | ||
|
|
||
| function replaceChunkName(callPath) { | ||
| const agressiveImport = isAgressiveImport(callPath) | ||
| const values = getExistingChunkNameComment(callPath) |
There was a problem hiding this comment.
look like webpackChunkName is the only thing thing function returns.
There was a problem hiding this comment.
The returned webpackChunkName is not complete, so I think it should be the prefix
|
|
||
| addOrReplaceChunkNameComment(callPath, { webpackChunkName }) | ||
| addOrReplaceChunkNameComment(callPath, { ...values, webpackChunkName }) |
There was a problem hiding this comment.
No need to spread values, as long as there is only webpackChunkName inside.
Let's better get rid of them
let { webpackChunkName } = getExistingChunkNameComment(callPath) || {};or, even better, make getExistingChunkNameComment return a string.
There was a problem hiding this comment.
let { webpackChunkName } = getExistingChunkNameComment(callPath) || {};
The above writing will lead to the loss of other magic comments.
|
I feel a bit frustrated because it is not an actively maintained project. |
|
@gregberge Can you give a clear answer about this PR? |
|
@kaysonwu - my clean answer is "I've approved it". However, as long as only @gregberge is able to actually release the update we have to wait for him in any case. |
|
@theKashey your answer is clear, thank you very much! But @gregberge didn't deal with it in time. Unknown waiting is the most painful |
|
Please understand - it's always a balance between "real work", "stuff" you might do, "family", and OSS is eating a piece of everything above. |
|
@theKashey I can see that @gregberge is active on github, but he doesn't deal with PR. |
|
Yep, so I'll merge your PR with only my approval. |
fix custom webpackChunkName for aggressive import
Summary
babel-pluginwill ignore the correct customwebpackChunkNameduring dynamic import. I think it makes sense to keep this, it can store chunks in the specified directory.Test plan