How to increase EsLint memory to avoid `JavaScript heap out of memory`?

I've browsed the EsLint docs hoping to find an option to configure it to run with more memory. Sadly I was not able to find anything of the sort.

However, inspired by @vsemozhetbyt's answer -hence the up-vote- I started looking at Node's configuration options and I've found a way to get around this using Node's NODE_OPTIONS environment variable.

A space-separated list of command line options. options... are interpreted as if they had been specified on the command line before the actual command line

So this is what I did:

$ export NODE_OPTIONS="--max-old-space-size=4096"
$ eslint app.js

This way the Node process that runs EsLint just picks this up without the need for me to type in the --max-old-space-size flag nor the path to the Node binary every time I invoke EsLint.

By default, Node.js sets memory limit near 1.5 GB. You can increase it by --max_old_space_size key (say, --max_old_space_size=4096 to use 4 GB).

To use the key, you need to know the path to the ESLint main file and call it as a script this way:

node --max_old_space_size=4096 ./node_modules/eslint/bin/eslint.js app.js

I was having this problem in a Laravel/Vue application. Those details aren't significant, but the fact that Laravel has some folders such as vendor that includes all the composer packages meant that ES Lint was traversing a huge number of files, enough to blow out the heap.

The solution was to first add a .eslintignore file into the root of the project, such as:


Next, to execute ES Lint from the CLI (and GitLab-CI) as:

node_modules/eslint/bin/eslint.js --config ./.eslintrc.json .

It was also important to make sure ES Lint was using the correct config file to check against the intended ruleset.

You can visually test against some of this by adding --debug onto your CLI command, and you will see it traversing illegal folders and files if that is occurring. I think that is a decent debug step--to test it in verbose mode. You might see ES Lint traversing unnecessary folders or testing against incorrect rules.

In my opinion, this problem can easily stem from ES Lint trying to load a huge number of errors into memory while it is working. Rather than increase the heap, you can dial in what exactly ES Lint is linting.