ESBuild suddenly displays blank page in development mode [17.1.0]
Command
serve
Is this a regression?
- [ ] Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was
No response
Description
Since yesterday, suddenly all our 4 clients started to only display a blank page when run in development mode. No errors anywhere.
Building and deployment works fine.
When changing the builder back to "browser" everything works again.
I have tried to create a minimal version by stripping away all code, but still maintain the issue, as least in our end.
Minimal Reproduction
git clone https://github.com/spock123/esbuild-blankspace.git
npm install
npm run dev
Stop serving, change angular-json:
Change:
"builder": "@angular-devkit/build-angular:browser-esbuild",
to:
"builder": "@angular-devkit/build-angular:browser",
npm run dev
Exception or Error
When loading the page, a blank screen is displayed.
Initial index.html is loaded but application not bootstrapped or loaded.
Your Environment
Angular CLI: 17.1.0
Node: 20.10.0
Package Manager: npm 10.2.3
OS: darwin arm64
Angular: 17.1.0
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, localize, material, platform-browser
... platform-browser-dynamic, router, service-worker, ssr
Package Version
---------------------------------------------------------
@angular-devkit/architect 0.1701.0
@angular-devkit/build-angular 17.1.0
@angular-devkit/core 17.1.0
@angular-devkit/schematics 17.1.0
@angular/fire 17.0.1
@schematics/angular 17.1.0
rxjs 7.8.1
typescript 5.2.2
zone.js 0.14.0
Anything else relevant?
It apparently stopped working since yesterday, where all our clients were functioning without issue. Multiple developers experience same issue, so it's probably not a local environment issue. We have reverted to use the old browser builder and it works fine there, - frustratingly.
Appreciate any help
Update: I downgraded to 17.0.9 and now it works again!
In the linked github project, this is the branch called "downgrade"
What is happening here is that the baseHref is set to /en which vite normalizes to /en/ which causes the files to only be accessible from /en/.
This can be seen in the response The server is configured with a public base URL of /en - did you mean to visit [/en/polyfills.js](http://localhost:4100/en/polyfills.js) instead?
What are your intentions of having a base-href of /en instead of /en/? From our end, we could probably ignore setting the public base to base href when it does not terminate with a slash.
Thanks @alan-agius4 . This must have be changed between 10.0.9 and 10.1.0, as it worked up to this point? Change in Vite perhaps? The idea with the base-href is that we serve multiple languages for our app (the repo is a very stripped down version with just one language). I'll definitely investigate and update status, thanks!
@alan-agius4 it works! Amazing, thank you so much!
You're welcome to close the issue, apparently it allows for the missing slash in 17.0.9, and not in 17.1.0.
Cheers, and thank you
Found this old PR in Vite, where they allowed missing trailing slashes:
https://github.com/vitejs/vite/pull/10723
@alan-agius4 before you close it, I noticed that now that I changed the baseHref to include a trailing slash, references to assets like this: /assets/test.gif do not work in development mode, as the link does not get the baseHref added.
Anything we can do about this? It would be pretty unfortunate if global references to assets stopped working.
If I remove the trailing slash again, links to /assets work again - but of course then the compiler complains once it's time to do a production build.
Update: I did some digging and that's apparently by design. baseHref is only prepended to relative urls, not global urls.
@spock123, that is indeed working as expected. I am not quick sure what setup / structure are you going for but from the gist of it it looks like you'd want to set a base-href of /.
@alan-agius4 yes thanks. I think I will do that in development mode. thank you. Unfortunately I don't think it's possible to set/override baseHref with a parameter to the cli, which makes it a bit more tricky. It means that we cannot use targets in our configuration, as they all have the correct baseHref.
We could of course replicate the cli configuration targets but it is already quite large due to the amounts of locales (we have 12!)
It used to be an option for the cli, to set the base href when using ng serve, but that was taken away long time ago.
We'll solve it somehow, thanks for your time
Closing as the issue seems to have been resolved.
@alan-agius4 It has indeed. Thanks
This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.