AOT seems to be enabled by default in beta.22 ?

[ritz078]

Please provide us with the following information:

OS?

Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

El Capitan

Versions.

Please run ng --version. If there's nothing outputted, please run in a Terminal: node --version and paste the result here:

angular-cli: 1.0.0-beta.22
node: 6.6.0
os: darwin x64

Repro steps.

Was this an app that wasn't created using the CLI? What change did you do on your code? etc.

run ng serve

The log given by the failure.

Normally this include a stack trace and some more information.

10% building modules 2/2 modules 0 active(node:14509) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Error encountered resolving symbol values statically. Function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AppModule in /Users/ritz078/projects/housing-assist/src/app/app.module.ts, resolving symbol AppModule in /Users/ritz078/projects/housing-assist/src/app/a 20% building modules 86/86 modules 

Mention any other details that might be useful.

---

Thanks! We'll be in touch soon.

[kucharzyk]

It looks like aot is enabled by default but I'cant even disable it.

[sgybas]

This has already been reported in #3354.

[aaronleestic]

These are the approximately gzipped production payload for my application:

CLI beta 21/Angular 2.2.1 without AoT. main.bundle: 260kb, 0.chunk: 20kb...
CLI beta 21/Angular 2.2.1 with AoT. main.bundle: 200kb, 0.chunk: 50kb...
CLI beta 22/Angular 2.2.3 AoT only. main.bundle. 70kb, vendor 130kb. 0.chunk: 50kb...

Basically with AoT, the main/vendor bundle reduced by about 20%, but all the other lazy/pre-loaded chunks increased, some by more than 100%. I compared the chunk's source and found that with AoT, the size increase seem to came from very many pre-compiled html js code, such as

this._text_50 = this.renderer.createText(this._el_49, "Some html text", null), this._text_51 = this.renderer.createText(this._el_47, "\n ", null), this._text_52 = this.renderer.createText(this._el_45, "\n ", null), this._text_53 = this.renderer.createText(this._el_43, "\n ", null), this._text_54 = this.renderer.createText(this._el_0, "\n", null),

where this._el_123 reference a renderer of an html tag. These "\n" code lines basically matches the closing HTML tag. Without AoT, these code would be replaced with plain HTML developers code up.

Is this expected? Are there any work in progress to reduce the pre-compiled code size? Due to this increase, it may not be worth it in certain situation to turn on AoT. Not sure if this should be a CLI issue or an Angular2 framework issue. If so, please advise...

[hansl]

I deleted a comment that was obviously against the code of conduct.

[hansl]

@ritz078 we don't enable AoT by default, BUT we do generate lazy bundles. The code that analyze your project for lazy routes still uses static analysis to figure out your lazy routes. We had "faulty" code before that was working which we might revert too; it was dumber but in this case it would fix it.

[hansl]

We changed the way we analyze lazy routes in the CLI; you now have to use statically analyzable code. This is more solid and also takes into account libraries that include routes and lazy routes. It also means the code needs to be AoT-compatible, even though you're not using AoT to compile it.

The problem here seems to be that you either:

1. are using function calls that are not "simple" enough for the static analyzer to understand, or
2. are using a library that doesn't include metadata.json files. This can be figured out by remove libraries and seeing if the code compiles.

For point 1, you should not use function calls or non-const values in metadata. Metadata is supposed to be static and easily parseable.

For point 2, we (the Angular Team) offer best practice guides for library developers to follow, in order to be AoT compatible. Libraries should follow those best practices. If you are (or know) the library author, this page explains how to be AoT compatible for a library: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html

[the-destro]

It seems that the user experience(in my case ng serve stalling) is not ideal. Also, it seems that ng serve/build is ignore my tsconfig and using declaration: true as I am seeing a lot of these type errors after upgrading to the latest beta: exported variable 'reducers' has or is using name 'Action' from external module

[maxime1992]

@hansl I'm not sure to understand, but if we use a non compatible AOT library, we won't be able to use angular-cli (except < beta 22) ?

[montella1507]

@maxime1992 seems so. + there are several new problems like using non-reexported types as return type of methods in exported class...

@the-destro yeah.. with beta.22 i have 1000 errors like this regarding rxjs... and now i dont know how to fix those errors.. do you?

IM so afraid, that this change - you need every library to be AOT compatible, will brake the neck of Angular 2.....

[kylecordes]

Although it is momentarily inconvenient, I think it is a very positive development to see CLI requiring that code and libraries have the bits necessary to work with AOT. This should result in a better sense of urgency among application and library authors to become compatible with AOT.

In the long run, I think this would be even better: for Angular itself to be modified a bit such that JIT imposes as close as possible to the same requirements as AOT.

[montella1507]

this will lead to the end of angular, because authors of 3rd party libraries wont invest their time to modify code and build it with ngc.

[klinki]

@kylecordes I loved that I could use some older javascript libraries - for example jQuery jsTree, some color picker and so on.. and write simple wrapper for Angular 2. There are lost of non-angular libraries which are really great and up to this moment could be used (with some wrappers) with angular. Now if you cut them out, you end up with just bunch of Angular 2 libraries with very varying quality.

I don't think it is a good idea.

Right now no one is forcing me to use AOT, so I will avoid it as long as possible. But I'm also losing benefits of it - just because you decided to make this huge breaking change in beta.22.

[kylecordes]

@klinki What I described would only affect Angular specific reusable libraries. It would not affect jQuery or any of zillions of other reusable chunks of code which don't have any Angular specific annotations / components / etc. in them. I'm not on the Angular team so I am not among the "you" who put in this change :-) but I think a couple of the messages here overstate the impact. The current situation is basically an accident of history, that the requirements for Angular code compatible with AOT are different than the requirements for angular code compatible with JIT. I suspect in a few more versions we will all have long forgotten that, the requirements will have been brought close enough that JIT is no big deal, routinely use, as the Angular team has had in mind for a long time. It's a big complicated thing, takes a while to accomplish the full vision.

[deebloo]

I agree with @kylecords. This won't affect non angular libs and now anything built with the cli will be AOT compliant. I do see that it is causing some pain but I believe it to be a net good.

[montella1507]

I am not even able to build several Anuglar 2 starter packs, because of errors like:

exported variable 'xyz' has or is using name 'Subject' from external module rxjs

which is built-in in angular 2. Thats the thing,.. so i wont talk here about 100 libraries which you have mentioned on your main page angular.io like PrimeNG,, Kendo,.. that ARE NOT ready for AOT.

[bonnici]

I think it's much more than just momentarily inconvenient. As Angular-CLI devs we will now have to audit every open source component we bring in and ensure that they are AoT-friendly before we can use them, even if we have no interest in making an AoT app. In my experience there will be many components that will never be updated so we'll just have to skip them and try to find something else. I don't think it's the "end of angular" but it's definitely a huge hassle.

[tomwanzek]

My immediate concern is that #2799 is still open, i.e. the interaction between AOT compilation and custom decorators critical to state management/side-effects solutions in two material libraries is not yet resolved.

For the first time in the beta cycle, I have held off on upgrading, i.e. from beta.21 to beta.22, as it is not self-evident to me whether said issue is exacerbated with the latest release.

So, if someone could shed some light on this particular aspect, I should be most indebted.

[maxime1992]

@deebloo

I do see that it is causing some pain but I believe it to be a net good.

For sure, idealy if everything was AOT compliant it would be nice awesome.
But it sounds impossible to have every project AOT compliant. As a developer willing to give the best for my users, I'm ready to make my code AOT compliant. But some devs out here won't do that. Especially 3rd party libs. This brings me to that question :

This won't affect non angular libs

How so ? This is really something I don't understand.
What are the boundaries of AOT ?
Is only our code required to be AOT compliant or also the libs we use ?

Last thing is, as @tomwanzek said, there's a huge concern of introducing the obligation to have our code AOT compliant when #2799 is still opened : Custom decorators are stripped off.
I tried to launch my app yesterday after making it fully AOT compliant, and as I use @ngrx/effects my app was displaying well ... But nothing was happening as most of the work is launched from effect.

I've been sticking with angular-cli since the beginning, even tho there are great starters out there that support AOT, lazy loading, hmr, etc for months.

But I really like the idea behind angular-cli : Having a similar code base for every repo and making a tool common to every devs so it's easier to work on another project.

I loved the decision and (huge) work done when switching from systemjs to webpack. But this time, it feels like this is a big decision with a deep impact on the community (+ existing projects) and we didn't see that coming.

Could it be possible to have an issue opened to discuss that kind of update, even before the work gets started ? I don't know if asking community opinion for big changes is something common in open source world, but it'd probably be great and constructive ! :)

[deebloo]

@maxime1992 totally agree that it is odd to have this change in before having a fix for #2799. when I said it won't affect non angular libs I mean to say that if you are using jquery, moment, or something like that AOT doesn't affect it.

[the-destro]

I think having it enabled by default but able to be disabled should be the mantra going forward with some of these big "flag" type changes. Also, enforcing AOT compliance only makes sense to me if Angular itself did not support JIT. Perhaps they will with Angular 3 that will be the case. If it is, then this seems be best left for a 2.0 version of the cli.

[the-destro]

@born2net does the error go away with ng build --aot=true ? Also, have you tried exporting those vars and seeing if it can build?

[hansl]

@born2net not relevant to this issue, but you need to export var providing. You simply declare it right now.

[born2net]

I can only assume a lot more people are going to face issues as they will start moving to .22.
So I went ahead and changed it to '''export var providing = ...'''
I also changed my providing to lambda from arrow function

export var providing = [CommBroker, AUTH_PROVIDERS,
    {
        provide: AppStore, useFactory: function() {
        const reducers = combineReducers({
            notify,
            appdb,
            business,
            stations,
            reseller,
            adnet,
            orders
        });
        const middlewareEnhancer = applyMiddleware(<any>thunkMiddleware);
        const isDebug = window['devToolsExtension']
        // const applyDevTools = () => isDebug ? window['devToolsExtension']() : f => f;
        // const enhancers: any = compose(middlewareEnhancer, applyDevTools());
        const enhancers: any = compose(middlewareEnhancer);
        const store = createStore(reducers, enhancers);
        return new AppStore(store);
    }, deps: []
    },
    ...

and here are the issues now.
tried both aot true / false

root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studioDashboard
$ ng build --aot false
 10% building modules 3/3 modules 0 activeError encountered resolving symbol values statically. Function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts
Error: Error encountered resolving symbol values statically. Function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts
    at simplifyInContext (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:475:23)
    at StaticReflector.simplify (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:478:22)
    at StaticReflector.annotations (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:60:36)
    at AotPlugin.getNgModuleMetadata (C:\msweb\studioDashboard\node_modules\@ngtools\webpack\src\plugin.js:330:41)
    at AotPlugin._processNgModule (C:\msweb\studioDashboard\node_modules\@ngtools\webpack\src\plugin.js:271:42)
    at C:\msweb\studioDashboard\node_modules\@ngtools\webpack\src\plugin.js:242:39
    at process._tickCallback (internal/process/next_tick.js:103:7)

root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studioDashboard
$

root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studioDashboard
$

root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studioDashboard
$

root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studioDashboard
$ ng build --aot true
 10% building modules 3/3 modules 0 activecan't resolve module C:/msweb/studioDashboard/src/appdb/NotifyReducer.ts from C:/msweb/studioDashboard/src/appdb/NotifyReducer.ts
can't find symbol notify exported from module C:/msweb/studioDashboard/src/appdb/NotifyReducer.ts
Error: can't find symbol notify exported from module C:/msweb/studioDashboard/src/appdb/NotifyReducer.ts
    at ReflectorHost.findDeclaration (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\reflector_host.js:173:23)
    at C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\codegen.js:137:46
    at Array.forEach (native)
    at extractProgramSymbols (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\codegen.js:120:10)
    at CodeGenerator.codegen (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\codegen.js:57:29)
    at C:\msweb\studioDashboard\node_modules\@ngtools\webpack\src\plugin.js:210:73
    at process._tickCallback (internal/process/next_tick.js:103:7)

root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studioDashboard
$

I am not even thinking AOT at this point as I am sure many things I do are not going to be compatible with AOT, for example I used private in components for members which are accessed from the template, I know these need to be public, as one example.

So really I just want to get JIT working with .22 so I can finally use --hmr which I have been waiting for, for sooo long...

but no go.

@hansl if you have a chance it would be awesome if you could use my project as a test bed for .22
(should only take few minutes to install)

git clone https://github.com/born2net/studioDashboard.git
studioDashboard
npm i
ng build --aot false

and if you can get it working with .22, I'd buy u a beer :) (works great in .21 so I can't imagine it would be so difficult in .22)

tx as always,

Sean.

[bonnici]

@born2net extract your factory into an exported function. e.g. something like

export function appStoreFactory() {
        const reducers = etc;
}

 provide: AppStore, useFactory: appStoreFactory

[born2net]

tx for the reply so went ahead and converted to:

export function appStoreFactory() {
    const reducers = combineReducers({
        notify,
        appdb,
        business,
        stations,
        reseller,
        adnet,
        orders
    });
    const middlewareEnhancer = applyMiddleware(<any>thunkMiddleware);
    // const isDebug = window['devToolsExtension']
    // const applyDevTools = () => isDebug ? window['devToolsExtension']() : f => f;
    // const enhancers: any = compose(middlewareEnhancer, applyDevTools());
    const enhancers: any = compose(middlewareEnhancer);
    const store = createStore(reducers, enhancers);
    return new AppStore(store);
}
   

issue persists:

$ ng build
 10% building modules 3/3 modules 0 activeError encountered resolving symbol values statically. Function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts
Error: Error encountered resolving symbol values statically. Function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts, resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts
    at simplifyInContext (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:475:23)
    at StaticReflector.simplify (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:478:22)
    at StaticReflector.annotations (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:60:36)
    at AotPlugin.getNgModuleMetadata (C:\msweb\studioDashboard\node_modules\@ngtools\webpack\src\plugin.js:330:41)
    at AotPlugin._processNgModule (C:\msweb\studioDashboard\node_modules\@ngtools\webpack\src\plugin.js:271:42)
    at C:\msweb\studioDashboard\node_modules\@ngtools\webpack\src\plugin.js:242:39
    at process._tickCallback (internal/process/next_tick.js:103:7)

[hccampos]

Getting the same kind of stuff here. There should really be a way to disable the AoT plugin and just use awesome-typescript-loader or ts-loader.

[kolkov]

I have found what causes this problem in my case:
If I understand correctly, they filter out the character ! from path, but ! is legal character in Windows path.
#3529 (comment)

[sampath-karupakula]

I am also facing similar issues, How can I downgrade to the angular-cli.

[born2net]

npm install [email protected]
and
npm install [email protected] -g
just stay on .21 until the team fixes it!

[andrelmp]

still open on beta.23?

[kucharzyk]

It looks like beta.23 is not yet published to npm.

I'll check if this works when new version will be avabile

[montella1507]

@kucharzyk yeah.. i tried to installl latest version via NPM install Git../tarball/master but i have got tons of errors, so this is propably not the correct way.. so we have to wait :-( i am waiting for that because ngrx/effects are greta, but they use decorators, and they are stripped down in current CLI versions.

[antonybudianto7]

looks like this is affecting hmr usage too, now it does full reload on lazy-loaded components...

[montella1507]

@hansl have you already noticed problems with HMR on 22-1 and lazy routes ? or shall i create an issues with minimal repo?

[jponeill]

Adding the static analysis/AoT related issue(s) to the "breaking changes" section in the changelog would probably save some people trouble.

[rosslavery]

To be clear -- is this a bug as far as the team is concerned, or is this how the cli will be compiling from beta 22 onward?

That is to say:

• An angular-cli project (and all of it's dependencies) must be AoT ready, even if the developer has no desire to use AoT compilation
• The --aot flag now controls whether the project will be precompiled, but will not disable the checks for AoT-compliance

I'd like to upgrade because of the speed improvements that have been made, but my project relies on some 3rd party libs that aren't AoT-ready.

[hansl]

@rosslavery Pretty much. We're always looking for feedback, and we are really aware of the vacuum right now for developing AOT-compatible libraries.

Give us the libraries that are not AOT compliant and we can contact them. We have a great developer relations team that can help those libraries move onto supporting AOT (every library developer I've met wants to, they just often don't know how or it isn't clear).

[born2net]

AFAIK the issues are beyond just AOT, as just running static methods forRoot is causing issues.
and for what its worth, I believe we should continue and support --aot false as some projects I am working on have already been released and rely on CLI.

[deebloo]

@born2net the issue that a lot of libs that have a forRoot method are having is that somewhere in that forRoot method they are doing something that isn't statically analyzable.

Not saying I don't agree, just pointing out the issue is not calling static methods on modules

[born2net]

@deebloo that's what I thought, but I double checked and mine is failing even if my forRoot does nothing at all... I opened a bug and provided access to project to @hansl but no status yet
regards

[pauleveritt]

material2 has a forRoot (and is currently buggy and cumbersome for AoT).

[born2net]

I can confirm forRoot does not work...

[trevor-hackett]

I can confirm that forRoot does work. Been using it in my lib and it works with no issues.

[hansl]

Closing this as obsolete. We've been enforcing static analysis since Beta 22 now.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}