Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Ivy -@9.0.0-rc.1 & -@9.0.0-rc.2] `ngcc` fails to compilate NativeScript-Angular package with error: "Error: Error on worker #3: RangeError: Maximum call stack size exceeded" #33734

Closed
VladimirAmiorkov opened this issue Nov 11, 2019 · 19 comments

Comments

@VladimirAmiorkov
Copy link

@VladimirAmiorkov VladimirAmiorkov commented Nov 11, 2019

馃悶 bug report

Affected Package

@nativescript/angular . This is the main package that contains the implementation that allows Angular to run in NativeScript.

Is this a regression?

No, because Ivy is a feature that we want to allow the users of NativeScript to benefit from.

Description

Currently we want to build the @nativescript/angular package with ngc (in order to support View engine) and want to make sure that the package is also correctly processed by ngcc (in order to support Ivy)

馃敩 Minimal Reproduction

As this is yet not merged and release because 9.0.0 is still not available officially. You cna observe the issue in a branch of @nativescript/angular. Here is a show setup:

  • Clone git clone https://github.com/NativeScript/nativescript-angular.git
  • cd nativescript-angular
  • git checkout amiorkov/ivy
  • From the root of the repo execute cd nativescript-angular && npm i && npm run pack (this will build the @nativescript/angular package, make it into a .tgz and place it in a dist directory of the repo)
  • From the root of the repo execute cd nativescript-angular-package && npm i && npm run pack-with-scoped-version /Users/amiorkov/Desktop/Work/nativescript-angular/dist/nativescript-angular-scoped.tgz (this will create the nativescript-angular package that uses the previously build @nativescript/angular package as a dependency. Replace the path to the nativescript-angular-scoped.tgz that is after the npm run pack-with-scoped-version <path-to-scoped-tgz> script)

After this you can proceed with running ngcc in the Test app (e2e/ivy-sample) (cd e2e/ivy-sample/ && npm i && ./node_modules/.bin/ngcc)

Test app

  • From root of repo cd e2e/ivy-sample && npm i && ./node_modules/.bin/ngcc && tns run ios - We would like to use a symlink in this app for the nativescript-angular package. Can we make ngcc work with symlinked packages (the code that ngcc needs to compile is nested in an innter node_modules)

馃敟 Exception or Error



mcsofamiorkov:ivy-sample amiorkov$ ./node_modules/.bin/ngcc
Warning: Entry point '@nativescript/angular' contains deep imports into '/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/tns-core-modules/ui/layouts/layout-base'. This is probably not a problem, but may cause the compilation of entry points to be out of order.
Compiling @nativescript/angular : main as commonjs
Error: Error on worker #3: RangeError: Maximum call stack size exceeded
    at visitNode (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/typescript/lib/typescript.js:17006:23)
    at Object.forEachChild (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/typescript/lib/typescript.js:17139:24)
    at NodeObject.forEachChild (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/typescript/lib/typescript.js:124873:23)
    at CommonJsReflectionHost.Esm2015ReflectionHost.findDecoratedVariableValue (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/host/esm2015_host.js:605:25)
    at /Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/host/esm2015_host.js:605:69
    at visitNodes (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/typescript/lib/typescript.js:17016:30)
    at Object.forEachChild (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/typescript/lib/typescript.js:17140:21)
    at NodeObject.forEachChild (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/typescript/lib/typescript.js:124873:23)
    at CommonJsReflectionHost.Esm2015ReflectionHost.findDecoratedVariableValue (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/host/esm2015_host.js:605:25)
    at /Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/host/esm2015_host.js:605:69
    at ClusterMaster.onWorkerMessage (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/execution/cluster/master.js:158:27)
    at /Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/execution/cluster/master.js:46:95
    at ClusterMaster. (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/execution/cluster/master.js:238:57)
    at step (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/tslib/tslib.js:136:27)
    at Object.next (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/tslib/tslib.js:117:57)
    at /Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/tslib/tslib.js:110:75
    at new Promise ()
    at Object.__awaiter (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/tslib/tslib.js:106:16)
    at EventEmitter. (/Users/amiorkov/Desktop/Work/nativescript-angular/e2e/ivy-sample/node_modules/@angular/compiler-cli/ngcc/src/execution/cluster/master.js:232:32)
    at EventEmitter.emit (events.js:189:13)

馃實 Your Environment

Angular Version:



Angular CLI: 9.0.0-rc.1
Node: 10.15.2
OS: darwin x64
Angular: 9.0.0-rc.1
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.900.0-rc.1 (cli-only)
@angular-devkit/core         9.0.0-rc.1
@angular-devkit/schematics   9.0.0-rc.1 (cli-only)
@ngtools/webpack             9.0.0-rc.1
@schematics/angular          9.0.0-rc.1 (cli-only)
@schematics/update           0.900.0-rc.1 (cli-only)
rxjs                         6.5.3
typescript                   3.6.4
webpack                      4.27.1

Anything else relevant?

@IgorMinar

This comment has been minimized.

Copy link
Member

@IgorMinar IgorMinar commented Nov 11, 2019

We've been working with the nativescript team to ensure compatibility with v9 and Ivy.

I believe that they are releasing a new version of NativeScript that has all the necessary fixes. @alxhub can you confirm please?

@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 11, 2019

Hi @IgorMinar ,

I am part of the NativeScript team and I am working on the integration with Ivy. There have been many issues fixed and with the help of @alxhub we managed to run an Ivy enabled NativeScript app two months ago. But unfortunately the same code base that worked two months ago does not complete with the current next version of Angular. I am facing then issue above when running ngcc over our code base.

JoostK added a commit to JoostK/angular that referenced this issue Nov 12, 2019
When ngtsc comes across a source file during partial evaluation, it
would determine all exported symbols from that module and evaluate their
values greedily. This greedy evaluation strategy introduces unnecessary
work and can fall into infinite recursion when the evaluation result of
an exported expression would circularly depend on the source file. This
would primarily occur in CommonJS code, where the `exports` variable can
be used to refer to an exported variable. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending u
evaluating the `exports` variable again. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending up
evaluating the `exports` variable again. This went on for some time
until all stack frames were exhausted.

This commit introduces a `ResolvedModule` that delays the evaluation of
its exports until they are actually requested. This avoids the circular
dependency when evaluating `exports`, thereby fixing the issue.

Fix angular#33734
JoostK added a commit to JoostK/angular that referenced this issue Nov 12, 2019
When ngtsc comes across a source file during partial evaluation, it
would determine all exported symbols from that module and evaluate their
values greedily. This greedy evaluation strategy introduces unnecessary
work and can fall into infinite recursion when the evaluation result of
an exported expression would circularly depend on the source file. This
would primarily occur in CommonJS code, where the `exports` variable can
be used to refer to an exported variable. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending u
evaluating the `exports` variable again. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending up
evaluating the `exports` variable again. This went on for some time
until all stack frames were exhausted.

This commit introduces a `ResolvedModule` that delays the evaluation of
its exports until they are actually requested. This avoids the circular
dependency when evaluating `exports`, thereby fixing the issue.

Fix angular#33734
@gkalpak

This comment has been minimized.

Copy link
Member

@gkalpak gkalpak commented Nov 15, 2019

@VladimirAmiorkov, I am trying to reproduce this issue (in order to verify whether #33772 fixes it), but I am getting the following error when running npm i inside e2e/-ivy-sample:

ENOENT: no such file or directory, stat '.../nativescript-angular/dist/nativescript-angular-compat.tgz'

Any idea what I might be missing?

Another question:
I noticed that the nativescript-angular-ngcc project in ngcc-validation repo fails with a different error.

Can you explain this difference?
Which sample app should we be looking at?

@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 15, 2019

@gkalpak
You have to build the nativescript-angular package. Do the following:

  • From the root of the repo execute cd nativescript-angular && npm i && npm run pack (this will build the @nativescript/angular package, make it into a .tgz and place it in a dist directory of the repo)
  • From the root of the repo execute cd nativescript-angular-package && npm i && npm run pack-with-scoped-version /Users/amiorkov/Desktop/Work/nativescript-angular/dist/nativescript-angular-scoped.tgz (this will create the nativescript-angular package that uses the previously build @nativescript/angular package as a dependency. Replace the path to the nativescript-angular-scoped.tgz that is after the npm run pack-with-scoped-version <path-to-scoped-tgz> script)

After this you can proceed with running ngcc in the Ivy-sample (cd e2e/ivy-sample/ && ./node_modules/.bin/ngcc)

@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 15, 2019

If you are talking about this errors, I have not seen them before. In my testing I was not able to get that far due to this "Maximum call stack size exceeded" exception. Maybe the ngcc-validation repo is using an internal version of ngcc? I was using the current 9.0.0-rc.1 version.

nativescript-angular-ngcc

Status: e2e failure

stderr: npm WARN lifecycle The node binary used for scripts is /tmp/yarn--1573805358891-0.6385403268618182/node but npm is using /usr/local/bin/node itself. Use the --scripts-prepend-node-path option to include the path for the node binary npm was executed with.

WARNING in /home/circleci/repo/node_modules/@nativescript/core/profiling/profiling.js
Module not found: Error: Can't resolve '~/package.json' in '/home/circleci/repo/node_modules/@nativescript/core/profiling'

ERROR in /home/circleci/repo/node_modules/@nativescript/core/ui/tab-navigation-base/tab-strip/tab-strip.js
Module not found: Error: Can't resolve '../../../color' in '/home/circleci/repo/node_modules/@nativescript/core/ui/tab-navigation-base/tab-strip'
ERROR in /home/circleci/repo/node_modules/@nativescript/core/ui/builder/component-builder/component-builder.js
Module not found: Error: Can't resolve '../../../platform' in '/home/circleci/repo/node_modules/@nativescript/core/ui/builder/component-builder'
ERROR in /home/circleci/repo/node_modules/@nativescript/core/ui/tab-navigation-base/tab-strip-item/tab-strip-item.js

@manughub manughub modified the milestones: v9-candidates, v9-blockers Nov 15, 2019
@gkalpak

This comment has been minimized.

Copy link
Member

@gkalpak gkalpak commented Nov 15, 2019

Thx, I'll give it another try.
(BTW, ngcc-validation uses the latest Angular version from the master branch (with a few hours delay), so it is newer than the latest released version.)

@VladimirAmiorkov VladimirAmiorkov changed the title [Ivy -@9.0.0-rc.1] `ngcc` fails to compilate NativeScript-Angular package with error: "Error: Error on worker #3: RangeError: Maximum call stack size exceeded" [Ivy -@9.0.0-rc.1 & -@9.0.0-rc.2] `ngcc` fails to compilate NativeScript-Angular package with error: "Error: Error on worker #3: RangeError: Maximum call stack size exceeded" Nov 18, 2019
gkalpak added a commit to gkalpak/angular that referenced this issue Nov 18, 2019
When ngtsc comes across a source file during partial evaluation, it
would determine all exported symbols from that module and evaluate their
values greedily. This greedy evaluation strategy introduces unnecessary
work and can fall into infinite recursion when the evaluation result of
an exported expression would circularly depend on the source file. This
would primarily occur in CommonJS code, where the `exports` variable can
be used to refer to an exported variable. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending u
evaluating the `exports` variable again. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending up
evaluating the `exports` variable again. This went on for some time
until all stack frames were exhausted.

This commit introduces a `ResolvedModule` that delays the evaluation of
its exports until they are actually requested. This avoids the circular
dependency when evaluating `exports`, thereby fixing the issue.

Fix angular#33734
@gkalpak

This comment has been minimized.

Copy link
Member

@gkalpak gkalpak commented Nov 18, 2019

I was able to reproduce the problem. I tried with the latest from master with #33772 on top and the error goes away 馃帀
There's another error, though 馃槥

Failed to compile entry-point @nativescript/angular due to compilation errors:
node_modules/@nativescript/angular/common.js(15,27): error TS-991010: Expected array when reading the NgModule.declarations of NativeScriptCommonModule
node_modules/@nativescript/angular/router/router.module.js(59,22): error TS-991010: Expected array when reading the NgModule.exports of NativeScriptRouterModule

Looking into that...

@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 18, 2019

@gkalpak Hmm, I have seen this exact error and from what I remember it was due to ngc not executed on the @nativescript/angular package. Did you execute the old ngc before testing the ngcc ?

@gkalpak

This comment has been minimized.

Copy link
Member

@gkalpak gkalpak commented Nov 18, 2019

I used the instructions from #33734 (comment). At what point should I run ngc?

@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 18, 2019

I see. If the cd nativescript-angular && npm i && npm run pack was successful then the ngc was ran by the prepare script, you can verify that, if there are *. metadata.json files in the @nativescript/angular package than ngc has been done.

Other than that I will have to test this locally and see what can be the cause of this. The error Expected array when reading the NgModule.declarations of NativeScriptCommonModule is not an correct error as since the declarations is an array :(

@gkalpak

This comment has been minimized.

Copy link
Member

@gkalpak gkalpak commented Nov 18, 2019

Yeah, the metadata files are there. In the compiled common.js file, the declarations look like this: declarations: __spreadArrays([dialogs_1.ModalDialogHost], directives_1.NS_DIRECTIVES)

So, it looks like __spreadArrays() is what throws ngcc off. Looks like an ngcc issue. I'll look into it and let you know.

gkalpak added a commit to gkalpak/angular that referenced this issue Nov 19, 2019
When ngtsc comes across a source file during partial evaluation, it
would determine all exported symbols from that module and evaluate their
values greedily. This greedy evaluation strategy introduces unnecessary
work and can fall into infinite recursion when the evaluation result of
an exported expression would circularly depend on the source file. This
would primarily occur in CommonJS code, where the `exports` variable can
be used to refer to an exported variable. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending u
evaluating the `exports` variable again. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending up
evaluating the `exports` variable again. This went on for some time
until all stack frames were exhausted.

This commit introduces a `ResolvedModule` that delays the evaluation of
its exports until they are actually requested. This avoids the circular
dependency when evaluating `exports`, thereby fixing the issue.

Fix angular#33734
@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 20, 2019

@gkalpak ,

Any news on this new issue? Can I be of help?

alxhub added a commit that referenced this issue Nov 20, 2019
When ngtsc comes across a source file during partial evaluation, it
would determine all exported symbols from that module and evaluate their
values greedily. This greedy evaluation strategy introduces unnecessary
work and can fall into infinite recursion when the evaluation result of
an exported expression would circularly depend on the source file. This
would primarily occur in CommonJS code, where the `exports` variable can
be used to refer to an exported variable. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending u
evaluating the `exports` variable again. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the `exports` variable
again. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending up
evaluating the `exports` variable again. This went on for some time
until all stack frames were exhausted.

This commit introduces a `ResolvedModule` that delays the evaluation of
its exports until they are actually requested. This avoids the circular
dependency when evaluating `exports`, thereby fixing the issue.

Fix #33734

PR Close #33772
@alxhub alxhub closed this in b07b6f1 Nov 20, 2019
@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 21, 2019

@alxhub In which version of the RC can we expect this issue to be resolved. Just tested the latest 9.0.0-rc.3 and I still get the same error.

@JoostK

This comment has been minimized.

Copy link
Member

@JoostK JoostK commented Nov 21, 2019

@VladimirAmiorkov it just missed the RC.3, so it is indeed still broken. Next RC will have this fix. I believe @gkalpak is still testing NativeScript and ngcc compatibility.

@gkalpak

This comment has been minimized.

Copy link
Member

@gkalpak gkalpak commented Nov 21, 2019

It turns out that ngcc cannot recognize __spreadArrays(), because the packages are compiled with noEmitHelpers: true (so TypeScript does not emit the implementation of helpers such as __spreadArray()), but also without importHelpers: true (so the helpers are not imported either).
I don't know if you have a custom way to provide the helpers, but ngcc cannot recognize them if they are not imported.

By changing nativescript-angular/tsconfig.json from "noEmitHelpers": true to "importHelpers": true and adding tslib as a dependency in e2e/ivy-sample/package.json, I was able to solve the problem.

Now, there is another problem, where ngcc cannot recognize the following as an array:

exports.FORMS_DIRECTIVES = [
  // Some items...
  ...
];
var NativeScriptFormsModule = /** @class */ (function () {
  function NativeScriptFormsModule() {
  }
  NativeScriptFormsModule = tslib_1.__decorate([
    core_1.NgModule({
      declarations: exports.FORMS_DIRECTIVES,
      ...
    })
  ], NativeScriptFormsModule);
...

So, I am looking into that now.

@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 21, 2019

@gkalpak Thank you for the update. Its a simple patch about the importHelpers so I will handle that in our package. Thank you for all your help and for keeping me in the loop.

@nanselpaul2400

This comment was marked as off-topic.

Copy link

@nanselpaul2400 nanselpaul2400 commented Nov 21, 2019

@gkalpak

This comment has been minimized.

Copy link
Member

@gkalpak gkalpak commented Nov 28, 2019

@VladimirAmiorkov, can you try with the build artifacts from here and see if the app works (assuming you have already switched to importHelpers: true as described in #33734 (comment))?
(I get the app to be processed successfully by ngcc, but I am not sure how to actually build/run it.)

@VladimirAmiorkov

This comment has been minimized.

Copy link
Author

@VladimirAmiorkov VladimirAmiorkov commented Nov 28, 2019

Hi @gkalpak ,

Thank you for all of our efforts and support on this. If the you have managed to run ngcc over the packages of the ivy-sample (which includes nativescript-angular) all should be good for the app to run.

I am tagging @vakrilov to proceed with the Ivy implementation in NativeScript.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can鈥檛 perform that action at this time.