Always Reproducible "Maximum call stack size exceeded" npm install error

I understand, but to be fair the only reason I found that workaround is because I just wouldn’t give up and I was hoping to come up with something that can help the npm team troubleshoot a very long standing issue it would seem (google searches date back a pretty long time on this one). With a reproducible variant of this that happens every time, I thought maybe it would make it on your radar finally so that it can be looked at in more detail.

Don’t get me wrong, I’m not one of those people that is looking to get an issue solved (MY issue at the moment) by a large open source project just because I’m asking for it. I understand the flow of open source projects, the time it takes to even read over issues, triage them, etc, so hopefully you’re not taking what I am saying that way. I’m very grateful for the work you guys and all other open source organizations/teams do because they help me and countless others function and not re-invent the wheel. Merely the fact that we’re having this conversation is already half the battle because I now know you have seen this and its on the radar. Where on the radar that is, I’m not sure, and neither are you, and thats fine. But as long as its somewhere in the pipeline and doesn’t become a giant bug the more people that upgrade node/npm versions then we’ll get around to it at some point.

I just know from my own experience that updating to the latest and greatest causes it, its repeatable, and its a long time outstanding issue so I wanted to give as much input on it as i could and hope that it crosses your mind next time someone asks about it and/or if you’re feeling like taking a deeper dive into it when (IF) you have some free time. I know I can also look over it and submit a PR, that’s definitely something I could do, but my knowledge of the ecosystem as a whole is obviously not as good as yours and it would take me substantially longer to even understand where to begin :)

1 Like

Hi Matt! I’ve tried twice and was unable to reproduce that error (node8.11.3 / npm6.4.0). I do see warnings about peerDependencies, but nothing fails. I selected “Yes” to instal peerDeps, but not the “employee only” option.

$ ./node_modules/.bin/ace -- setup
[07:09:49] Working directory changed to ~/dev/tmp/ace/node_modules/@spothero/ace/config
[07:09:56] Using gulpfile ~/dev/tmp/ace/node_modules/@spothero/ace/config/gulp
[07:09:56] Starting 'setup'...
[07:09:56] Starting 'updatePackageScripts'...
[07:09:56] Finished 'updatePackageScripts' after 5.81 ms
[07:09:56] Starting 'installPeerDeps'...
? Also install peerDependencies? (Required when starting a new project with ACE) Yes
[07:10:05] Starting 'confirmInstallPeerDeps'...
npm WARN deprecated react-dom@16.2.0: This version of react-dom/server contains a minor vulnerability. Please update react-dom to 16.2.1 or 16.4.2+. Learn more:
npm WARN @spothero/ace@3.3.2 requires a peer of @spothero/core@1.2.0 but none is installed. You must install peer dependencies yourself.
npm WARN @spothero/ace@3.3.2 requires a peer of @spothero/ui@5.5.1 but none is installed. You must install peer dependencies yourself.
npm WARN ace@1.0.0 No description
npm WARN ace@1.0.0 No repository field.

+ babel-polyfill@6.26.0
+ core-js@2.5.7
+ prop-types@15.6.2
+ react@16.2.0
+ react-dom@16.2.0
added 6 packages from 2 contributors and audited 28951 packages in 52.879s
found 0 vulnerabilities

[07:10:59] Finished 'confirmInstallPeerDeps' after 54 s
[07:10:59] Finished 'installPeerDeps' after 1.03 min
[07:10:59] Starting 'scaffoldConfigs'...
? Scaffold ACE config files in /config directory? (you can do this later by calling `npm start -- scaffoldConfigs`) Yes
[07:11:07] Starting 'confirmScaffoldConfigs'...
[07:11:08] Update `settings.js` for project settings and `tasks.js` for Gulp tasks.
[07:11:08] Finished 'confirmScaffoldConfigs' after 23 ms
[07:11:08] Finished 'scaffoldConfigs' after 8.2 s
[07:11:08] Starting 'scaffoldProject'...
? Scaffold default ACE project files? (you can do this later by calling `npm start -- scaffoldProject`) Standard
[07:11:13] Starting 'confirmScaffoldProject'...
[07:11:13] Make sure to run `npm start -- installPeerDeps` before development if you didn't install `peerDependencies` yet.
[07:11:13] Run `npm start` to begin development.
[07:11:13] Finished 'confirmScaffoldProject' after 49 ms
[07:11:13] Finished 'scaffoldProject' after 5.15 s
[07:11:13] Finished 'setup' after 1.27 min

Platform Info

$ npm --versions
{ ace: '1.0.0',
  npm: '6.4.0',
  ares: '1.10.1-DEV',
  cldr: '32.0',
  http_parser: '2.8.0',
  icu: '60.1',
  modules: '57',
  napi: '3',
  nghttp2: '1.32.0',
  node: '8.11.3',
  openssl: '1.0.2o',
  tz: '2017c',
  unicode: '10.0',
  uv: '1.19.1',
  v8: '6.2.414.54',
  zlib: '1.2.11' }

$ node -p process.platform

I know this isn’t incredibly useful, but it’s another data point I guess. I’ll try on node10 and see what happens.

1 Like

Hey Brian,
Thanks for trying it out. I could have sworn I wrote in the original post that it was on node 10.9 and npm 6.2 but looking back all I did was post my platform info. This actually all works fine for me on 10.3/6.1 but someone upgraded to the 10.9/6.2 setup which prompted me to do so as well and we were all getting the error on that. Somewhere between 10.3 and 10.9 is where its always reproducible but I know for a fact on the combo of 10.9/6.2 it is (I think I also tried on 10.8 at some point but can’t completely recall).

1 Like

Hey no problem. Your platform info had everything I needed, including the version. Thanks for the descriptive steps to reproduce.

I thought I’d try it with what I normally use to see if I could reproduce it. Since it didn’t I’ll take a look at trying with the latest of each. It looks like 10.9 and 6.4.x are the latest, so I will give that a shot when I get a sec.

1 Like

Hey Brian,
Just wanted to check in and see if you had a chance to run this with the specified versions? Thanks again for looking at it.

1 Like

@reintroducing, this error happened to me as well.
I checked the npm logs and I saw that it was failing at install @xtuc/long
I found this solution

Its likely that you have to remove your ~/.npmrc file.

I tried this and it solved the issue for me.

Hope this helps!

Thanks Alex, but my .npmrc file has nothing more than the following:


I’ve encountered the same “Maximum call stack size exceeded” error. What I’ve narrowed it down to in my npmrc file is the “_auth” flag. If I comment it out, the install works. If I uncomment it, the error occurs. I’ve tried testing with other settings in there, but that’s the only one that makes the difference from what I’ve seen.

Any updates on this issue?

None from my end and it does not seem like its a priority for the npm team, unfortunately.

I’ll try to take a look at it this weekend, it’s a bit annoying that you probably need to actually install most of those dependencies to reproduce it properly. I don’t know how big the Node.js call stack limit is, but what might be happening is that the dependency tree is too big and installing lodash etc. dedupes part of the tree so the depth works again. Not at all sure though.

@reintroducing Can you post the full error message (mainly the call stack)? There are a number of other posts with the same error but different causes, it would be helpful to link them together. Also, if you happen to find an easier/more minimal way to reproduce it, that’s always welcome.

I also ran into this issue trying to complete the rust wasm tutorial with npm. Here’s the stack overflow question.

1 Like

The issue is happening for me. I tried everything in a fully clean folder, no parent folders containing node_modules or package[-lock].json anywhere… After an uninstall and reinstall of node, npm, etc.

The resolution was to upgrade my version of Git tools. (was on 2.19, now on 2.20).

I run this too, only on centos and ubuntu, see

build log:

failure on centos:
work on debian:

1 Like

I believe it is connected to dependencies to git. Please see

1 Like

Same issue suddenly - I do not have any .npmrc file, I updated git (to 2.21.0) and npm (6.9.0) - Help!

1 Like

Just signed up to tell you this: Been there, done that. This mainly happened with create-react-app, and any React project I started.I spent days trying to fix it.
Finally had to switch to yarn. And later, better still, pnpm. Problem solved.

I’ve been able to consistently reproduce this simply by running “npm install webpack@4.30.0” or most any version of webpack and having an _auth field in my npmrc. (I ran an npm cache clean --force as well.) See attached log for details of output - 2019-07-05T20_11_51_830Z-debug.log (10.8 KB)
The _auth setting results in the basic authorization header being used, causing a 404, and then an infinite loop of failedDependency being called within deps.js.
Testing with Postman to do some request calls against the npm registry, I’ve noticed that @xtuc/long and @mapbox/geojson-types get 404’s when using basic authorization, but requests to other packages don’t. And taking out the basic authorization of course works fine in all cases.
Any idea how/why there are differences when basic auth is used on those requests?


I have the exact same issue @atdiff is having.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.