Closed itrethan closed 7 years ago
I agree, we should use AOT compilation now that it's available in Angular2!
+1
there's still a lot of bugs and peculiarities in aot that would break most people's app...so this doesn't need to be added immediately
At least we can get a writeup explaining how to do it individually, so we can work the kinks out ourselves.
The details could be found here: http://blog.mgechev.com/2016/08/14/ahead-of-time-compilation-angular-offline-precompilation/
Just wondering how to do that with webpack, maybe another loader?
+1
I was finally able to get AOT running fine with Webpack 2, you guys can check it here: https://github.com/qdouble/angular2webpack2-starter . There is a known issue with lazy routes when using AOT though, hopefully they patch it soon https://github.com/angular/angular/issues/11075
@qdouble I downloaded your repo and got it to compile, excellent!. Only problem is, it doesn't work with any require()
statements, like used in most webpack apps. When I try to get it working with require(my.template.html) inside a component, it just gives error:
Error: Error encountered resolving symbol values statically. Calling function 'require', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function,
@IAMtheIAM that's an AOT limitation. You can't use require on your styles or templates with offline compile. It should work fine with JIT. For your html and styles, use templateUrl and stylesUrls... they will be bundled properly because the starter is using the angular2-template-loader.
I've updated my starter project to fully support lazy loading in AOT mode. I have to wait until there are some more updates/bug fixes before making it a bit cleaner, but it's a viable solution for now: https://github.com/qdouble/angular2webpack2-starter/pull/3
+1
@qdouble any updates on this ?
@kodeine uh, my angular repo has grown and is working very well, but I'm not trying to say anything negative about this repo... my link is here: https://github.com/qdouble/angular2webpack2-starter address any issues there.
+1. AOT very important to increase speed for first start. We have big app on angular2 and we have first init time about 2-3 sec. after 1 sec of loading. 4 seconds is not good for reactive apps. Thanks.
@qdouble I think, you should make more production-ready config for webpack. I mean splitting different environments ti dedicated files. Now your webpack config is unsupportable and not ready to be usen in production.
@vadimzham I disagree, it's a matter of preference I suppose.
@qdouble Dedication configs on production/staging/development environments it's not just preference. It's necessity.
@vadimzham that's really just your opinion. There's no major difference between a production and development config that can't be solved with pushing in a few extra plugins or changing some settings based on variables. It's a design choice.
It would be great if we can incorporate tree shaking into the prod AOT build process as well.
https://angular.io/docs/ts/latest/cookbook/aot-compiler.html#!#tree-shaking
@vadimzham We are already using the webpack starter of @qdouble in production.
Have a look at this sexy & fast website :-) https://secrets.schmid.digital
It uses AoT and is ultra fast. The website is now about 4-5x faster than before! Thanks again to @qdouble . He does awesome work! :)
Check out this webpack starter, if you can't wait longer to use AoT! https://github.com/qdouble/angular-webpack2-starter
@smith64fx yea, i have to use AOT on our website too. But looks like i will use angular-cli to do it. Also now i have problems with with several packages of AOT support. So, i have to wait several days(or fix it by myself).
@vadimzham Yes not every package supports AoT yet.
What i still don't really understand about Angular-cli: Is it a replacement or an extension for webpack? And in the future, what is the way to go?
btw the webpackstarter from @qdouble also uses angular-cli for AoT:
From the package.json file:
"compile:aot": "npm run sass && npm run clean:compile && npm run ngc && npm run build:aot",
@smith64fx angular-cli is webpack-based tool that help you to start clear project. It will have much less code than any of angular2-webpack-starter
or angular-webpack2-starter
projects. Also it will help you generating new components/modules/etc.
It seems there is no plan to support AOT in this repo based on the previous comments, is that true?
@itrethan 🎱 No, it is definitely something to support. I hope to do something on that frontier soon.
@itrethan Have a look at this Branch. I have just adopted a few things. Do a npm run aot && npm run build:aot
and then have npm run server:prod
serve it.
As far as I could do some testing, the best option so far is @ngtools/webpack.
I could make it work without too much effort, and especially without impacting my existing configuration.
@katallaxie Thanks, are you going to merge this with master or just leave the aot part in a separate branch?
@itrethan we will bring it to master, hopefully with ts and dll.
@itrethan Have a look at V6 it is a core version of the starter; fully typescript'd, with aot, and dll support. Though some things to still to work on, unit testing, index.html
production.
@itrethan I still not get why you reference ngc
in npm scripts. It is actually ever used? AFAIK, with @ngtools/webpack you don't need to leverage ngc itself directly.
Am I missing something?
I was thinking the exact same thing, why is this v6 branch not using @ngtools/webpack
@Spittal ngtools/webpack is already there, you can find it in package.json and webpack.config.ts.
What I was pointing out is whether ngc is still relevant, since the npm script "aot" is not called before "build:aot"
@unsafecode yep, its there, but not actually used. When I have time I will add this.
@katallaxie No worries - was just curious to understand whether it was still meaningful, or not.
@unsafecode I was actually not so sure if it is best to use the plugin. Using ngc
makes things more transparent and results in less deps?! I would love to have everything as slim as possible. And (vs6)[https://github.com/AngularClass/angular2-webpack-starter/tree/v6] is what I have in mind for my projects. I think that further down the road it would be best to have the starter and some sort of recipes (so, some modules).
@katallaxie The problem with ngc is it cannot work easily work w/ Sass/Less and pre/post processing steps for HTML templates. AFAIK, it only works if all imported files are already on the filesystem when it runs, which is terribly against what webpack tries to do.
@unsafecode 🎱 then join the force 🛩 and lets get this running.
any progress @katallaxie @unsafecode ?
@kjartanvalur So far, my experimentation has been successful relying on @ngtools/webpack. The repo has been updated with some documentation, but you can find a testing app hidden in their source code here https://github.com/angular/angular-cli/tree/master/tests/e2e/assets/webpack/test-app
Yeah, I'll be honest it seems like we're in a bit of a 'growing pain' area with AOT and Universal. Two things I really want to implement yet there doesn't seem to be a great way to do so without having a HUGE amount of boilerplate. I've been keeping a close eye on this project https://github.com/qdouble/angular-webpack2-starter as it seems very promising.
@kjartanvalur I'm effectively using v6 for production. I do not know what @gdi2290 plans are for further dev
.
@unsafecode we could pull @ngtools/webpack in v6.
@katallaxie That would be ideal for me, I am really interested in merging v6 into my production apps that use postcss to process styles, which currently isn't support by ngc.
There's still a lot of bugs with @ngtools that's why I'm not using it directly in my repo yet: https://github.com/angular/angular-cli/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20aot
compiling and building as separate processes gets around the bugs... I'll switch to ngtools when it's stable
@gdi2290 @Spittal @qdouble @unsafecode working on @ngtools/webpack
. I have pushed some things, more work to do. But help is always welcome.
@katallaxie some game breakers for me are 1) ViewEncapsulation.None or Emulated break the build or cause styles not to import properly: https://github.com/angular/angular-cli/issues/2584
2) Nested types are often not properly resolved It's related to this TS bug https://github.com/Microsoft/TypeScript/issues/9944, however if I use my starter where I compile and build as two different processes, the bug doesn't occur
3) It strips custom decorators: https://github.com/angular/angular-cli/issues/2799
Once those 3 issues are solved, I'll switch over to it, but for now it seems like a bigger hassle to use it rather than just using the scripts to process it as separate tasks.
@qdouble yep, there are some remaining issues. However, can we test v6
and move it, or stop it?!
The view encapsulation thing can be fixed by just using the style-loader and an import statement.
Note: for support questions, please use one of these channels: Chat: AngularClass.slack or Twitter: @AngularClass