Lint-staged: Command-line flag to lint changed unstaged files as well?

[mgol]

I was wondering if the package could support a command-line flag to lint unstaged but changed files as well - that may often be useful when starting a dev server to have a quick feedback about errors only in modified code.

On one hand, this may go against the package name. On the other hand, this package includes a lot of niceties like easy-on-eyes console output, easy configuration etc. so duplicating it all just to get unstaged linting support seems wasteful.

What do you think?

[okonet]

You don't need this package for that. You can just do this with husky:

"scripts": {
  "precommit": "eslint ."
}

This will run eslint on all files each time.

If you want to lint before start, you could do something like:

"scripts": {
  "prestart": "eslint ."
}

etc.

[mgol]

I don't want to run the linter on all files but only on the ones modified

since the last commit. That's the whole problem.

Michał Gołębiowski

[okonet]

Ah gotcha. Anyway this is out of scope for this package but I assume there are packages on npm that coudl work for you.

FYI if you're using webpack you can add a loader that will lint modified files during the dev process.

[okonet]

Actually, it just made me think since I wanted to go away from this dependency https://github.com/okonet/lint-staged/blob/master/package.json#L54 this might be a good experiment. So if you're up to it, you could try creating a PR and we could discuss it.

So, I'd say it could be an additional option gitCmd that would get you the list of files. So for staged files it would be something like git diff-index --cached --name-only HEAD and for all changed you'll run it without --cached.

This would allow more simple integrations with other backends like Mercurial, for example.

Thoughts?

[chilijung]

@mgol here is another alternative for this repository, with zero config
eslint: https://github.com/Canner/eslint-gitstatus
tslint: https://github.com/Canner/tslint-gitstatus

if you want to implement for other libraries you could use https://github.com/Canner/git-status-filter-file-extension apis, for getting the latest modified files.

[luftywiranda13]

@mgol you can pass --cache flag to eslint. like eslint . --cache. So ESLint will only check changed files.

http://eslint.org/docs/user-guide/command-line-interface#options

[wald-tq]

@okonet I did experimental support for unstaged files in my branch, also used gitty for git access.

Here is the branch: https://github.com/wald-tq/lint-staged/tree/unstaged

[bennycode]

Is there any update on this topic? Because I also want to run my linters on every modified file (not just the staged ones!) without the need having the linters inspecting ALL files.

Here is my case which shows that lint-staged doesn't work for modified files: 😢

@wald-tq I declard "lint-staged": "wald-tq/lint-staged#1072028f4b3483ae44a711162b6ee6ffdb69da6f" in my package.json in hope it would pick up my modified files but it didn't. 😢

[wald-tq]

@bennyn Sorry for my late reply, you need to add the configuration for unstaged files like this:

  "lint-staged": {
    "unstaged": true,
    "linters": {
      "*.ts": "tslint"
    }
  },

[bennycode]

@wald-tq: Thanks for the hint! I tried it but now I am getting this error (TypeError: Cannot read property 'push' of undefined in gitty):

Screenshot

Here is my config:

  "lint-staged": {
    "unstaged": true,
    "linters": {
      "src/**/*.{css,js,json,jsx,less,scss}": [
        "npm run lint",
        "git add"
      ]
    }
  },
  "scripts": {
    "lint": "prettier-eslint --write \"src/**/*.{css,js,json,jsx,less,scss}\"",
  }

Am I doing anything wrong?

[wald-tq]

I think you have to track down your problem. First I would get sure that lint-staged produces the correct output.

I am using lint-staged as part of my webpack build using the webpack-shell-plugin.

[theenadayalank]

Maybe this package could help to lint committed files on pre-push https://github.com/theenadayalank/lint-prepush.
Inspired by this issue https://github.com/okonet/lint-staged/issues/303

[aguynamedben]

I noticed this as I upgraded lint-staged. lint-staged ^7.2.0 would also lint changes that were not staged, which is a workflow I got used to.

1. Run yarn lint-staged. See that things need fixing.
2. Fix the things.
3. Run yarn lint-staged. See that you fixed it.

Now I have to stage all day just to fix a bunch of lint changes. an "unstaged": true option would be awesome. I was looking through the readme/change log and don't see any references to this behavior, but if you downgrade to lint-staged 7.2.0 you will see that unstaged changes are linted.

[amimas]

Was this feature added/removed mistakenly? I'm also looking to lint files that has changed only (i.e. added/modified files) but before attempting to commit.

[iiroj]

I think as the name suggest, the simple case of lint-staged will always be to only work with staged files. This was probably removed in v9 where we removed the advanced configuration options.

I do have this branch where you can supply a custom list of files to the Node.js API:
https://github.com/okonet/lint-staged/commit/d220555bf7a402fbd799c922330539bb38dcf4c8

It's not ready, since it shouldn't hide all unstaged changes when supplied with a custom list, but it would allow simple wrapper scripts for running the same lint-staged config against other files as well.

Thoughts on this?

[okonet]

It was never implemented afaik

[amimas]

What's the future vision for this project? Will it remain as a tool to be used for "staged files only"?

If that's the vision, it's fine but it becomes a limitation in terms of usage. Being able to run linters on staged files only is a good use case for preventing bad commits.

Another use case is to be able to run linters on "changed files (including new/untracked)", which is slightly different from the idea of preventing bad commits. The only way to be able to validate "changed files" would be constantly making changes to files + staging, which probably isn't ideal.

I'm sure there could be another tool/package setup to be able to run linters on changed files only. The git status --short command already lists changed files including untracked/new files. It's just a matter of parsing the output and ignoring the files with deleted status.

But, it'd be nice to know if the vision of this tool will remain on staged files or will it be expanded to cover more use cases.

[okonet]

Another use case is to be able to run linters on "changed files (including new/untracked)", which is slightly different from the idea of preventing bad commits.

I'm not sure this is a use case TBH. This is something your editor / IDE is capable of doing. Or what am I missing?

[amimas]

I'm not sure this is a use case TBH. This is something your editor / IDE is capable of doing. Or what am I missing?

Maybe I'm missing something about linters usage 😄. I'm not sure that editors/IDEs can take care of validating unstaged files. Plus that might also depend on whether there's a plugin for the linter for corresponding editor and whether or not the contributor has actually installed the plugin.

To me, a typical workflow looks like this:

1. Change files in the repo as needed
2. Run test from the terminal
3. If everything looks good, stage and commit; otherwise repeat step 1 and 2 as needed

In step 2, running the test would typically include linters as well and that's when it'd be useful (I think), if we could run the linters on only the changed files (including new, modified, and renamed files).

[iiroj]

@amimas If you'd be content with writing a wrapper that passes a custom list of files to _lint-staged_ via the Node.js API, that might be doable pretty soon. So something like:

// lint-unstaged.js

const lintStaged = require('lint-staged')
const execGit = require('lint-staged/lib/execGit')

;(async () => {
  const files = (await execGit(['diff', '--name-only'])).split('\n').filter(Boolean)
  await lintStaged({ files })
})()

In this example _lint-staged_ would use the same config to generate and run tasks on the files-list.

[okonet]

I'm not sure that editors/IDEs can take care of validating unstaged files.

Every modern editor has a linter integration that runs on files regardless of their git status. WebStorm has it built in, vscode I believe also has it built in. If not there are plugins. Lint-staged is definitely not the replacement for editor integrations but a last outpost prior the commit to _make sure_ you didn’t forget to fix an issue.

[amimas]

@iiroj - Thanks for your suggestion. Writing something custom is probably the only option at this point. I thought the topic of this thread was to extend the usage or add a feature to this tool. But, I do agree that the suggested feature doesn't really align with the current name of the tool. It can be confusing, I think 😄

[amimas]

@okonet - I agree that lint-staged is not a replacement for editor integration. There are a lot of different linters available and not all of them are going to be available out of the box. You're right that there are plugins, but it's up to the user to install the plugin.

Lint-staged is definitely not the replacement for editor integrations but a last outpost prior the commit to make sure you didn’t forget to fix an issue.

The current feature of preventing commits is definitely useful. But, I think it's not that uncommon scenario, where someone may have to make changes multiple times before their change set is ready to be committed. That's why I'm focusing on the workflow I mentioned above. Most projects would have some kind of build & test command that contributors are expected to execute. It'd be helpful to be able to run linters on modified, renamed, or new files as part of that test command. The only way this can be achieved right now, I think, is to keep staging changes, which probably isn't necessary.

I am relatively new to linting. So, it's possible I'm missing something obvious.

[okonet]

suggested on the Husky readme as a way to run a pre-commit linting hook as fast as possible

It literally suggests using lint-staged to solve that. So we now came full circle and there is a feature request to lint-staged that works around the use of lint-staged? 😅

Unfortunately the JetBrains family of editors doesn't stage a file when you edit it.

None of editors stage files as you edit it AFAIK so I'm not sure wha't the issue here. Can you elaborate, please?

[jonfreedman]

I was digging into why our pre-commit wasn't working, without wanting to commit. Turns out the edited files are staged as part of the commit (I assume in order to support changesets) so this turns out to be a non issue.