Frontend Development Build Not Working

[cgarwood]

Checklist

• I have updated to the latest available Home Assistant version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.
• I have tried reproducing the issue in safe mode to rule out problems with unsupported custom resources.

Describe the issue you are experiencing

The development frontend build (from script/develop) is resulting in the frontend being stuck on the loading screen with javascript errors in the console:

VM722:201 Uncaught (in promise) SyntaxError: Identifier 'clearUrlParams' has already been declared
    at ./src/entrypoints/core.ts (core.js:107:1)
    at __webpack_require__ (core.js:673:31)
    at core.js:823:27

VM852:10 Uncaught (in promise) RangeError: Maximum call stack size exceeded
    at module.exports (eval at ./node_modules/core-js/internals/normalize-string-argument.js (app.js:747:1), <anonymous>:10:27)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:22:17)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)
    at new DOMException (eval at ./node_modules/core-js/modules/web.dom-exception.stack.js (app.js:1071:1), <anonymous>:24:14)

This started with my frontend dev environment (bare metal Ubuntu) that was working OK ~2 weeks ago.

• I tried using the devcontainer, and got the same console error.
• I tried deleting the frontend build, hass_frontend, and node_modules folders, and re-running yarn and script/develop, same console error.
• I deleted the entire frontend development directory, re-pulling from git, and re-running yarn and script/develop
• I manually modified the <title> tag in hass_frontend/index.html to confirm that my HA Core was serving the current development build
• I deleted my entire Home Assistant development VM, re-installed a fresh copy of Ubuntu, pulled the core and frontend repositories, ran both devcontainers, and still get the same error.
• I've tested in Chrome , Firefox, and Edge on two separate devices.
• The frontend loads fine if I comment out development_repo and use the packaged version.

Describe the behavior you expected

Development frontend build works properly

Steps to reproduce the issue

Details above.

What version of Home Assistant Core has the issue?

2025.01-dev

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue with?

Chrome 131.0.6778.86, Firefox 131.0.6778.86 and 133.0, Edge 131.0.2903.86

Which operating system are you using to run this browser?

Windows 11 23H2, Ubuntu 24.04.1

State of relevant entities

No response

Problem-relevant frontend configuration

No response

Javascript errors shown in your browser console/inspector

No response

Additional information

No response

[cgarwood]

I've traced it to #22807

The prior commit builds fine (09c5dab)
The commit merging that PR gives me the console errors/pages not loading as mentioned in the issue above.

[wendevlin]

Hi @cgarwood,

Sorry to hear that. Maybe your node version is too old? We use node 20

Strange that the issue is in devcontainer too 🤔

[silamon]

We had already checked this on discord, it was v20.18.1.

[cgarwood]

Yeah, On Node 20.18.1. The devcontainer not working is the really weird one for me, especially after a fresh build. Makes it feel like its my system, but two different installs now exhibit the same issue. Surprised it hasn't cropped up for anyone else. Kind of at a loss 🫠

[steverep]

Try clearing your Babel cache and rebuilding:

rm -rf node_modules/.cache/babel-loader

Is this isolated or can others repro?

[cgarwood]

I had tried nuking the entire node_modules a couple times. Will try just deleting the babel cache folder

[steverep]

Deleting node_modules usually does nothing unless you also clear the yarn cache (which is stored in the home directory). If you are starting with a fresh container, that would have been empty too.

The error is a bit perplexing... did you also try clearing the browser site data for localhost (not just the cache with shift+F5, but all site storage via browser settings)?

Also, do you have a path and/or query params in the URL?

[cgarwood]

No change after deleting the babel cache.

No path or query params. However, if I try to go to /onboarding.html I get a different, but similar error in the browser console:

Uncaught (in promise) SyntaxError: Identifier 'HaOnboarding' has already been declared
    at ./src/onboarding/ha-onboarding.ts (onboarding.js:415:1)
    at __webpack_require__ (onboarding.js:1613:31)
    at eval (eval at ./src/entrypoints/onboarding.ts (onboarding.js:399:1), <anonymous>:3:78)
    at ./src/entrypoints/onboarding.ts (onboarding.js:399:1)
    at __webpack_require__ (onboarding.js:1613:31)
    at onboarding.js:1877:27

Or a login page URL gives me:

VM52859:433 Uncaught (in promise) SyntaxError: Identifier 'appNames' has already been declared
    at ./src/auth/ha-authorize.ts (authorize.js:199:1)
    at __webpack_require__ (authorize.js:1351:31)
    at eval (eval at ./src/entrypoints/authorize.ts (authorize.js:355:1), <anonymous>:3:71)
    at ./src/entrypoints/authorize.ts (authorize.js:355:1)
    at __webpack_require__ (authorize.js:1351:31)
    at authorize.js:1615:27

Haven't specifically gone through the browser to clear all data for the site, but I did have the same errors on Firefox on the new development VM after a fresh re-install, so it wouldn't have had any saved site data.

Seems like its mostly limited to my setup (otherwise I assume other people would have reported it) but no clue what/why. Definitely odd.

[steverep]

I'm not sure how, but your VM seems to be mucking with something. It's kind of behaving like a global script that's being run twice. It fails on the first const declaration in each case.

Maybe try a private window?

[cgarwood]

Same behavior in a private browsing window as well. I'm thinking it has to be related to the build process instead of the browser, as I get the same behavior on two different computers and my phone browser also isn't loading the page (iPhone, don't have a Mac so not sure if there's a way to get access to the Safari JS console).

I tried pulling the devcontainers on a separate Windows 11 machine and running them through Docker directly on that windows machine and the UI loads OK there. Wondering if it's something Ubuntu specific with RSPack?

[steverep]

Try:

1. In build-scripts/rspack.cjs, search for and remove "eval-" from the devtool setting.
2. Build both cases - the one that works and the one with errors.
3. Do a diff -r on the 2 in hass_frontend/frontend_latest.

They ought to be identical, but if they are different then rspack is indeed corrupting it somehow.

[cgarwood]

The diff on the build is pretty significant between bd0bfc1 and 09c5dab

However, changing "eval-cheap-module-source-map" to "cheap-module-source-map" gets rid of the console errors. If I re-add the eval-, rebuild, and refresh, the console errors are back and the frontend doesn't load. Remove eval- and rebuild and it starts working again consistently.

edit: tested a few other devtool options, and it appears any option starting with eval- causes the error, but options I tried without eval- work OK.

[steverep]

The diff on the build is pretty significant between bd0bfc1 and 09c5dab

Yeah a significant diff would be expected between commits. I meant between the build that gives you errors and the one you said works when you pulled the container on a separate Windows 11 machine (same latest commit).

However, changing "eval-cheap-module-source-map" to "cheap-module-source-map" gets rid of the console errors. If I re-add the eval-, rebuild, and refresh, the console errors are back and the frontend doesn't load. Remove eval- and rebuild and it starts working again consistently.

That's interesting - not sure what to make of that yet. The point of telling you to remove eval was to enable readable code and diffs in the output. With eval enabled, each module gets collapsed into a single string and single line, making it really hard to examine or diff.

[cgarwood]

Yeah a significant diff would be expected between commits. I meant between the build that gives you errors and the one you said works when you pulled the container on a separate Windows 11 machine (same latest commit).

aaaah that makes way more sense 😆 I'll try to grab that

[cgarwood]

diff -r on the folders themselves gives 600mb of output. However, if I limit it to frontend_latest/core.js and frontend_latest/app.js:

On cheap-module-source-map there are no differences between the working windows build and broken ubuntu build.
On eval-cheap-module-source-map app.js and core.js appear quite different. output of diff -r for those two files attached.
app.js.diff.txt
core.js.diff.txt

[steverep]

That's good info, but because the eval wraps everything into the same line, the diffs are almost useless without further parsing. The one thing I can tell though is that the differences are in the wrapped code, i.e. something is different between the 2 when Rspack converts the code to a string for eval. That means it's not generating different runtime code.

This is probably an issue to file with Rspack. If you maybe parse the eval versions into lines somehow and then diff them, you might be able to pinpoint where the conversion is going wrong and why.

[cgarwood]

Went ahead and opened an issue on the rspack repo: web-infra-dev/rspack#8710 linking back to this one