Lint-staged: Argument list too long

[ar53n]

Description

I have a big project where I use a tslint, and I needed to check 450 files before committing, but an error occurred. But if I copy this command directly, there will be no error.

~/admin-webapp/node_modules/.bin/tslint: Argument list too long
npm ERR! code ELIFECYCLE
npm ERR! errno 126

My lint-staged config:

{
  "linters": {
    "*.ts": ["npm run lint", "git add"]
  },
  "ignore": ["**/*.spec.ts"]
}

package.json

 "lint": "tslint -c tslint.json --project src/tsconfig.json",

Steps to reproduce

Add more 360 files
run lint-staged through npm run lint

Debug Logs

expand to view

~/admin-webapp/node_modules/.bin/tslint: Argument list too long
npm ERR! code ELIFECYCLE
npm ERR! errno 126

Environment

• OS: macOS High Sierra
• Node.js: v8.9.1
• lint-staged: v7.3.0

[sudo-suhas]

I had faced this issue on Windows and we fixed it by splitting the command. Later, I made the incorrect assumption that there was no such a limit on Linux and mac. But as detailed in this stackoverflow post, https://serverfault.com/questions/69430/what-is-the-maximum-length-of-a-command-line-in-mac-os-x, it is 262144 by default on mac(probably 131072 for Linux). I will try to fix this bug sometime this week.

[ar53n]

@sudo-suhas thanks. It just confused me a bit, because the same team is doing well.

Its work good, but i think its not clear

{
  "linters": {
    "*.ts": ["tslint -c tslint.json --project src/tsconfig.json", "git add"]
  },
  "ignore": ["**/*.spec.ts"]
}

[okonet]

I think we should just print a more friendlier message and suggest to skip the run for such cases. The splitting part is rather complex and makes the code harder to maintain. I also believe the case is so rare it’s not worth doing. I hardly believe there is value in using lint-stages on hundreds of files. CI should cover that. What do you think @sudo-suhas?

[sudo-suhas]

I can see merit in either approach so I am okay with leaving it up to you. Regarding detecting the specific circumstance, do you think we should just check the number of files? It could come from the config with a sane default. And if the number exceeds the limit, we skip running the linter?

[okonet]

do you think we should just check the number of files

Yeah, something like this. Basically the number of arguments I'd say. If this exceed the limit we'd fail the whole operation with a nice error message.

[sudo-suhas]

I am not sure if failing the operation is the right thing to do. This would force the user to run it with --no-verify right?

[okonet]

Yeah, but I think that's the behavior I'd like to enforce in this case. Linting hundreds of files is no different from linting the whole project, which should be done on CI. It's about common sense and best practices. I don't want lint-staged to be the single point of failure.

[ar53n]

@okonet I agree, because the prettier works well

[iiroj]

Is this still relevant? There is now a warning message based on the length of the filenames argument, and it is possible to create custom splitting by using the function linters.

Example: Run eslint on entire repo if more than 10 staged files
https://github.com/okonet/lint-staged#example-run-eslint-on-entire-repo-if-more-than-10-staged-files