Hi, is there any possibility to not pass any arguments into command. I'm using lint-staged like so:
...
"scripts": {
"build": "gulp build"
},
"lint-staged": {
"resources/assets/client/js/application/**/*.js": [
"npm run build",
"eslint --fix",
"git add"
]
}
...
So I dont want to pass files args into my build task because it breaks.
npm run build -- file1.ext file2.ext
Why would you use 馃毇馃挬 lint-staged otherwise? You can just use git hooks.
I am using lint-staged to detect if package.json is staged and if so, run yarn install to update yarn.lock file. So I add yarn install in the npm scripts section which is getting passed the arguments by lint-staged.
I do the same and I've just created a separate script that does compare yarn.lock files in diff revisions. I don't have the problem with arguments.
This is related to #138
You can very simply ignore args. For example:
npm run blah && :
The trailing : is the "no-op" command in Bash. Any args passed to it are always ignored, and it always exits 0.
For example, to use it in lint-staged:
"lint-staged": {
"*.{ts,tsx}": [
"tsc -p ./tsconfig.json --noEmit && :"
],
},
that way for example lint-staged will not break the TypeScript tsc command (because passing it files changes the meaning, and in TypeScript you want it to check your _whole project_ otherwise TypeScript won't detect type errors in files that you didn't modify in your commit, thus you will introduce errors into your commit).
Also because of the &&, if the tsc command fails, then the whole command will fail and the commit will fail (which is what you want).
@trusktr,
You can very simply ignore args. For example:
..."lint-staged": { "*.{ts,tsx}": [ "tsc -p ./tsconfig.json --noEmit && :" ], },
Did you test this example? I tried it and it didn't do the thing.
I followed through lint-staged source code and it seems like this example should not work.
lint-staged does not look at the command as at bash script.
Instead, it thinks of it as a single binary with an array of arguments, so tsc -p ./tsconfig.json --noEmit && : translates into, roughly speaking, execFile('tsc', ['-p', './tsconfig.json', '--noEmit', '&&', ':']).
So, && and : are just two another args of tsc command and are just ignored.
It seems like, if you want to ignore staged files as args in case of tsc command, you should use it like this:
"lint-staged": {
"*.{ts,tsx}": [
"bash -c \"tsc -p ./tsconfig.json --noEmit\""
],
},
Am I missing something?
lint-staged does not look at the command as at bash script.
I can confirm that.
In case it's helpful to someone else, I was looking for how to run unit tests in a particular folder when files are changed, and arguments were breaking the script.
However, even better than ignoring arguments is to use the jest option --findRelatedTests which takes advantage of lint-staged passing the filenames:
"lint-staged": {
"src/**/*.{ts,tsx}": [
"yarn test-related-ci",
]
}
"scripts": {
"test-related-ci": "jest --findRelatedTests"
}
For what it's worth, in the latest version it's possible to not pass arguments by using the function config.
As an example, see https://github.com/okonet/lint-staged#example-run-tsc-on-changes-to-typescript-files-but-do-not-pass-any-filename-arguments
@trusktr's solution worked when I put the && : in the script command. For example:
"scripts": {
"build": "ncc build src/index.ts -o dist -s && :"
},
"lint-staged": {
"src/*.{ts,js}": [
"eslint --fix",
"npm run build"
]
},
Not working with sonar-scanner:
website/app/**/*.{js,jsx,css,scss}:
- eslint --fix
- prettier --single-quote --write
- "sonarqube-verify && :"
Last job failed saying && is unrecognized option.
Managed to overcome my problem with following code:
module.exports = {
"website/app/**/*.{js,jsx,css,scss}": [
"eslint --fix",
"prettier --single-quote --write",
() => "sonarqube-verify",
]
}
Most helpful comment
You can very simply ignore args. For example:
The trailing
:is the "no-op" command in Bash. Any args passed to it are always ignored, and it always exits0.For example, to use it in lint-staged:
that way for example lint-staged will not break the TypeScript
tsccommand (because passing it files changes the meaning, and in TypeScript you want it to check your _whole project_ otherwise TypeScript won't detect type errors in files that you didn't modify in your commit, thus you will introduce errors into your commit).Also because of the
&&, if thetsccommand fails, then the whole command will fail and the commit will fail (which is what you want).