Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

ng serve with esbuild fails to serve directory assets #27044

Closed
georgmu opened this issue Feb 6, 2024 · 1 comment · Fixed by #27049
Closed

ng serve with esbuild fails to serve directory assets #27044

georgmu opened this issue Feb 6, 2024 · 1 comment · Fixed by #27049

Comments

@georgmu
Copy link
Contributor

georgmu commented Feb 6, 2024

Which @angular/* package(s) are the source of the bug?

Don't known / other

Is this a regression?

Yes

Description

I have a setup with a non-angular login page, served at path /#/. This is included via assets in angular.json:

...
            "assets": [
              "src/favicon.ico",
              "src/assets",
              "src/#"
            ],
...

When using ng serve with @angular-devkit/build-angular:browser and calling curl http://localhost:4200/#/, the login page is returned.

When using ng serve with @angular-devkit/build-angular:browser-esbuild or @angular-devkit/build-angular:application and calling curl http://localhost:4200/#/, the index.html of the angular project is returned.

The application redirects to /#/ if authentication is missing. This results in a redirect loop from / to /# (because angular router does not know about any /#/ route).

A work-around is to redirect directly to the index.html page ( curl http://localhost:4200/#/index.html works with both esbuild and the old setup), but this is looks a bit ugly.

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 17.1.2
Node: 20.10.0
Package Manager: npm 10.4.0
OS: linux x64

Angular: 17.1.2
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, localize, material, platform-browser
... platform-browser-dynamic, router

Anything else?

No response

@JoostK JoostK transferred this issue from angular/angular Feb 6, 2024
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Feb 7, 2024
…d with Vite dev-server

Prior to this commit, the Vite html fallback middleware failed to handle the in-memory assets generated by Angular CLI, resulting in incorrect fallback behavior. For instance, when an `index.html` existed as an asset under a specific path, the generated `index.html` would be served instead.

This fix addresses the issue, ensuring that the appropriate `.html` is served when using the Vite dev-server.

Closes angular#27044
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Feb 7, 2024
…d with Vite dev-server

Prior to this commit, the Vite html fallback middleware failed to handle the in-memory assets generated by Angular CLI, resulting in incorrect fallback behavior. For instance, when an `index.html` existed as an asset under a specific path, the generated `index.html` would be served instead.

This fix addresses the issue, ensuring that the appropriate `.html` is served when using the Vite dev-server.

Closes angular#27044
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Feb 7, 2024
…h Vite dev-server

Prior to this commit, the Vite html fallback middleware failed to handle the in-memory assets generated by Angular CLI, resulting in incorrect fallback behavior. For instance, when an `index.html` existed as an asset under a specific path, the generated `index.html` would be served instead.

This fix addresses the issue, ensuring that the appropriate `.html` is served when using the Vite dev-server.

Closes angular#27044
alan-agius4 added a commit that referenced this issue Feb 7, 2024
…h Vite dev-server

Prior to this commit, the Vite html fallback middleware failed to handle the in-memory assets generated by Angular CLI, resulting in incorrect fallback behavior. For instance, when an `index.html` existed as an asset under a specific path, the generated `index.html` would be served instead.

This fix addresses the issue, ensuring that the appropriate `.html` is served when using the Vite dev-server.

Closes #27044
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Feb 9, 2024
…d with Vite dev-server

Prior to this commit, the Vite html fallback middleware failed to handle the in-memory assets generated by Angular CLI, resulting in incorrect fallback behavior. For instance, when an `index.html` existed as an asset under a specific path, the generated `index.html` would be served instead.

This fix addresses the issue, ensuring that the appropriate `.html` is served when using the Vite dev-server.

Closes angular#27044
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 9, 2024
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
2 participants