Angular-cli: JIT mode only: Uncaught Error: Unexpected value imported by the module 'AppModule'. Please add a annotation.

Created on 17 Aug 2017  路  27Comments  路  Source: angular/angular-cli

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

@angular/cli: 1.3.0
node: 6.11.0
npm: 5.3.0
os: darwin x64
@angular/animations: 4.3.5
@angular/common: 4.3.5
@angular/compiler: 4.3.5
@angular/core: 4.3.5
@angular/forms: 4.3.5
@angular/http: 4.3.5
@angular/platform-browser: 4.3.5
@angular/platform-browser-dynamic: 4.3.5
@angular/router: 4.3.5
@angular/cli: 1.3.0
@angular/compiler-cli: 4.3.5
@angular/language-service: 4.3.5

Repro steps.

Repository https://github.com/ng-select/ng-select

git clone [email protected]:ng-select/ng-select.git
cd ng-select
npm install
npm run build // should output dist folder
cd integration
npm install // should install @ng-select/ng-select from dist folder
ng serve // will file at runtime
ng serve --prod // works fine

The log given by the failure.

Uncaught Error: Unexpected value 'NgSelectModule' imported by the module 'AppModule'. Please add a @NgModule annotation.
    at syntaxError (compiler.es5.js:1690)
    at compiler.es5.js:15382
    at Array.forEach (<anonymous>)
    at CompileMetadataResolver.webpackJsonp.../../../compiler/@angular/compiler.es5.js.CompileMetadataResolver.getNgModuleMetadata (compiler.es5.js:15365)
    at JitCompiler.webpackJsonp.../../../compiler/@angular/compiler.es5.js.JitCompiler._loadModules (compiler.es5.js:26795)
    at JitCompiler.webpackJsonp.../../../compiler/@angular/compiler.es5.js.JitCompiler._compileModuleAndComponents (compiler.es5.js:26768)
    at JitCompiler.webpackJsonp.../../../compiler/@angular/compiler.es5.js.JitCompiler.compileModuleAsync (compiler.es5.js:26697)
    at PlatformRef_.webpackJsonp.../../../core/@angular/core.es5.js.PlatformRef_._bootstrapModuleWithZone (core.es5.js:4536)
    at PlatformRef_.webpackJsonp.../../../core/@angular/core.es5.js.PlatformRef_.bootstrapModule (core.es5.js:4522)
    at Object.../../../../../src/main.ts (main.ts:11)

Desired functionality.

I expect to serve linked local library without any errors as it works with -aot mode.

Mention any other details that might be useful.

I get this error only then I'm installig local library from dist folder and only with JIT mode. In package.json I have added "@ng-select/ng-select": "../dist/"

It works perfectly fine if I install library from npm repository. I tried to add paths to tsconfig as described here https://github.com/angular/angular-cli/wiki/stories-linked-library but it doesn't work for me. I would be very helpful if somebody can look at this issue, I thought something may be wrong with my code somewhere but I suppose everything should work fine in JIT mode if it is working in AOT mode :)

2 (required) broken

Most helpful comment

A lot of these _solutions_ are hacks which seem unpractical, especially when it comes to maintainability. A core/shared library is that way because it holds system critical functionality. I much rather not get used to deleting angular/core folders out of a (or many) library(ies).

I have been trying to follow yeoman's library seed to properly build a lib (which looks somewhat similar to what @filipesilva is building) as the way to go (to take out my inexperience). But I still run into these issues as described above. It is quite frustrating.

Obviously there are many more out there that have abstracted core code into a lib. A good solution, or a fix, would be welcome. It obviously has to do with the fact that two @angular/* modules are included and therefore the app loads neither (or something like that).

Yes, I could just use 1.2.7 until there is a _"golden standard"_. But it would also be good to know that this is being addressed (or shown that we are all doing it wrong). So far there is no comment on this thread.

Thanks for building such an awesome tool though. It has helped a ton and is really amazing! I also understand that there are priorities (this may not be one). I don't want to sound ungrateful.

All 27 comments

I have the same issue over here and already mentioned it in another issue that seemed related.

It works in 1.2.7, but not in any of the 1.3.x versions (incl. the rc) and neither in the 1.4.0-beta0.

I installed cli 1.2.7 as @ebtc mentioned but I'm still getting the same error.

Output from ng serve

Your global Angular CLI version (1.3.0) is greater than your local
version (1.2.7). The local Angular CLI version is used.

To disable this warning use "ng set --global warnings.versionMismatch=false".
** NG Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200 **

Same issue with JIT (build works but fails at runtime). AOT works fine.
I am using lerna to link my library with my app.

Used to work with:

  • @angular/* 4.2.3
  • @angular/cli: 1.1.2

But once upgraded to the following versions, it started to fail:

  • @angular/* 4.3.5

    • @angular/cli: 1.3.0

Unexpected value '[object Object]' imported by the module 'AppModule'. Please add a @NgModule annotation.

update: Its working with angular-cli 1.2.7

Same error here when symlinking / npm-linking an external module from ng-cli 1.3.x. Fixing @angular-cli to ~1.2.0 instead of ^1.2.0 fixes the problem.

A simple reproduction of this issue is available at bgotink/angular-cli-symlink-reproduction

As already mentioned above:

  • this works fine in 1.2.x but not 1.3.x or 1.4.0-beta.1
  • this works fine in AOT but not in JIT

@anjmao I think you're missing the paths in the compilerOptions. If I modify integration/tsconfig.json in your repository to match

{
  // ...
  "compilerOptions": {
    // ...
    "baseUrl": "",
    "paths": {
      "@angular/*": ["../node_modules/@angular/*"]
    }
  }
}

it works with @angular/[email protected] in JIT.

Thanks @bgotink, after adding paths it started to work in JIT mode on @angular/[email protected]

@hansl did an update to the way paths get read: d1d2aa0ccf646bf377916272b5a28b251bd4c41f. Has anyone gotten his modules to work with this? Any other solutions?
@filipesilva ... or this is unrelated to the original issue that brought d1d2aa0ccf646bf377916272b5a28b251bd4c41f about?

After digging through issues, I just figured this one : https://github.com/angular/angular-cli/issues/7137
As mentioned, I added --preserve-symlink to my ng serve command and I could successfully run my app with my external module symlinked !

Just wondering if there was a fix for this issue coming up, or if there was a decision in the correct pattern to follow when developing angular libraries?

I'm currently on cli 1.4.2, and I'm having the same issue when using npm link to devlop angular libraries, and I have tried the following things

  • Standard workflow using JIT (as mentioned above, it worked great in 1.2.x, but stopped working in 1.3.x)

    • Browser error: Unexpected value '[object Object]' imported by the module

  • Using preserve symlink ng serve --preserve-symlink

    • The file watcher in my app no longer detects changes in the linked library and I have to manually kick off a new build

  • Using AOT ng serve --aot

    • This seems to work, but is this the "proper" way to do this?

I would really appreciate any feedback/guidance. Thanks for all the hard work in building a killer CLI!

@dbfannin I've been struggling with this as well, my comments in this issue report might help.

In short, avoid having node_modules present in the library when you link.

@matthewhegarty, thanks for link! I've been using (basically) that same method for the past month or so, thinking it would just be a stopgap solution until this "bug" was fixed. Unfortunately, I've found it to be really inconvenient to develop this way, especially in an architecture that relies heavily on shared modules.

For anyone else feeling this pain, I've just been enabling AOT when serving up my application (ng serve --aot). This seems to be a good solution so far. Definitely much better than deleting/moving node_modules/@angular/core every time I need to link my library.

I came across this whilst looking into this issue. I think this is related but a different issue. If it helps, I've included some steps to reproduce.

The issue occurs if you create a local path to a package, but have a separate dependency
which bundles its own @angular/core.

In the example below, the 'angular-datatables' library bundles @angular/core, and removing just that directory from application's node_modules fixes the issue.

Attachments

  1. A demo library (adapted from ng2-datatable-bootstrap4) ng2-datatable-bootstrap4.tar.gz

  2. An angular-cli generated Application npm-link-issue-test.tar.gz

  3. My console log localhost-1505919376015.log.gz

Steps to reproduce

mkdir npm-issue && cd npm-issue

# download files
wget https://github.com/angular/angular-cli/files/1318152/ng2-datatable-bootstrap4.tar.gz
wget https://github.com/angular/angular-cli/files/1318151/npm-link-issue-test.tar.gz

# unpack tars
tar xzf ng2-datatable-bootstrap4.tar.gz
tar xzf npm-link-issue-test.tar.gz

# install dependencies
cd ng2-datatable-bootstrap4
npm install

# Create dist
npm run build


cd ../npm-link-issue-test/
npm install

# add local dependency
npm install ../ng2-datatable-bootstrap4/dist

ng serve

# browse to http://localhost:4200 and the error appears in the console

Workaround

# list all the dependencies which bundle their own '@angular/core'
find node_modules -name 'core' -type d

# Remove the 'core' directory from the dependencies listed above.
rm -rf node_modules/angular-datatables/node_modules/@angular/core

# then restart `ng serve`

A lot of these _solutions_ are hacks which seem unpractical, especially when it comes to maintainability. A core/shared library is that way because it holds system critical functionality. I much rather not get used to deleting angular/core folders out of a (or many) library(ies).

I have been trying to follow yeoman's library seed to properly build a lib (which looks somewhat similar to what @filipesilva is building) as the way to go (to take out my inexperience). But I still run into these issues as described above. It is quite frustrating.

Obviously there are many more out there that have abstracted core code into a lib. A good solution, or a fix, would be welcome. It obviously has to do with the fact that two @angular/* modules are included and therefore the app loads neither (or something like that).

Yes, I could just use 1.2.7 until there is a _"golden standard"_. But it would also be good to know that this is being addressed (or shown that we are all doing it wrong). So far there is no comment on this thread.

Thanks for building such an awesome tool though. It has helped a ton and is really amazing! I also understand that there are priorities (this may not be one). I don't want to sound ungrateful.

We have also chosen for linking our generic codebase and I totally agree with @axtho that it would be really nice if this works again. I'll stay for now on 1.2.7 I guess, or use aot mode, but it seems like many people have quite a big problem now. Especially because we felt comfortable when all >1.0.0 releases supported this strategy till 1.3.0. CLI self also still provides the documentation on how to use linked modules, but this probably is out of date. I think it can lead people to falsy solutions if this is not addressed, again agree with @axtho. I use CLI from it's beta days and it solved many of our problems, it's an amazing tool and I hope we get someone's explanation on the plans for this.

Ah, I just found that in v1.5.0-beta.2 --preserve-symlink works for us in JIT mode. So the combination of tssconfig "paths": { "@angular/": [ "../node_modules/@angular/"]} and this flag on ng serve solves the problem for us.

@ubarevicius so do all versions > 1.2.7 with --preserve-symlinks

https://github.com/angular/angular-cli/issues/7409#issuecomment-325183227

Ah man, need to pay more attention when reading the comments :) thx

So just for the record: I got it all to work with the latest beta (maybe that is even not necessary). I can confirm the --preserve-symlinks and the "paths": {...} inclusion works.
Maybe it helps someone: I figured out my issue was (in the end) that I included too many things in the "paths" object (I was including also non-angular packages, like ngrx, which the lib and the app share).

For those still struggling, here is my working setup: note here that the "paths" object goes to the tsconfig of the app which consumes the linked lib (something I was not totally aware of). Check out the core setup with the two tsconfig files (something the yeoman generator did, and which seems to work well).

Maybe this will help someone save some time.

Even I'am facing the same issue when tried using 'MatSnackBar'.
This is my error: Unexpected value 'MatSnackBar' imported by the module 'AppModule'. Please add a @NgModule annotation.
Here's the link

Same as @akash-potdar7. I can load plenty of other MatModule's, but Unexpected value 'MatSnackBar' imported by the module 'AppModule'. Please add a @NgModule annotation. at syntaxError (webpack-internal:///../../../compiler/esm5/compiler.js:684)

edit: I messed up the import somehow. It works now. Double check your app.module.ts guys

I had the same problem with a linked lib for angular 5 and this worked for me: https://stackoverflow.com/a/47445313/1438483

@amivit

I got the same error
_Unexpected value 'MatSnackBar' imported by the module 'AppModule'. Please add a @NgModule annotation. at syntaxError (webpack-internal:///../../../compiler/esm5/compiler.js:684)_

Just added

MatSnackBarModule

in the app module and MatSnackBar in the component the error resolved..

screen shot 2017-12-30 at 9 40 32 pm
As of 12-30-17 , MatSnackBar is still being advertised on the material.angular site https://material.angular.io/components/snack-bar/overview
Not the correct MatSnackBarModule, I wonder why?

"compiler.js:15975 Uncaught Error: Unexpected value 'AngularFireDatabase' imported by the module 'AppModule'. Please add a @NgModule annotation."
I got this error when I trying to save data in firebase real-time database using the AngularFirebaseDatabase module.

Are you still able to reproduce this issue?

Closing the issue due to inactivity. If the problem still exists in the latest version of the CLI, please open a new issue following the template and providing a minimal demo where we can reproduce it. Thanks! :-)

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

Was this page helpful?
0 / 5 - 0 ratings