npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

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

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

@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!

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

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.

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

Anybody? :\

If you search Google this seems to be a common problem with no real solid solution because its not always easily reproducible. With this, its reproducible every time so I figured it’d be a good way for someone on the npm team to troubleshoot it once and for all.

It’s been triaged. I’m not entirely sure what’s going on, but, specially since there’s a workaround, this isn’t going to be super high priority for me to fix. PRs are welcome, if you find the time, though! (or if someone else does <3)

I have the exact same issue @atdiff is having.

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 :)

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.

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).

Thanks Kat, I missed that. However, there is no workaround, and anything I’ve tried that did work in prior npm/node versions does not work on 10.9/6.2. I guess if you are saying that the weirdness of having to install random packages is the workaround then sure, but is that really even a viable workaround? :)

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.

Any updates on this issue?

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.

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?

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.

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.

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

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


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).

That’s what workarounds are. You do something silly, and then get on with your day. :slight_smile: I’m more concerned about people who simply can’t get their work done at all, even if they change things, due to some bug beyond their control, hence what I said.

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

build log:

failure on centos:
work on debian:

What I Wanted to Do

I’ve written a CLI (similar to create-react-app) that takes care of some React project boilerplate for you. Part of the setup process is an npm install of peerDependencies. When you do this during setup, the install fails with the dreaded npm ERR! Maximum call stack size exceeded which I’ve googled for hours with random work arounds working for some and not others and sometimes reproducible and sometimes not.

My expectation is that the npm install of the peer deps would work and the setup would finish.

What Happened Instead

Every time I run the setup process of the CLI from scratch it fails on the peer dependencies install step.

Reproduction Steps

Here is the CLI with details on how to get up and running (just a few steps):

If you run that in a clean directory and say “Yes” to install peer deps setup step you will get the error. The offending step is this command: npm install -S babel-polyfill@6.26.0 core-js@2.5.7 prop-types@15.6.2 react@16.2.0 react-dom@16.2.0. Running that manually after the setup fails produces the same error.

I thought maybe version numbers were wonky so i tried to strip them out running this next: npm install -S babel-polyfill core-js prop-types react react-dom. Result: also fails.

So then I try just npm i lodash. Also fails.

For fun I run this next: npm install -S lodash request chalk express async and it succeeds!

I re-run the original offending command again: npm install -S babel-polyfill@6.26.0 core-js@2.5.7 prop-types@15.6.2 react@16.2.0 react-dom@16.2.0 and it succeeds!

For fun, I re-run the setup step for the CLI: ./node_modules/.bin/ace -- setup and say “Yes” to install peer deps again. everything works as expected and I’m able to get through the setup process just fine.


If you want to repeat this every time, clear out all the files from the project directory and leave just the package.json file. Run through the setup steps again starting with the install step (npm install @spothero/ace -D). Then run the setup again ./node_modules/.bin/ace -- setup and you’re back in the vicious cycle stated above in the reproduction steps section. (better yet, right after this setup step fails, run just npm i lodash and it fails too).

Its not until I run the npm install -S lodash request chalk express async command that everything starts to work again. I have no clue why that is but hopefully it helps you guys with troubleshooting this (some of those packages are not even part of the CLI deps, lodash is, the others arent, at least directly). Then run the original npm install -S babel-polyfill@6.26.0 core-js@2.5.7 prop-types@15.6.2 react@16.2.0 react-dom@16.2.0 again and voila, working.

This is reproducible on multiple systems with my co-workers so its not just my machine. I’m also installing node through nvm for what its worth.

Platform Info

$ npm --versions
{ '10.9-ace': '1.0.0',
  npm: '6.2.0',
  ares: '1.14.0',
  cldr: '33.1',
  http_parser: '2.8.0',
  icu: '62.1',
  modules: '64',
  napi: '3',
  nghttp2: '1.32.0',
  node: '10.9.0',
  openssl: '1.1.0i',
  tz: '2018e',
  unicode: '11.0',
  uv: '1.22.0',
  v8: '',
  zlib: '1.2.11' }
$ node -p process.platform