Feature Request: Integrate AotPlugin

[DzmitryShylovich]

New @ngtools/webpack version was released. I think you can try to integrate it.

https://github.com/angular/angular-cli/blob/master/packages/webpack/README.md

[qdouble]

@DzmitryShylovich starting on it now

[qdouble]

I was going to release this today, but the plugin seems to have a few bugs, so I'm going to wait to see if they release any patches next week first before making a bunch of workarounds.

[brandonroberts]

You won't need the angular2-router-loader anymore either. You'll lose the ability to have loadChildren with sync modules though.

[qdouble]

@brandonroberts, yeah... it still seems to offer that benefit, no reason to ditch it if adds a feature

[bmayen]

Are there any issues in particular that are blocking this? Would like to upvote them.

[DzmitryShylovich]

https://github.com/angular/angular-cli/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20aot

[qdouble]

As an update, there's still about 3 big bugs with ngtools that makes switching not worth it for right now:

1. ViewEncapsulation.None or Emulated break the build or cause styles not to import properly:
   @ngtools crashes when using scss with ViewEncapsulation.None angular/angular-cli#2584

2. Nested types are often not properly resolved
   It's related to this TS bug XXX has or is using name 'Foo' from external module "../bar" but cannot be named microsoft/TypeScript#9944

3. It strips custom decorators: Custom decorators are stripped when using the AoT build flag angular/angular-cli#2799

Once those 3 issues are solved, I'll switch over to it (I can live with problem 2, but 1 and 3 are deal breakers).

[sonicoder86]

@qdouble By default it only emulates encapsulation, None creates global styles which can be resolved with ExtractTextPlugin

Are custom decorators really a must? Built multiple Angular 2 apps without them.

[qdouble]

@BlackSonic default encapsulation is Native... both Emulated and None break the build... this will be problematic whether or not you use ExtractTextPlugin I believe. Still researching the decorator thing, but if I stops things like @ngrx/effects from working properly, then that's definitely a problem.

The big issue is, is it really worth using ngtools if you have to work around a ton of bugs that don't exist with the current solution being used with this repo?

[sonicoder86]

If you rely on them it can be an issue yes...my aot starters default also runs on ngc and the secondary is the plugin.

[qdouble]

The encapsulation bugs occur at compile time, before the build process...it basically doesn't find your css/scss files when you set it that way, so it's a compilation error that occurs before the build process. Issue 2) can be worked around by explicitly casting the type... a bit tedious but I can live with that.

You technically can use ngtools with some apps and make it work, but I think it's best to wait and see if some more of the bugs get worked out.

[montella1507]

@qdouble Hi Anthony, It is possible to branch project to solution with this fork of webpack/ngtools that doesnt remove the decorators? https://github.com/Polvista/ngtools-webpack-keep-decorators

Then just merge to master with normal ngtools/webpack when its fixed. (I think it wouldnt happen as i track that issue :-( )

[DzmitryShylovich]

It's doesn't make much sense to use any forks for a 1-2 week. All these issues should be fixed very soon.

[montella1507]

@DzmitryShylovich
angular/angular-cli#2584 open for 6-7 weeks without any real progress.
angular/angular-cli#2799 open for 4 weeks without any real progress.

Where did u get the information about fix date? I have already lost my hope in real fix. it has TOP priority and still lasts for 1 month :-/ It sounds littlebit hillarious to me, they have declined quick fix because of "build speed", their solution didnt split Vendor files to different bundle so every build on watch with "starter empty" application lasts 10-14 seconds and it doesnt support HMR, so every change takes 20-30 sec to take in effect :-(

The official Angular CLI solution is so far behind the QDoubles one.... I dont want to be cocky, but its really hillarious, angular 2 still has not any official working ready-to-work-with solution. Im just sad of this, especially if i dont have enough skills to help with that.

[qdouble]

@montella1507 I've been following angular since beta 0, so I know how frustrating it can be to wait on them to fix the seemingly most important things...so I've gotten into the habit of trying to hack stuff together the best I can in the meantime as we have no idea whether they will fix something this week/month/year.

As far as a ngtools branch, it's easiest for me to maintain this repo when it's based on what I'm actually using in my real projects... even with the decorator workaround, the viewEncapsulation bug would still break my apps ( when using Emulated for >>>/deep style changes), so I'd need to be able to get around both before it would make sense to switch to using it.

[DzmitryShylovich]

they are already working on view encapsulation bug angular/angular-cli#2584 (comment)

plus there were several commits related to decorators so it should be fixed in a week or 2

[jskrzypek]

@DzmitryShylovich Which commits specifically are related to decorators? git log --all --grep="\s[dD]ecorator" only turns up angular/angular-cli@b0d4b23 which isn't at all related.

[DzmitryShylovich]

angular/angular#12933

[jskrzypek]

@DzmitryShylovich
I thought you meant there were commits on angular-cli, so I don't understand your reply.

Are you saying the reason angular-cli strips out decorators during AoT is because of something in angular/angular?

[DzmitryShylovich]

angular/angular-cli#2799 (comment)
the keyword is tsickle

[jskrzypek]

Seems more like the solution is just not to use angular-cli until it's actually in some ready-to-use state.

[montella1507]

@jskrzypek to be honest, Angular CLI is not usable at all... 20-30 sec rebuild time with Starter / empty app is definitively the big tragedy. I will not WASTE any time with Angular CLIs rebuild time, when i can use this solution with 4sec rebuild time and Hot Module replacement with big solution.

I am just waiting for SASS support for solution-wide styles, because we really need source mapping. Then i will absolutely switch to QDOUBLEs starter and we will use angular cli only for component /,.. generation.

[montella1507]

At the current state with Angular CLI, Angular2 cannot be the competitor to ReactJS. Because every new developer to Angular 2 with experience with React will see, he has to wiat 30 sec with every (even the smallest one) change. Its just SAD.

[sonicoder86]

@montella1507 watch mode is coming angular/angular#12867

[qdouble]

I haven't used cli in several months, but 20-30 second rebuilds? I'm assuming it may be trying to rebuild in AOT mode if that's slow. I played around with having some of that sort of functionality in this starter, but having to run ngc after every changed seemed slow so I didn't think it was even worth doing. Might as well just dev in JIT and occasionally check your work in AOT.

[DzmitryShylovich]

angular/angular#12867

[montella1507]

@qdouble angular-cli starter solution, windows, I7 4cored, 3,5 Ghz, SSD. NO AOT
= 14sec rebuild + 1 sec browser sync "reaction" + 5 sec refresh of the page.

And of course i didnt counted the time to "make the replay the actions" that are neccesarry to see the changes.

Its rly big pain for our coders to work with AngularCLI solution, because they have to wait 20-30 sec for every sh... they want to do.

BTW on the same machine on linux, its liek 40% faster. But still terrible. I think the big problem is. AngularCLI somehow built every file (even the angular2/rxjs/other vendor files) on windows with every change in "app code"-

[DzmitryShylovich]

See angular/angular-cli#2584 bug with encapsulation is closed :)

[qdouble]

@DzmitryShylovich cool, I guess we just need the decorator thing fixed for it to be useable?

[jskrzypek]

@DzmitryShylovich after doing more research into what happens in compiler-cli, tsc-wrapped, and the role of tsickle in the offline compiler, I am left with the understanding that tsickle comes into the picture after the offline compilation step of producing the *.ngfactory.ts files, and moreover, it's role is to downlevel the metadata used in angular into jsdoc annotations in the JS output, for later use by the closure compiler. Is that correct?

If that's the case, is tsickle really a necessary step for a build process based on webpack that doesn't run the closure compiler?

[maxisam]

@qdouble angular/angular-cli#2799 ngtool uses a workaround solution for now.

[qdouble]

@maxisam yeah, I will get around to it eventually but it's not really urgent for me as I'm busy with other stuff...will accept PR if I don't get around to fiddling with it soon. Curious to see if everything will work without breaking or having to hack around.

[fxck]

@qdouble @DzmitryShylovich maybe I'm not quite understanding how @ngtools/webpack works, but how exactly does it compile sass? Is it using sass-loader internally? If so, how does it deal with your own sass configuration, say I had this in my webpack config

    new LoaderOptionsPlugin({
      debug: true,
      options: {
        sassLoader: {
          includePaths: [ root('src/app/styles') ]
        }
      }
    })

it will work fine in JIT, but I suppose AotPlugin won't know about it and simply won't compile, or? That's what I'm getting anyway. But surprisingly enough, when I use postcss with autoprefixer, my scss is actually prefixed in AOT.

[qdouble]

@fxck I don't think ngtools compiles sass directly, it just deals with the files in a way where webpack can compile it

[fxck]

then

      {
        test: /\.scss$/,
        use: [
          'to-string-loader',
          'css-loader',
          'sass-loader',
          'postcss-loader'
        ],
      },

// ---
    new LoaderOptionsPlugin({
      debug: true,
      options: {
        postcss: function () {
          return [
            Autoprefixer,
            CssNano
          ];
        },
        sassLoader: {
          includePaths: [ root('src/app/styles') ]
        }
      }
    }),

should work fine but throws..

ERROR in ./~/@angular/core/src/linker/system_js_ng_module_factory_loader.js
Module not found: Error: Can't resolve '/Users/fxck/www/ngtools-test/$$_gendir' in '/Users/fxck/www/ngtools-test/node_modules/@angular/core/src/linker'
 @ ./~/@angular/core/src/linker/system_js_ng_module_factory_loader.js 69:15-36 85:15-102
 @ ./~/@angular/core/src/linker.js
 @ ./~/@angular/core/src/core.js
 @ ./~/@angular/core/index.js
 @ multi vendors

..when trying to import a file(which works fine in JIT) from location defined in includePaths, I'm confused.

[qdouble]

haven't messed with ngtools in a couple of months now, but sometimes the file paths are different in aot mode vs jit, so try to see if the files exist where it's looking and if you can set it differently

[qdouble]

using the aot plugin now: 73758e1