No apparent way to use `--bundle-dependencies=all` successfully since 1.5.0

[SteveSandersonMS]

Prior to the 1.5.0 release, it was possible to pass --bundle-dependencies=all --prod to get an AoT compiled self-contained bundle that worked for server-side rendering (SSR) under Node.js. Since 1.5.0, these flags produce a bundle that, as far as I can tell, can never work because they now rely on the existence of browser DOM APIs that don't exist in Node.

If there is any way to use --bundle-dependencies=all successfully in --prod build with 1.5.0+, I'd love to know about it.

Versions

Angular CLI: 1.5.4
Node: 6.11.0
OS: win32 x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, platform-server, router

@angular/cli: 1.5.4
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.21
@angular-devkit/schematics: 0.0.37
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.4
@schematics/angular: 0.1.7
typescript: 2.4.2
webpack: 3.8.1

Repro steps

• Clone the example repo at https://github.com/SteveSandersonMS/angular-bundledependencies-repro. This is the same as the universal-starter repo, except for one commit that gets as close as I can to a scenario where --bundle-dependencies=all could work (but still doesn't).
• Run npm install
• Observe that it works fine in a non-prod build by running npm run build:ssr then npm run serve:ssr. If you visit http://localhost:4000, you'll get both server and client rendering.
• Observe that if you build in prod mode (run npm run build:ssr:prod then npm run serve:ssr), then it does not work - you'll get this error:

TypeError: StaticInjectorError[InjectionToken DocumentToken]: 
  StaticInjectorError[InjectionToken DocumentToken]: 
    Right-hand side of 'instanceof' is not an object
    at ke (C:\path\angular-bundledependencies-repro\dist\server.js:4106:724114)
    at xe (C:\path\angular-bundledependencies-repro\dist\server.js:4106:723991)
    at lr (C:\path\angular-bundledependencies-repro\dist\server.js:4106:746752)
    at _n.insertToken (C:\path\angular-bundledependencies-repro\dist\server.js:4106:767718)
    at C:\path\angular-bundledependencies-repro\dist\server.js:4106:726646
    at Fe (C:\path\angular-bundledependencies-repro\dist\server.js:4106:726661)
    at I (C:\path\angular-bundledependencies-repro\dist\server.js:4106:721959)
    at Object.parse (C:\path\angular-bundledependencies-repro\dist\server.js:4106:766648)
    at Object.t.createDocument (C:\path\angular-bundledependencies-repro\dist\server.js:4106:1194422)
    at Object.t.createWindow (C:\path\angular-bundledependencies-repro\dist\server.js:4106:1194526)

If you trace this into the server.js bundle code, what's happening is that it's testing whether someValue instanceof HTMLElement (though it's not obvious at first glance because everything is minified and renamed). That code would be OK in a browser, but it's an error in Node, because HTMLElement is undefined. So the generated bundle isn't going to work for SSR under Node.

• If you want, verify that removing --bundle-dependencies=all from lines 22 and 23 in package.json is enough to make it work in both dev and prod builds. So the problem is the combination of --prod with --bundle-dependencies=all - you can use either on their own, but not both together.

Observed behavior

Fails with the Right-hand side of 'instanceof' is not an object error shown above.

Desired behavior

SSR works as it did in the non-prod build.

Mention any other details that might be useful (optional)

The equivalent did work pre-1.5.0 (which was also Angular 4.x).

The reason I'm asking about this is because I'm building new Angular CLI-based ASP.NET templates that will be included in the .NET Core SDK and Visual Studio. We want the template to use --bundle-dependencies=all by default because then developers don't have to publish their node_modules to production, and attempting to publish 20,000+ files from node_modules is extremely time-consuming (and not always reliable) from VS. Plus it tends to hit Windows path-length limitations depending on the deployment target.

[naveedahmed1]

@filipesilva any thoughts on this?

[filipesilva]

@Brocco can you take a look please?

[naveedahmed1]

@Brocco did you get a chance to look into this?

[asadsahi]

Really love to have this nailed down. Thanks guys.

[naveedahmed1]

@hansl is it due to the issue reported here #8900 ?

[naveedahmed1]

Ok I think the issue is with the uglifyjs plugin. It seems that angular cli is using --mangle and --compress option with this plugin for server bundles and its causing the issue.

To confirm this, I first build bundle using below command:

ng build --app=ssr --output-hashing=media --aot --bundle-dependencies=all

Then I used uglifyjs using below command

uglifyjs main.bundle.js --output output.js

(main.bundle.js is the server bundle generated in 1st command)

the bundle generated after above command worked perfectly.

Then I tried generating a bundle with --compress and --mangle

uglifyjs main.bundle.js --output output.js --compress --mangle

when I used this bundle it threw the error @SteveSandersonMS mentioned above.

An unhandled exception has occurred: StaticInjectorError[InjectionToken Application Initializer -> InjectionToken DocumentToken]: 
  StaticInjectorError(Platform: core)[InjectionToken Application Initializer -> InjectionToken DocumentToken]: 
    Right-hand side of 'instanceof' is not an object
      TypeError: StaticInjectorError[InjectionToken Application Initializer -> InjectionToken DocumentToken]: 
 

[naveedahmed1]

@filipesilva can you please share if there is any update on this?

[naveedahmed1]

@hansl should we expect this and #8900 to be solved in V6?
If this could be fixed, it would really help developers using Angular and SSR with Windows technologies (.net core) or hosting Angular apps on Windows servers/IIS/Kestrel.

[asadsahi]

Personally I would love to have this feature available as soon as possible, but for now I have stopped wasting time and effort on making angular apps universal.
Right now the stability of angular universal is good for demo purposes but as soon as you start expanding application to a good scale you start realising the amount of energy required to maintain those features is quite large. I hope in coming days DX will improve to implement SSR in angular apps and it will be easier like angular cli has done good job developing/building angular apps.