🦋 Changeset detected

Latest commit: b89ff4f

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Tests added.

What happens if something is added to .gitignore, but .gitignore is not staged?

Regarding your .gitignore question, let's not build additional logic but always trust what Git tells us. So in that case the unstaged changes in .gitignore would be hidden, but lint-staged already listed the staged files before that.

I'll try to spend some time on this over the weekend.

There's a random failure that occurs on about 5% of runs. Restoring the backup stash and re-running does not result in an error. The error message seems to indicate that the stash isn't found, but I haven't yet figured out why.

@ItsNickBarry

I had a workaround for this feature for a while, I wrapped lint-staged to hide all untracked and un-staged chunks so TypeScript compilation can be checked.

I wonder if I can help to get this released.

The error message seems to indicate that the stash isn't found, but I haven't yet figured out why.

Does this happen immediately after git stash push?

I've had similar issues. I've added a 1 second wait (I know not pretty) after pushing the stash as git seem to exit a bit sooner than it should. Instead of the wait we could poll for stash to appear with 1 second timeot?

There are definitely some bugs and issues in git (depending on the version). Sometimes git stash would create a stash but fail to cleanup the index. For which I had to add a workaround too (comparing the index to stash and resetting). Not pretty too :)

I think it's fixed. Issue was that await this.execGit(['stash', 'apply', '--quiet', '--index', rev]) treats rev as an index if all of its characters are numbers.

Is there a way for me to test this version of lint-staged to make sure my expectations of the behavior is the same? UPD: I guess I can checkout this branch and run it locally NP.

@zaripych You can also npm install lint-staged@[email protected]:ItsNickBarry/lint-staged#hide-all

@zaripych yes, lint-staged doesn't have a compilation step or anything so the code can be directly adjusted inside node_modules/.

I haven't been able to spend time on this yet. In general it's ok but I feel it should more cleanly preserve the current implementation (in main) as the default logic.

I've ended up using this command npx lint-staged@[email protected]:ItsNickBarry/lint-staged#hide-all --hide-untracked --hide-unstaged

I've done a few rounds of testing with new parameters and this works quite well. The scenarios I tested:

• Having some code with TypeScript issues in unstaged area - were hidden when passing parameter, restored after run
• Having some working code chunks staged, while some more chunks (with TypeScript errors) in the same file unstaged - only unstaged code was hidden, everything restored after run
• Having some staged code rely on unstaged code - unstaged code hidden and as expected, linting fails, all files restored after run
• Having untracked files with TypeScript issues - files hidden completely, restored after run

I just realized this doesn't cover a few other use cases I have with lint-staged that I patched 😅, but this is off-topic here.

Thank you @ItsNickBarry for great work.

Let me know if I can help further.

This is exactly the kind of functionality I'm looking for in order to be able to use knip!

Sorry, I tried to rebase this to the current origin/main but it's too many commits and merge conflicts.

Ping @ItsNickBarry I decided to re-implement the --hide-unstaged flag in a new PR #1636 because it seemed a lot easier this way.

Let's figure out the --hide-untracked after this in another PR (or this one). I believe after merging the new PR #1636 it will be a lot clearer that we create a second patch file for untracked files.