webpack: Webpack 5 HMR plugin error in runtime.[hash].hot-update.js

Bug report

What is the current behavior? i am not sure whether this is webpack-dev-server issue or webpack or something else, however after 1st hot reload happens there is a constant error:

jsonp chunk loading:103 Uncaught TypeError: Cannot read property 'push' of undefined
    at self.webpackHotUpdatePACKAGEJSONNAME (jsonp chunk loading:103)

self["webpackHotUpdatePACKAGEJSONNAME"] = (chunkId, moreModules, runtime) => {
	for(var moduleId in moreModules) {
		if(__webpack_require__.o(moreModules, moduleId)) {
			currentUpdate[moduleId] = moreModules[moduleId];
			if(currentUpdatedModulesList) currentUpdatedModulesList.push(moduleId);
		}
	}
	if(runtime) currentUpdateRuntime.push(runtime); // error happens here
	if(waitingUpdateResolves[chunkId]) {
		waitingUpdateResolves[chunkId]();
		waitingUpdateResolves[chunkId] = undefined;
	}
};

If the current behavior is a bug, please provide the steps to reproduce.

launch dev-server with hot:true

What is the expected behavior? does not happen in webpack@4 i think that the issue is that this variable currentUpdateRuntime is accessed before it is initialized in: __webpack_require__.hmrI.jsonp or __webpack_require__.hmrC.jsonp

Other relevant information: webpack version: 5.1.0 Node.js version: v12.18.0 Operating System: Windows 10 Additional tools: webpack-devs-server@latest

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (5 by maintainers)

Commits related to this issue

[#11670] Adds a warning about incorrect use of HMR chunks Namely, this update adds to the beginning of each xxx.hot-update.js chunk a simple check that the chunk is loaded by a <script> element with ... — committed to birdofpreyru/webpack by birdofpreyru 4 years ago

Most upvoted comments

@evilebottnawi I figured it out. It happens if any XXX.hot-update.js is by mistake loaded into the frontend as a standalone script. Thus not a Webpack bug, but detecting it automatically and throwing a clear error message may be a nice feature. The mistake is easy to do, if somebody takes chunk names from webpack stats and injects them all as <script> into html (oiginally there is no xxx.hot-upload.js chunks, and when they appear it is difficult to find out the problem from an obscure error message about a crush inside Webpack).

birdofpreyru on Oct 23, 2020

I had the same issue when using Module Federation. If I remove the federated import (import('MyModule/Button')), then everything works fine. Adding the federated import and things break.

I am using a proxy to avoid CORS issues, so that localhost:3000 goes to my host app, and localhost:3000/federation/MyModule redirects to my other app.

When the websocket message arrives, it inits currentUpdateRuntime = [].

I think the issue is that the webpack/runtime/jsonp chunk loading (self.webpackHotUpdate) is being loaded a second time when I import my other app. In the dev tools, I can see that it’s being run from the other app when it errors. So I suspect it’s re-initing var currentUpdateRuntime;.

I guess its an issue with my entry point from my other app.

vjpr on Apr 14, 2022

@SecretPocketCat Correct.

birdofpreyru on Nov 11, 2022

@evilebottnawi I figured it out. It happens if any XXX.hot-update.js is by mistake loaded into the frontend as a standalone script. Thus not a Webpack bug, but detecting it automatically and throwing a clear error message may be a nice feature. The mistake is easy to do, if somebody takes chunk names from webpack stats and injects them all as <script> into html (oiginally there is no xxx.hot-upload.js chunks, and when they appear it is difficult to find out the problem from an obscure error message about a crush inside Webpack).

@birdofpreyru This saved me, thanks so much for this!

kbruccoleri on Sep 29, 2022

please ignore, this seems to be a webpack-assets-plugin issue and not webpack/dev-server, sorry again

SPWizard01 on Oct 13, 2020