regression due #15899

[alexander-akait]

please create small reproducible repo

Here you go:
https://github.com/jsg2021/webpak-hanging-bundle-example

Originally posted by @jsg2021 in #15899 (comment)

[webpack-bot]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[alexander-akait]

bump

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

[steverep]

I'm not sure if this is the same issue yet, but something completely broke @home-assistant frontend from 5.72.1 to 5.73.0. The app now just completely hangs - no webpack errors or warnings and nothing in the console either.

@jsg2021 you mentioned in the PR that you were able to work around the problem. How?

[jsg2021]

@jsg2021 you mentioned in the PR that you were able to work around the problem. How?

In my example repo, it's importing a module that uses a top-level await... i factored that module out of my graph. I can't remember if i got rid of it, or marked it external. It's been a while.

[steverep]

Ah okay. Thanks anyway.

[steverep]

@alecmev you had mentioned having a similar issue. Were you ever able to figure it out?

[alecmev]

@steverep Nope, still pinned to 5.72.1, sorry.

[steverep]

I was able to better characterize the issue (at least in my case). It seems the entry bundle is no longer being recognized as JS:

Error
Loading module from “http://localhost:8124/frontend_latest/authorize.js” was blocked because of a disallowed MIME type (“text/plain”).

This doesn't show in the console when the code is wrapped in eval, which made it harder to trace.

@alexander-akait any idea what is the root cause here?

[jsg2021]

@steverep That suggests it's a different issue. In my case the file is served...it just never calls back to the module graph to finish bootstrapping. (the top-level await)

In your case...What is serving the files? refusing to serve the file would be a bug in the web service configuration, but the output files's mine type (i don't think) is not handled by webpack ??

most systems map mime type by file extension. some file systems can set it as metadata on the file.

[steverep]

@jsg2021 sorry my comment wasn't very clear. The entry chunk actually does begin to load, so that error is caused by the webpack runtime trying to load an async chunk somewhere.

[steverep]

Just following up on my previous comments.. The type text/plain error is actually unrelated and caused by an empty module. I can fix that and the bigger issue remains.

In short, loading the entrypoint either with import() or <script> appears to be done successfully, but async chunks never start loading.

I've been through the diffs between 5.72.1 and 5.73.0 multiple times and #15899 seems like the only viable one to blame (and also the one I understand the least 😕).

[ConnorLanglois]

I believe I know partially what is happening here, just ran into this issue myself. It seems that if you have a module that does top-level await conditionally, then the module chain won't finish loading. Please see this repo for a minimal reproducible example along with basic debug I did to confirm it, pasted below for reference:

Some debugging I did with my free time into this issue (see the code above for context for this to make sense):

The forced await statement is needed for some reason because I am fairly certain there is a bug in webpack with TLA (top-level await), where a module has top-level await but does it conditionally (like 'variable && ...'). Here, webpack does not load the module chain correctly. It seems like this is the case because of the order that the JS runtime executes async functions.
Ex:

CASE 1:

> (async () => { console.log('test 1'); })(); console.log('test 2');
test 1
test 2

CASE 2:

> (async () => { await 'test'; console.log('test 1'); })(); console.log('test 2');
test 2
test 1

The await causes the statement outside the async function to run first.

Using a dummy await 'test' in moduleWithTLA.js forces the JS runtime to execute like CASE 2 and I'm guessing webpack assumes this behavior always occurs.

From deep-dive into webpack, it appears that it is setting hasAwait, for the __webpack_require__.a invocation with this module, to 1. Here is an excerpt of that from the build:

/***/ 795:
/***/ ((module, __unused_webpack___webpack_exports__, __webpack_require__) => {

__webpack_require__.a(module, async (__webpack_handle_async_dependencies__, __webpack_async_result__) => { try {
// Comment out line 2 and uncomment line 3 to get fixed/expected behavior.
__webpack_require__.g.someNonExistentVariable && await 'test';
// await 'test';

console.log('here 2');



__webpack_async_result__();
} catch(e) { __webpack_async_result__(e); } }, 1); // <--- THIS `1` RIGHT HERE

/***/ })

Note the comment "THIS `1` RIGHT HERE" marking the code of interest. This 1 seems like it would be correct, since the module does contain a top-level await. But it may not actually execute that await statement if done conditionally like above. If you remove the 1 (the last function argument entirely), the code runs correctly. But this can't be an actual solution obviously because the await statement could run sometimes depending on the condition.

This is the extent to which I debugged the issue to determine it is likely a webpack bug.

[steverep]

I can confirm that conditional TLA is the problem. When I refactor to remove the conditionals from the await, I can upgrade to 5.73.0 or 5.81.0 without any issue.

@ConnorLanglois thanks for figuring this out 👏🏻

@alexander-akait maybe it's time to remove "possible" from the issue title? 😉

[alexander-akait]

Yeah, feel free to send a fix if you want to help, also put this in our board