may I ask when this is happening?

Is this already released?

Alternatively, we can use the universal approach which I do prefer.
spa.UseProxyToSpaDevelopmentServer("http://localhost:8080")
Where :8080 is the actual Vue CLI serving port.

Alternatively, we can use the universal approach which I do prefer.
spa.UseProxyToSpaDevelopmentServer("http://localhost:8080")
Where :8080 is the actual Vue CLI serving port.

UseProxyToSpaDevelopmentServer actually doesn't start a npm process, but creates only a reverse proxy to forward incoming requests to a local SPA development server... This PR addsStartVueCliServerAsync function which starts Vue CLI, so you don't need to run the process in a separate console before starting ASP.NET Core app.

@liborpansky Yes, you are correct but as far as I know the UseReact or UseAngular middlewares will rebuild the SPA EVERYTIME you start the debugger, also the spawned separate process is NOT terminated automatically when you stop debugging from VS. This process locks the port so you need Ctrl+C to manually close it before attempting next debug round.
Just my experience and I prefer the proxy over this implementation of the JavascriptService in general - not just this PR.

Cheers,
H

I personally prefer to use the debugger only when needed for this kind of web development using vscode, I'd rather the process would be streamlined by running the cli dev server when i start dotnet watch run at the terminal which i was already doing using the webpack dev server implementation instead of making a vscode task to create 2 terminals and or starting them both manually.

@danroth27 Can one of the 3 Vue PR's get some love?

Perhaps@ryanbrandenburg or@SteveSandersonMS have some input?

As far as I'm aware, we don't have plans to introduce Vue-specific features. This isn't because we have anything against Vue, but rather just to limit the growth in the number of frameworks that we're maintaining support for. The dev team only has a finite capacity for handling third-party concepts, and last year we made the strategic choice to focus on only Angular and React.

I totally understand you might not like this if Vue is your chosen framework. I also understand that in absolute global market terms, there might be a stronger case right now for Vue than Angular (though statistically probably not among ASP.NET Core devs). However we're not going to drop either Angular or React, at least for the forseeable future, because continuity of support is more important. If you want to advocate for a change to this, I'd recommend talking with the PMs@DamianEdwards and@danroth27.

So then, for the short term at least, I'd recommend publishing the Vue middleware as a separate package. This spreads out the support load across the community and makes the ASP.NET Core OSS ecosystem more healthy than having everything centralised under Microsoft control. Alternatively you can useUseProxyToSpaDevelopmentServer like@hxhieu mentions.

Also CC@mkArtakMSFT in case he has views on how to proceed with this PR.

Vue is on the rise, but it looks Angular still dominates:https://w3techs.com/technologies/comparison/js-angularjs,js-vuejs.

Even so, Vue is a great framework and we'd love to support it (along with a couple of others), but our resources are limited. I agree with@SteveSandersonMS 's assessment that this should be managed separately by the community.

If that's the case I'm going to close this PR. Thanks everyone!

I took your advice and independently published this as a nuget package.
https://github.com/EEParker/aspnetcore-vueclimiddleware
https://www.nuget.org/packages/VueCliMiddleware/2.1.1

@danroth27@SteveSandersonMS@ryanbrandenburg Would you consider#1736 which creates a common middleware which can generically handle all npm command based dev servers instead of being Angular/React specific. There is not actually much code difference between them all. Inhttps://github.com/aspnet/JavaScriptServices/issues/1656@SteveSandersonMS seems amenable to the idea. It would handle all cases and be more future proof against the next JS framework that becomes popular.

@RehanSaeed that was my initial thought +1

Thanks for your feedback@danroth27. I agree that this sort of thing should be maintained as a separate package. But I would also suggest that MS do the same with React and Ang instead of baking-in support for one framework or another. Frameworks come and go and it doesn't seem to make sense to have theappearance of favoring any of them. In the meantime I would please ask you at least support some common middleware such as#1736.

I feel the EF Core team is example of a team doing this relatively well. They split out all sorts of providers and tooling into separate packages that you pull in only when needed.

@EEParker it's will work with Quasar CLI?

This probabily don't work with Quasar, I got this error:

TimeoutException: The vue-cli server did not start listening for requests within the timeout period of 50 seconds. Check the log output for error information.

The NPM Script is:

  "scripts": {    "dev": "quasar dev",    "lint": "eslint --ext .js,.vue src",    "test": "echo \"No test specified\" && exit 0"  },

The Startup.cs is:

            app.UseSpa(spa =>            {                spa.Options.SourcePath = "Frontend";                if (env.IsDevelopment())                {                    spa.UseVueCli("dev", 8085);                }            });