angular: platform-server errors with ivy-ngcc - UMD module - Angular 9.0.0-rc.7
π bug report
Affected Package
The issue is caused by package @angular/platform-server
Is this a regression?
Yes, the previous version in which this bug was not present was: @angular/platform-server@9.0.0-rc.6
Description
When trying to compile my application with Ivy, I get errors on ivy ngcc for platform-server when compiling for umd bundles (for SSR)
π¬ Minimal Reproduction
Update any project to latest version of Angular (9.0.0-rc.7).
Add following config to angular.json
:
"server": {
"builder": "@angular-devkit/build-angular:server",
"options": {
"outputPath": "dist-server",
"main": "src/main.server.ts",
"tsConfig": "src/tsconfig.server.json"
},
"configurations": {
"production": {
"optimization": true,
"outputHashing": "media",
"sourceMap": false,
"namedChunks": false,
"extractLicenses": true,
"vendorChunk": false,
"bundleDependencies": "all",
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
}
]
}
}
}
Then run command:
ng run MyProject:server:production
π₯ Exception or Error
Compiling @angular/platform-server : main as umd
Hash: f0b9625353a4d2f5af81
Time: 12116ms
Built at: 12/23/2019 8:02:36 PM
Asset Size Chunks Chunk Names
main.js 1.75 KiB 0 main
Entrypoint main = main.js
chunk {0} main.js (main) 28 bytes [entry] [rendered]
ERROR in Expected UMD module file (/node_modules/url/node_modules/punycode/punycode.js) to contain exactly one statement, but found [object Object],[object Object].
π Your Environment
Angular Version:
Angular CLI: 9.0.0-rc.7
Node: 12.13.1
OS: win32 x64
Angular: 9.0.0-rc.7
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router, service-worker
Ivy Workspace: Yes
Package Version
--------------------------------------------------------------------
@angular-devkit/architect 0.900.0-rc.7
@angular-devkit/build-angular 0.900.0-rc.7
@angular-devkit/build-optimizer 0.900.0-rc.7
@angular-devkit/build-webpack 0.900.0-rc.7
@angular-devkit/core 9.0.0-rc.7
@angular-devkit/schematics 9.0.0-rc.7
@angular/cdk 9.0.0-rc.5
@angular/fire 5.2.1
@angular/google-maps 9.0.0-rc.5
@angular/material 9.0.0-rc.5
@angular/pwa 0.900.0-rc.7
@ngtools/webpack 9.0.0-rc.7
@nguniversal/module-map-ngfactory-loader 9.0.0-next.9
@schematics/angular 9.0.0-rc.7
@schematics/update 0.900.0-rc.7
rxjs 6.5.3
typescript 3.6.4
webpack 4.41.2
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 27 (21 by maintainers)
Commits related to this issue
- fix(ngcc): do not collect private declarations from external packages Previously, while trying to build an `NgccReflectionHost`'s `privateDtsDeclarationMap`, `computePrivateDtsDeclarationMap()` would... — committed to gkalpak/angular by gkalpak 4 years ago
- fix(ngcc): do not collect private declarations from external packages Previously, while trying to build an `NgccReflectionHost`'s `privateDtsDeclarationMap`, `computePrivateDtsDeclarationMap()` would... — committed to gkalpak/angular by gkalpak 4 years ago
- fix(ngcc): do not collect private declarations from external packages Previously, while trying to build an `NgccReflectionHost`'s `privateDtsDeclarationMap`, `computePrivateDtsDeclarationMap()` would... — committed to gkalpak/angular by gkalpak 4 years ago
- fix(ngcc): do not collect private declarations from external packages (#34811) Previously, while trying to build an `NgccReflectionHost`'s `privateDtsDeclarationMap`, `computePrivateDtsDeclarationMap... — committed to angular/angular by gkalpak 4 years ago
- fix(ngcc): do not collect private declarations from external packages (#34811) Previously, while trying to build an `NgccReflectionHost`'s `privateDtsDeclarationMap`, `computePrivateDtsDeclarationMap... — committed to sonukapoor/angular by gkalpak 4 years ago
Issue not solved with
Angular 9.0.0-rc.9
.Yes, the fix is included in v9.0.0-rc.11.
Thank you so much @petebacondarwin π
@gkalpak yes the backend is in .Net and thatβs a separate repo. I tested it on my side and I can confirm that the issue has been resolved on runtime as well. Thank you so much for the quick fix π
Looking forward to have it in next release.
Iβm still having this issue with latest
Angular 9.0.0-rc.8
.No, the fix hasnβt landed yet. This is the PR (which is still open): #34811
This is your problem @naveedahmed1 :
Notice that the URL refers to
compiler-cli
.You can find instructions on how to use them here. Basically, you just replace the versions in your package.json to point to the artifacts URL.
I have done that already and the error goes away. But I want to verify that everything still works as expected at runtime and I am not sure how to do that for your app.
It seems that this issue is caused by the recent changes related to UMD bundles in Angular 9.0.0-rc.7
https://github.com/angular/angular/pull/34356
https://github.com/angular/angular/commit/84a7d8a
https://github.com/angular/angular/commit/c26738d
Can confirm also experiencing this issue only from Angular 9.0.0-rc.7, did not exist in Angular 9.0.0-rc.6
Thx, @naveedahmed1. I took a look and there are actually two issues involved:
@angular/platform-server
imports Node.jsβ built-inurl
module here.ngcc
fails to recognize that this is the Node.js built-in and tries to processurl
package (which is a transitive dependency of the project and ends up in top-levelnode_modules/
via npm deduping).The
url
package dependes on thepunycode
package, whose main file is in the form;(function(root) { ... }(this));
(which is neither CommonJS nor UMD).ngcc
assumes that the file pointed to by apackage.json
βsmain
property will be in either CommonJS or UMD format. Given thatpunycode.js
does not look like CommonJS,ngcc
tries to parse it as UMD and it expects UMD files to be in format(function (factory) { ... })(function (...) { ... });
(and thus only have one top-level statement). However, the file has two top-level statements (one empty statement, followed by a parenthesized function call):;(function(root) { ... }(this));
Having 100% static evaluation for the UMD format is probably out of scope for
ngcc
(as it would be quite complex/costly with all the different variations), so we have to rely on heuristics (which canβt be 100% accurate). Off the top of my head, here are some things we can improve:ngcc
to ignore Node.js built-in modules as dependencies.package.json > main
points to either CommonJS or UMD. Improve our detection of the formatmain
files and throw a more descriptive error for unsupported formats.@gkalpak I have added you to a private repo and dropped you an email.