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

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.

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

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.

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!

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/cli@1.2.x in JIT.