Angular-cli: AOT seems to be enabled by default in beta.22 ?

Created on 3 Dec 2016  路  57Comments  路  Source: angular/angular-cli

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.

medium (days) investigation 2 (required) bufix
Source
picture ritz078
👍9

Most helpful comment

@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 ! :)

picture maxime1992 on 7 Dec 2016
👍13 ❤4

All 57 comments

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

kucharzyk picture kucharzyk on 3 Dec 2016

This has already been reported in #3354.

sgybas picture sgybas on 3 Dec 2016
👍1

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

aaronleeucla picture aaronleeucla on 5 Dec 2016

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

hansl picture hansl on 5 Dec 2016

@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 picture hansl on 5 Dec 2016
👎6

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

hansl picture hansl on 6 Dec 2016
👎13 👍4 😕1

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

the-destro picture the-destro on 6 Dec 2016
👍3

@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) ?

maxime1992 picture maxime1992 on 6 Dec 2016
👍8

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

montella1507 picture montella1507 on 6 Dec 2016
👍2

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.

kylecordes picture kylecordes on 6 Dec 2016
👎14 👍1

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.

montella1507 picture montella1507 on 6 Dec 2016

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

klinki picture klinki on 6 Dec 2016
👍16

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

kylecordes picture kylecordes on 6 Dec 2016
👍1

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.

deebloo picture deebloo on 6 Dec 2016

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.

montella1507 picture montella1507 on 6 Dec 2016

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.

bonnici picture bonnici on 7 Dec 2016
👍6

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.

tomwanzek picture tomwanzek on 7 Dec 2016
👍5

@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 ! :)

maxime1992 picture maxime1992 on 7 Dec 2016
👍13 ❤4

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

deebloo picture deebloo on 7 Dec 2016

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 picture the-destro on 7 Dec 2016

@aaronleeucla Are those stats pre-gzipped?

It is expected to go up in size (since AoT is actually compiling the HTML templates into JavaScript code, which is bigger), but the gzipped version of the files should be smaller, since there's a lot of repetition of the code.

hansl picture hansl on 7 Dec 2016
👍1

I'm currently fixing #2799, will come back later this week and definitely be in the next release.

hansl picture hansl on 7 Dec 2016
🎉8 ❤3

@hansl No, those stats are production gzipped. Main/vendor decrease in size, but chunks definitely increase. For my current app at no network throttling, AoT does improve loading and rendering time. But at scale, with an app with a large set of eager and/or lazy loaded HTML, the gains of AoT could very well be offset by the increased loading time of pre-compiled HTML, especially over slow networks.

aaronleeucla picture aaronleeucla on 7 Dec 2016

@montella1507 to fix, in general, you need to have declarations: false set in the tsconfig. @hansl unless you already know why it seems to be ignoring the tsconfig settings, I'll open a separate issue and try and track it down tonight.

the-destro picture the-destro on 7 Dec 2016
👍1

If I have to use angular 2.3.0 --> angular-cl 1.0.0-beta.21 and awesome-typescript-loader 3.0.0-beta.10 combinations works for me. 

{
  "name": "test",
  "version": "0.1.0",
  "license": "MIT",
  "angular-cli": {},
  "scripts": {
    "start": "ng serve",
    "lint": "tslint \"src/**/*.ts\"",
    "test": "ng test",
    "pree2e": "webdriver-manager update",
    "e2e": "protractor"
  },
  "private": true,
  "dependencies": {
    "@angular/common": "2.3.0",
    "@angular/compiler": "2.3.0",
    "@angular/core": "2.3.0",
    "@angular/forms": "2.3.0",
    "@angular/http": "2.3.0",
    "@angular/platform-browser": "2.3.0",
    "@angular/platform-browser-dynamic": "2.3.0",
    "@angular/router": "3.3.0",
    "@ng-bootstrap/ng-bootstrap": "1.0.0-alpha.14",
    "@ngrx/core": "1.2.0",
    "@ngrx/db": "2.0.1",
    "@ngrx/effects": "2.0.0",
    "@ngrx/router-store": "1.2.5",
    "@ngrx/store": "2.2.1",
    "@ngrx/store-devtools": "3.2.2",
    "angular-in-memory-web-api": "0.1.17",
    "angular2-jwt": "0.1.26",
    "angular2-moment": "1.0.0",
    "bootstrap": "4.0.0-alpha.5",
    "core-js": "2.4.1",
    "font-awesome": "4.7.0",
    "ng2-toasty": "2.1.0",
    "rxjs": "5.0.0-rc.5",
    "ts-helpers": "1.1.2",
    "web3": "0.17.0-beta",
    "zone.js": "0.7.2"
  },
  "devDependencies": {
    "@angular/compiler-cli": "2.3.0",
    "@types/bignumber.js": "co-mmons/types-bignumber.js",
    "@types/jasmine": "2.5.38",
    "@types/node": "6.0.51",
    "@types/web3": "cashila/web3-typed",
    "angular-cli": "1.0.0-beta.21",
    "codelyzer": "2.0.0-beta.3",
    "jasmine-core": "2.5.2",
    "jasmine-spec-reporter": "2.7.0",
    "karma": "1.3.0",
    "karma-chrome-launcher": "2.0.0",
    "karma-cli": "1.0.1",
    "karma-jasmine": "1.1.0",
    "karma-remap-istanbul": "0.2.1",
    "protractor": "4.0.13",
    "ts-node": "1.7.2",
    "tslint": "4.0.2",
    "typescript": "2.1.4",
    "webdriver-manager": "10.2.10"
  },
  "optionalDependencies": {
    "awesome-typescript-loader": "3.0.0-beta.10"
  }
}
xmlking picture xmlking on 11 Dec 2016

is the reason build .22 is so bad because it uses AOT?
I did try --aot false and still it hangs at 20% when running ng serve
hope we can get a new build soon
regards

born2net picture born2net on 12 Dec 2016
👍1

Try 'ng build' to see some details why it's hanging. But disabling --aot didn't work for me

tonimoeckel picture tonimoeckel on 12 Dec 2016

had same results with ng build

born2net picture born2net on 12 Dec 2016

@born2net what were the results of your build? It still hung or...

the-destro picture the-destro on 12 Dec 2016 
root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studioDashboard
$ ng build
 10% building modules 3/3 modules 0 activeError encountered resolving symbol values statically. Reference to a local (non-exported) symbol 'providing'. Consider exporting the symbol (position 135:5 in the original .ts file), resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts
Error: Error encountered resolving symbol values statically. Reference to a local (non-exported) symbol 'providing'. Consider exporting the symbol (position 135:5 in the original .ts file), resolving symbol AppModule in C:/msweb/studioDashboard/src/app/app.module.ts
    at positionalError (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:595:18)
    at simplifyInContext (C:\msweb\studioDashboard\node_modules\@angular\compiler-cli\src\static_reflector.js:473:27)
    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
$

let me remind that all is perfect in .21 and I wish to continue and run in JIT, as I have no interest in AOT at this point,

and same output on: ng build --aot false
regards

born2net picture born2net on 12 Dec 2016
👍1

@xmlking When I update to 2.3.0 and "awesome-typescript-loader": "3.0.0-beta.10"
image
https://github.com/angular/angular-cli/issues/3529

kolkov picture kolkov on 12 Dec 2016

for reference, error is coming from:
https://github.com/born2net/studioDashboard/blob/master/src/app/app.module.ts

born2net picture born2net on 12 Dec 2016

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

the-destro picture the-destro on 13 Dec 2016

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

hansl picture hansl on 13 Dec 2016
👍1

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\studioDashboardnode_modules\@angular\compiler-cli\src\static_reflector.js:475:23)
at StaticReflector.simplify (C:\msweb\studioDashboardnode_modules\@angular\compiler-cli\src\static_reflector.js:478:22)
at StaticReflector.annotations (C:\msweb\studioDashboardnode_modules\@angular\compiler-cli\src\static_reflector.js:60:36)
at AotPlugin.getNgModuleMetadata (C:\msweb\studioDashboardnode_modules\@ngtools\webpack\src\plugin.js:330:41)
at AotPlugin._processNgModule (C:\msweb\studioDashboardnode_modules\@ngtools\webpack\src\plugin.js:271:42)
at C:\msweb\studioDashboardnode_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\studioDashboardnode_modules\@angular\compiler-cli\src\reflector_host.js:173:23)
at C:\msweb\studioDashboardnode_modules\@angular\compiler-cli\src\codegen.js:137:46
at Array.forEach (native)
at extractProgramSymbols (C:\msweb\studioDashboardnode_modules\@angular\compiler-cli\src\codegen.js:120:10)
at CodeGenerator.codegen (C:\msweb\studioDashboardnode_modules\@angular\compiler-cli\src\codegen.js:57:29)
at C:\msweb\studioDashboardnode_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.

born2net picture born2net on 13 Dec 2016

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

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

 provide: AppStore, useFactory: appStoreFactory
bonnici picture bonnici on 13 Dec 2016

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)
born2net picture born2net on 13 Dec 2016

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.

hccampos picture hccampos on 13 Dec 2016
👍3

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.
https://github.com/angular/angular-cli/issues/3529#issuecomment-266737336

kolkov picture kolkov on 13 Dec 2016

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

sampath-karupakula picture sampath-karupakula on 14 Dec 2016

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

born2net picture born2net on 14 Dec 2016
👍1

still open on beta.23?

andrelmp picture andrelmp on 16 Dec 2016

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

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

kucharzyk picture kucharzyk on 16 Dec 2016

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

montella1507 picture montella1507 on 17 Dec 2016
👍2

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

antonybudianto7 picture antonybudianto7 on 19 Dec 2016
👍1

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

montella1507 picture montella1507 on 19 Dec 2016

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

jponeill picture jponeill on 23 Dec 2016
👍7

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.

rosslavery picture rosslavery on 3 Jan 2017

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

hansl picture hansl on 3 Jan 2017
👍5

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.

born2net picture born2net on 3 Jan 2017

@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

deebloo picture deebloo on 3 Jan 2017

@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

born2net picture born2net on 3 Jan 2017

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

pauleveritt picture pauleveritt on 4 Jan 2017

I can confirm forRoot does not work...

born2net picture born2net on 4 Jan 2017
👍3

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

yarrgh picture yarrgh on 6 Jan 2017
👎2 👍1

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

hansl picture hansl on 16 Mar 2017
👎5

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

angular-automatic-lock-bot[bot] picture angular-automatic-lock-bot[bot] on 6 Sep 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

daBishMan picture daBishMan  路  3Comments
jmurphzyo picture jmurphzyo  路  3Comments
brtnshrdr picture brtnshrdr  路  3Comments
hareeshav picture hareeshav  路  3Comments
gotschmarcel picture gotschmarcel  路  3Comments