angular-cli: Error in SSR if server build with `bundleDependencies=all`
Bug Report or Feature Request (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request
Command (mark with an x)
- [ ] new
- [ ] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [x] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
Versions
Angular CLI: 6.2.1 Node: 8.11.2 OS: darwin x64 Angular: 6.1.7 … animations, common, compiler, compiler-cli, core, forms … http, language-service, platform-browser … platform-browser-dynamic, platform-server, router … service-worker
Package Version
@angular-devkit/architect 0.8.1 @angular-devkit/build-angular 0.8.1 @angular-devkit/build-ng-packagr 0.8.1 @angular-devkit/build-optimizer 0.8.1 @angular-devkit/build-webpack 0.8.1 @angular-devkit/core 0.8.1 @angular-devkit/schematics 0.8.1 @angular/cdk 6.4.7 @angular/cli 6.2.1 @angular/flex-layout 6.0.0-beta.18 @angular/material 6.4.7 @angular/pwa 0.8.1 @ngtools/json-schema 1.1.0 @ngtools/webpack 6.2.1 @schematics/angular 0.8.1 @schematics/update 0.8.1 ng-packagr 4.1.1 rxjs 6.3.2 typescript 2.9.2 webpack 4.18.0
Repro steps
I use universal-starter, only change one line in angular.json:
"server": {
"configurations": {
"production": {
"bundleDependencies": "all", <= added
...
$ git clone -b issue-error-with-bundleDependencies git@github.com:clarkorz/universal-starter.git
$ cd universal-starter
$ yarn install
$ yarn build:ssr
$ yarn serve:ssr
Access http://localhost:4000 in browser.
The log given by the failure
Error: No NgModule metadata found for '[object Object]'.
at NgModuleResolver.resolve (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@angular/compiler/bundles/compiler.umd.js:11962:27)
at CompileMetadataResolver.getNgModuleMetadata (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@angular/compiler/bundles/compiler.umd.js:10604:47)
at JitCompiler._loadModules (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@angular/compiler/bundles/compiler.umd.js:23914:55)
at JitCompiler._compileModuleAndComponents (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@angular/compiler/bundles/compiler.umd.js:23895:40)
at JitCompiler.compileModuleAsync (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@angular/compiler/bundles/compiler.umd.js:23855:41)
at CompilerImpl.compileModuleAsync (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@angular/platform-browser-dynamic/bundles/platform-browser-dynamic.umd.js:195:35)
at /Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@nguniversal/express-engine/bundles/express-engine.umd.js:95:25
at new ZoneAwarePromise (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/zone.js/dist/zone-node.js:891:29)
at getFactory (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@nguniversal/express-engine/bundles/express-engine.umd.js:81:12)
at View.engine (/Users/wangshuo/Documents/GitHub/universal-starter/node_modules/@nguniversal/express-engine/bundles/express-engine.umd.js:60:13)
Desired functionality
bundleDependencies=all should work as same as bundleDependencies=none.
Mention any other details that might be useful
No.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 5
- Comments: 19 (7 by maintainers)
@ErazerBrecht - We think we have a solution for version 8.0.
On it (again). Investigating the root cause.
We were ending up with two copies of Angular due to the bundling setup we have for express-engine. We think we finally have a solution(See PR above) and turning on bundleDependencies on by default for version 8.0 of @nguniversal/express-engine. Still end up with a dist/server.js and dist/server/main.js (and dist/server/*.js for dynamic import based lazy routes) - But that’s still lot better than shipping entire node_modules.
Have a repro. First need to figure out why JitCompiler is getting involved at all since we pass in the NgFactory to the express engine.
@vikerman Any update on this issue or workaround? I’m running into it with latest Angular CLI and this seems to be a hard blocker atm.
@vikerman @MarkPieszak, would you have a look?