Javascriptservices: Support for Angular-cli

Created on 30 Mar 2017  路  20Comments  路  Source: aspnet/JavaScriptServices

Could you please consider supporting angular-cli as tooling for the frontend?

I tried the angular 2.x template and tried to add SASS and bootstraps support. But it gets complicated very quickly. Then I saw the angular 4.x template and saw it was even more complicated. I'd much rather use a tool like angular-cli. It has everything I need and was a lot easier to understand. If I want to switch to webpack I can always ng eject.

To me the template as it is, creates too much dependency between the frontend and the backend. There's also a lot of duplication of functionality. Angular CLI does AOT and HMR just fine and you only have to set a boolean to true.

Right now I'm calling ng build to build stuff to wwwroot/dist which works well. Except I don't get the advantage of reload or HMR. Still looking into that to get it to work.

One solution is to just start 2 services. The ASP.NET server and ng serve and then proxy one or the other. But I would rather let ASP.NET start the server or serve the files.

Most helpful comment

You can certainly add an .angular-cli.json file at the root of your project that configures angular-cli to generate components/services/etc. in the correct places. Something like this:

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "project": {
    "name": "AngularBasicTemplate"
  },
  "apps": [
    {
      "root": "ClientApp"
    }
  ],
  "test": {
    "karma": {
      "config": "./ClientApp/test/karma.conf.js"
    }
  },
  "defaults": {
    "styleExt": "css",
    "component": {}
  }
}

Is that what you need?

It will probably come down to @SteveSandersonMS not wanting to take a dependency on Angular-cli

While we probably wouldn't strictly depend on angular-cli by default, we might put the .angular-cli.json file there just so it's preconfigured for anyone who does want to use angular-cli for generating files.

All 20 comments

Also agree, since angular-cli has been released it became very popular amongst angular developers. The angular template, IMO, should use it to give users more flexibility and to descope such tasks as AOT, HMR, etc. because they are already provided by officially supported angular-cli.

If you are happy with Angular-cli why would you want to use JavaScriptServices at all? (I honestly want to know because perhaps I don't fully understand all the issues).

I only used Angular-cli a little bit before I switch to JavaScriptServices., but, It seems to me that JavaScriptServices performs the same functions that Angular-cli performs. It just allows you to do it without dropping to the command line and having to manually call ng build :) The tight coupling with Visual Studio is what makes it different and along with the other features is why I switched.

@ADefWebserver the suggestions is not to use them independently but to integrate it into JavaScriptServices so that the currently working integration would continue working fine without calling ng build manually, just hit F5. Since the features are similar then it should be possible to do. And this will also allow developers to create components and other things either manually or using angular-cli. So at the end you would get all already workig features with a plenty of optional ones which would work from command line. It's a win-win, IMO.

@zihotki - I see. It will probably come down to @SteveSandersonMS not wanting to take a dependency on Angular-cli. Also I am sure you saw @MarkPieszak comment in #800:

...we are trying to do server side pre-rendering, this breaks away from the use-case of the CLI...

You can certainly add an .angular-cli.json file at the root of your project that configures angular-cli to generate components/services/etc. in the correct places. Something like this:

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "project": {
    "name": "AngularBasicTemplate"
  },
  "apps": [
    {
      "root": "ClientApp"
    }
  ],
  "test": {
    "karma": {
      "config": "./ClientApp/test/karma.conf.js"
    }
  },
  "defaults": {
    "styleExt": "css",
    "component": {}
  }
}

Is that what you need?

It will probably come down to @SteveSandersonMS not wanting to take a dependency on Angular-cli

While we probably wouldn't strictly depend on angular-cli by default, we might put the .angular-cli.json file there just so it's preconfigured for anyone who does want to use angular-cli for generating files.

It's all still quite new to me. I'm working on a way to use Angular CLI with ASP.NET Core and I almost got a working solution that is still integrated with Visual Studio. I use ASP.NET Core for the REST API and trigger angular-cli from visual studio to do frontend stuff. Will share when I figured it all out.

As you said I probably wouldn't need JavascriptServices for that.

I think I'm looking for the same as @starquake . Angular CLI can run the webpack dev server but with MUCH LESS boilerplate webpack configuration. I'd like to get the benefits of the ASP.NET WebpackDevMiddlewre (watch, refresh, HMR) but without having to manage the webpack configuration and let Angular CLI handle that.

Angular CLI can run the webpack dev server but with MUCH LESS boilerplate webpack configuration. I'd like to get the benefits of the ASP.NET WebpackDevMiddlewre (watch, refresh, HMR) but without having to manage the webpack configuration and let Angular CLI handle that.

I'm afraid I have no idea how that would work in practice. Angular CLI and ASP.NET are very different things - neither knows about the other. The way we've already set up HMR (etc) in these templates is the cleanest approach I know of.

If anyone has a proposed working implementation of a cleaner project setup, do let us know! In lieu of that I'll close this because I'm not sure what else there'd be for us to do :) Hope that's OK!

I have a proposition. Still working it out. Almost finished. Will post when it's done.

Why not just use the Angular CLI and have .NET only be your REST API? You don't even need the two to communicate / know about each other (as Steve said). Just have one project with the CLI in it, proxying to your REST Api, and when you build --prod, just have that output go into the wwwroot folder of the .NET project itself. I could post a demo of this I have if you'd like sometime. You can't have an MVC project of course, it has to just serve that static index.html, etc.

Of course you won't have server side prerendering then as well, but I don't think there's a way to achieve that (aside from ejecting the webpack config) and then we'd be back to square 1 where we are now :)

I think having the .angularcli file and being able to generate components is about as good as it gets :)

Steve one thing we could do is offer all of the options for rules that the CLI does (they just automatically install less-loader sass-loader and all those configurations, there isn't really any magic going on, it's just ready for most common scenarios.

That's exactly what I'm doing. 馃榾

I have spent more hours than I care to admit getting an Angular CLI application to run with JavaScriptServices. So the only benefit I can see is to allow people to take the (soon to be numerous) Angular CLI applications, and get them to easily work with JavaScriptServices.

I think this can be done with a "converter tool". Basically you have to create the webpack settings (I was never able to get the "eject" webpack thing to work) move your assets to the wwwroot folder, and set the startup object correctly in the "boot-client.ts" file.

@starquake looking forward to seeing your solution!

O well. A couple of points:

  • While I largely agree with separating the SPA server-side app from other Web API, there is a case to be made for a single project that has everything in it - especially for smaller/example projects
  • The eject from the CLI was pretty seamless for me in a basic example and I was able to get going with the webpack middleware pretty easily. There are some items I'm still not happy with my current implementation but I do plan to post once I work them out
  • The proxy solution sounds promising. One of the things I'm trying to avoid is having to spin up a bunch of servers manually. That's one of the things I like about the webpack middleware is that I only have to start the ASP.NET application and it handles the webpack build for me. I had assumed it was already doing some type of proxying, but haven't dug into the source yet.

In any case, thank you all for the conversation. I'll be sure to circle back here with anything I post that might be helpful. I hope you do as well.

For anyone interested, I posted an example using the ASP.NET Core JavaScript Services middleware for webpack hmr. This is implemented on top of an ejected Angular CLI project using 'ng eject': https://github.com/aaronmarisi/demo-aspnet-javascript-services-webpack-hmr

Still working on my solution/tutorial but a bug in VS2017 15.1 is currently preventing it from working... Hopefully it will be fixed soon and I can post my solution.

Not getting @SteveSandersonMS angular-cli file to work in the dotnet new angular template without any modifications.

  WARNING selectors should contain a dash
Error locating module for declaration
        SilentError: No module files found

You can only use the CLI to generate files, but you'll have to update it to reflect the different file names etc, where app.module is etc.

The middle part of this C9 video talks about using Angular CLI with WebApi. Very interesting.

I really hope that asp.net core JavaScript services can better incorporate the Angular CLI. It becomes very difficult to follow guides and samples when most of the new Angular guides use the CLI.

@spottedmahn Work is underway in #1288.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

natemcmaster picture natemcmaster  路  4Comments

DanHarman picture DanHarman  路  4Comments

Eilon picture Eilon  路  3Comments

asadsahi picture asadsahi  路  3Comments

caesay picture caesay  路  3Comments