This is the third day of my participation in Gwen Challenge

Lynne, a front-end development engineer who can cry, love and laugh forever. In the Internet wave, love life and technology.

The problem

As I saw in the book, WebPack can package and extract vendor and perform client caching to speed up the overall rendering speed when configuring entry files.

It reminds me of the loading Chunk xx failed error occurred on someone else’s computer when I entered the test session after development, although there was no problem in my local area when the same code was packaged and deployed to the test environment in the production environment. Sometimes even refreshing was invalid. But there was no problem on my computer or on the Macs I tested, and it does seem Windows has a higher frequency of occurrence…

Fix bug

Although this bug is occasionally, at that time is also on the edge of one’s seat, now recall again, also want to figure out the specific reason. Without further ado, here are the two most likely and dominant (and most outrageous) causes and their solutions, based on my research and thinking.

The most common one – route lazy loading + cache

During project development, some JS files will change after we upload them to the test environment. After we upload them to the server, users will access the previous JS files again due to browser cache problems. This means that the newly packaged JS file is changed, but the old index.html that uses the browser cache is still loaded on the old chunk. This situation can be resolved by refreshing the page, which is much easier.

In routing of lazy loading cases, access to the current application for routing jump is real-time dynamic pull on the corresponding module of js file from the server, then change the code package online, when routing jump because the page does not refresh, so access to the original file name, this is can’t find module error will occur. The recommended solution is to catch the router.onError error and refresh it. In the onError method, reload our target page.

/* Router.onError ((error) => {const pattern = /Loading chunk (\d)+ failed/g; const isChunkLoadFailed = error.message.match(pattern); const targetPath = router.history.pending.fullPath; if (isChunkLoadFailed) { router.replace(targetPath); }});Copy the code

But the feedback from the development is not fully effective, so we have the plan behind!

The most outrageous one – carrier hijacking

The solution to this problem is simple: use HTTPS to encrypt data transfers and prevent requests from tampering.

I won’t go into details, because you can refer to this article – Loading Chunk X Failed of Webpack for details

If HTTPS is used or there is such a situation, anonymous reader feedback is that the package name starts with 16 easy to be hijacked, I??

conclusion

To summarize, these are the two main solutions to this problem, but it is avoided by simply cleaning the cache or repackaging occasionally. There is more than one possible cause, so it doesn’t seem to solve the problem of the occasional error once and for all. At the end of the discussion in this issue, there is no clear answer that everyone agrees on…

HTTPS to avoid carrier hijacking this solution actually I have not tested (don’t call me…) , if later encountered also want to see.

Conversations,

I wanted to talk about how to use Uglify in WebPack 2.x to clean up markup code and then compress it, but I came across this problem for a long time.

Well, tomorrow’s content is booked, I believe I will not pigeon…

The resources

  • The most comprehensive discussion and analysis on this subject – https://github.com/PanJiaChen/vue-element-admin/issues/439