Anyone run into RangeEr…
Anyone run into RangeError: Maximum call stack size exceeded when running build --with-deps? I have no buildable libraries but it still happens even if i make a buildable library and include it.
Responses:
Only happens on one of angular projects in my repo. I am assuming there is a circular dep somewhere just not sure where that would be causing it.
Update: Happens on any app beyond an essentially empty shell with a couple of routes.
```/node_modules/@nrwl/workspace/src/core/project-graph/project-graph-builder.js:25 addDependency(type, sourceProjectName, targetProjectName) { ^
RangeError: Maximum call stack size exceeded```
Nx 9.5.1 Angular devkit: 0.901.10
If I log the node that it is centered around a single one of my services CookieService I have started stripping out Imports to see if I can track down what is happening but this is all that is output
/node_modules/.bin/nx build --with-deps
static cookie-service npm:@angular/core
static cookie-service npm:@angular/common
static cookie-service npm:jest-preset-angular
static cookie-service npm:@angular/core
static cookie-service npm:@angular/common
static cookie-service npm:jest-preset-angular
which repeats until max call stack
The imports in CookieService
import { Injectable, Injector } from '@angular/core';
import { tzOffset } from './cookies';
./cookies just has 5 constants in it with strings assigned to them, no imports.
I can build the dep graph with affected:dep-graph though without issues.
On another app that does not use cookie-service the same thing happens (the outputs from the log above are different though).
Hey Jay, maybe this helps, changing the ng script in package.json to this
node --max_old_space_size=16384 ./node_modules/.bin/ng
You probably don’t need 16GB, 2 or 4 might be sufficient. It shows the level of my frustration when I was facing issues :grin:
I’ll give that a try thanks. Usually I try that when I get an out of memory error. Never tried it with a max call stack error
Oh - wait, I might be confused
My error seems to be being caused because there is an infinite loop that recurs itself.
I think Maximum call stack size exceeded can also be caused by some error in your routing. For instance, lazy loading a module that does not have any routes
Not sure memory will help that
More memory might postpone the error :wink:
So it also happens when i try and build an Nest app with --with-deps
Opened an issue here: https://github.com/nrwl/nx/issues/3271
This is most definitely a circular import somewhere. It took us a long time to find our bad apples (it was in multiple places)
How were you able to track it down? When I serve and build it doesn’t say anything about circular imports.
Not sure if this applies to your setup, but we hit this error and spent forever trying to debug it. Turned out that NX considers items imported to spec files as dependencies even when that dependency is not shipped with the component.
contrived example:
ButtonModule (depends on IconModule)
IconModule (icon spec file imports the published ButtonModule)
Even though the shipped code only has a dependency in a single direction, NX seems to consider this a circular dependency. NgPackagr did not have any issues with this when used directly.
I think that might be it just because when I started console logging things in the nx package that was building the DEP graph, some of the nodes were printing jest-present-angular which isn’t a dep of the library code. I am sure I have a million circular deps if that’s the case.
I feel like the Nx package should handle that when building with deps and ignore deps of spec files?
Yep, we ended up just moving all our specs out to a top level directory. Not my preferred structure in Angular, but it worked!
Oh god. I don’t think that’s going to work for us. Maybe I’ll take a look and see if I can track down the Dep graph stuff and see if I can ignore spec files when determining what to build.
bringing you in on this, is on the right track here with how nx might be handling circular imports when building –with-deps?
I know we don’t do anything special with spec files
We go through every file and find the imports
Ok that’s what I thought. I’m assuming that is the issue I’m running into then. When building the DEP graph (in the case of building) there is no need to look at spec files right? I think that is a safe assumption since otherwise I would need to go through every spec file we have and fix the imports even though it’s not a problem when doing everything but building with deps, let me know if I’m off base here.
K small update, if I purposely create a circular dependency in one of my spec files (import the module in the module.spec using the alias) in an app that was not erroring before and then build with –with-deps it does not error, builds with deps correctly. So it isn’t a single circular import doing it.
K small update, if I purposely create a circular dependency in one of my spec files (import the module in the module.spec using the alias) in an app that was not erroring before and then build with –with-deps it does not error, builds with deps correctly. So it isn’t a single circular import doing it.
I am able to reliably recreate it now. Will provide a repo in the github issue
updated issue with a repo demonstrating it
Found a package that helps track down circular deps, apparently I have 27 that do not show up when building or serving. So I am going to try and remove those and see what happens
Wow :flushed: that’s quite a bit. You have a link to the package?
It is called madge! if you google madge npm its the first this
madge --circular --extensions ts --ts-config tsconfig.json .
thats the command i ran
Thanks, I’ll take a look in some projects of mine