Skip to content
This repository has been archived by the owner on Apr 8, 2020. It is now read-only.

Support for Angular-cli #828

Closed
starquake opened this issue Mar 30, 2017 · 20 comments
Closed

Support for Angular-cli #828

starquake opened this issue Mar 30, 2017 · 20 comments

Comments

@starquake
Copy link

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.

@zihotki
Copy link

zihotki commented Mar 30, 2017

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.

@ADefWebserver
Copy link

ADefWebserver commented Mar 30, 2017

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.

@zihotki
Copy link

zihotki commented Mar 31, 2017

@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.

@ADefWebserver
Copy link

@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...

@SteveSandersonMS
Copy link
Member

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.

@starquake
Copy link
Author

starquake commented Mar 31, 2017

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.

@aaronmarisi
Copy link

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.

@SteveSandersonMS
Copy link
Member

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!

@starquake
Copy link
Author

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

@MarkPieszak
Copy link
Contributor

MarkPieszak commented Apr 7, 2017

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.

@starquake
Copy link
Author

That's exactly what I'm doing. 😀

@ADefWebserver
Copy link

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.

@aherrick
Copy link

aherrick commented Apr 8, 2017

@starquake looking forward to seeing your solution!

@aaronmarisi
Copy link

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.

@aaronmarisi
Copy link

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

@starquake
Copy link
Author

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.

@stibay
Copy link

stibay commented Aug 1, 2017

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

@MarkPieszak
Copy link
Contributor

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.

@spottedmahn
Copy link

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.

@SteveSandersonMS
Copy link
Member

@spottedmahn Work is underway in #1288.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants