Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Working relative to package.json, not git directory #373

Closed
thedamon opened this issue Jan 4, 2018 · 4 comments · Fixed by #374
Closed

Working relative to package.json, not git directory #373

thedamon opened this issue Jan 4, 2018 · 4 comments · Fixed by #374

Comments

@thedamon
Copy link

thedamon commented Jan 4, 2018

The docs state:
"The paths used for filtering via minimatch are relative to the directory that contains the .git directory"

But using 6.0.0, that's not the behaviour I'm seeing.

Structure

📁.git
📁other-project
📁project
  📁front-end
    📄package.json
    📁subproject
      📁scripts
        📄file.js*

This config:

"lint-staged": {
    "subproject/scripts/file.js": [
      "eslint --fix",
      "git add"
    ]
}

is picking up the change to /project/front-end/subproject/scripts/file.js

Is that expected and I misread the docs? Or is this a bug, or potentially being interrupted by something else.. I have no other hooks and not sure what would be interfering (using husky)

@sudo-suhas
Copy link
Collaborator

Hey @thedamon, thanks for opening the issue. The docs were incorrect as it was not updated correctly in the PR which deprecated gitDir(#327). I have opened a PR which corrects this(#374). Here's a preview link for the updated docs - /README.md@docs/filtering#filtering-files.

From what I can see, you have a multi-project monorepo. You should check out okonet/lint-staged#how-to-use-lint-staged-in-a-multi-package-monorepo and the example repo - https://github.com/sudo-suhas/lint-staged-multi-pkg which explain in more detail the ways you could use lint-staged in a monorepo.

@thedamon
Copy link
Author

thedamon commented Jan 4, 2018

Thanks! i read through some of the issues related to the removal of gitdir but maybe not close enough as i didn't properly come away thinking the behaviour would have changed...

we don't actually have a package.json in the project root (it's a java based CMS and our team is working just on the front end assets), but maybe we should weigh the advantages of adding one.

in the meantime I'll just act as if your PR is merged and cross my fingers!

@sudo-suhas
Copy link
Collaborator

I see. A package.json at the project root would only be required if you want to lint multiple projects inside the git repo, each of which has it's own linters. The reason for this is that husky overwrites any pre-commit hook which might have been setup by a different project. Therefore, only the last project which setup husky would have it's pre-commit hooks run. If the front-end folder is the only node.js project in your git repo, you can simply install lint-staged inside that and specify the file patterns relative to the project root.

@okonet
Copy link
Collaborator

okonet commented Jan 4, 2018

we don't actually have a package.json in the project root

@thedamon that shouldn't be a problem. The latest version works differently and the documentation PR is on the way (#374 — thanks @sudo-suhas for working on it!) so you should be able to add lint-staged and husky to your front-end project inside the bigger git project and make paths (or just keep it simple and use *.js since it should not interfere with the Java code) relative to it.

As @sudo-suhas mentioned, husky will overwrite pre-commit hook in the .git directory anyways, so please be careful. If you already have precommit hook, you might want extend it instead of using husky.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants