You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think vite plugins (even just a single vite plugin) should be addable to the angular.config, as an advanced dev-server option. I think this would be valuable primarily because there are significant differences between the webpack proxy server and the vite proxy server and adding this would be a useful escape hatch for any issues that come up.
If you look into it you'll see that the vite proxy server is simplistic and doesn't have much functional test coverage, whereas the vite plugin/middleware APIs are pretty full featured and well tested. Therefore limiting developers to the functionality of the vite proxy server is harming users and creating unnecessary support issues for angular (b/c the proxy is our only way to change request behavior during development).
Here are some of the changes between the webpack proxy and the vite proxy:
bypass fn doesn't support async/Promise methods
(I opened an issue for this and it's being worked on)
bypass fn doesn't officially support bypassing the request
See the conversation here - in short, the maintainer said:
we can't use vite plugins/middleware, b/c Angular exposes the vite proxy API, but doesn't allow vite plugins to be added.
I think Angular should expose an additional feature on their side; it doesn't feel right to me to create duplicate surfaces on the Vite side for a workaround just because Angular limited the surfaces.
It seems to me there are a number of angular issues due to the vite proxy server not being compatible with the webpack proxy server API, where people have built up significant dev server capabilities that is all associated with the old proxy server, and they can't migrate due to features they rely on not being supported. This feature would at least give people a way to help themselves.
Write a new out-of-process dev proxy server that has to be spun up before the dev server is started, and proxy everything to it that requires replacing development request behavior. This would be cumbersome during development, and also some work to write - we would have to proxy websockets for example.
The text was updated successfully, but these errors were encountered:
Command
serve
Description
I think vite plugins (even just a single vite plugin) should be addable to the angular.config, as an advanced dev-server option. I think this would be valuable primarily because there are significant differences between the webpack proxy server and the vite proxy server and adding this would be a useful escape hatch for any issues that come up.
If you look into it you'll see that the vite proxy server is simplistic and doesn't have much functional test coverage, whereas the vite plugin/middleware APIs are pretty full featured and well tested. Therefore limiting developers to the functionality of the vite proxy server is harming users and creating unnecessary support issues for angular (b/c the proxy is our only way to change request behavior during development).
Here are some of the changes between the webpack proxy and the vite proxy:
bypass
fn doesn't support async/Promise methods(I opened an issue for this and it's being worked on)
bypass
fn doesn't officially support bypassing the requestSee the conversation here - in short, the maintainer said:
router
It seems to me there are a number of angular issues due to the vite proxy server not being compatible with the webpack proxy server API, where people have built up significant dev server capabilities that is all associated with the old proxy server, and they can't migrate due to features they rely on not being supported. This feature would at least give people a way to help themselves.
Describe the solution you'd like
Describe alternatives you've considered
Write a new out-of-process dev proxy server that has to be spun up before the dev server is started, and proxy everything to it that requires replacing development request behavior. This would be cumbersome during development, and also some work to write - we would have to proxy websockets for example.
The text was updated successfully, but these errors were encountered: