-
-
Notifications
You must be signed in to change notification settings - Fork 65
Route Pattern not working #68
Comments
i have the same issue app.UseEndpoints(endpoints =>
{
endpoints.MapToVueCliProxy(
"admin/{*path}",
new SpaOptions {SourcePath = "client-app"},
npmScript: (System.Diagnostics.Debugger.IsAttached) ? "serve" : null,
regex: "Compiled succesfully",
forceKill: true);
endpoints.MapDefaultControllerRoute();
}); and my vue.config.js module.exports = {
publicPath: '/admin/',
} |
AFAIK the debugger will continue to server addresses at the ROOT even with things like app.UsePathBase and custom mappings added. Can you see if your app works at the custom URL as well as the root? I've experienced similar issues with aspnetcore routing. |
The route pattern seems to work here, combined with a vue.config.js file: Startup.Configure:
vue.config.js:
Unfortunately hot reload doesn't work after these changes. It seems that the browser cannot connect to the hot reload socket as it continuously reciecves 404 for requests to Could this be due to the |
The solution to the hot reload not working is to configure Webpack's devserver to serve the socket from the same subroute as the Vue app itself, like so: vue.config.js: module.exports = {
publicPath: '/clientapp/',
devServer: {
public: 'localhost',
sockPath: '/clientapp/sockjs-node'
}
} (for some reason the |
Hi !
I'm using the version 3.1.1.
I define the MapToVueCliProxy route pattern as follow
endpoints.MapToVueCliProxy( "booking", new SpaOptions { SourcePath = "../Kronos.BookingClient" }, npmScript: System.Diagnostics.Debugger.IsAttached ? "serve" : null, regex: "Compiled successfully", forceKill: true, https: true);
My website continue to serve the vuejs project on root (https://localhost:44389/ instead of https://localhost:44389/booking)
I also tried
endpoints.MapToVueCliProxy( "booking/{*path}", new SpaOptions { SourcePath = "../Kronos.BookingClient" }, npmScript: System.Diagnostics.Debugger.IsAttached ? "serve" : null, regex: "Compiled successfully", forceKill: true, https: true);
I suppose it is not a normal behavior. Am I wrong ?
The text was updated successfully, but these errors were encountered: