What version of Oxlint are you using?
1.58.0
What command did you run?
oxlint .
What does your .oxlintrc.json (or oxlint.config.ts) config file look like?
import { defineConfig } from "oxlint";
export default defineConfig({
options: {
reportUnusedDisableDirectives: "error",
typeAware: true,
typeCheck: true,
},
env: {
browser: true,
node: true,
},
plugins: ["eslint", "import", "jsdoc", "jsx-a11y", "nextjs", "oxc", "promise", "react", "typescript", "unicorn"],
categories: {
correctness: "error",
nursery: "error",
pedantic: "error",
perf: "error",
restriction: "error",
style: "error",
suspicious: "error",
},
rules: {
// (rule overrides omitted for brevity)
},
});
What happened?
What happened:
Running oxlint . in a project with its own .git directory consistently reports 0 files, even though the project contains 98 TypeScript/TSX files. Passing explicit file paths works correctly (e.g. oxlint app/(frontend)/providers.tsx finds and lints the file). Shell-expanded globs also work (e.g. oxlint app/**/*.tsx lints 9 files).
The cause is a .gitignore file in a parent directory above the project's git root. Specifically, I have a dotfiles repository at ~ with a ~/.gitignore that starts with * (ignore everything, then selectively un-ignore tracked dotfiles). This is a common pattern for managing dotfiles with git.
My project lives at ~/Local Documents/Projects/.../Cairn/ and has its own .git directory. Git itself correctly scopes .gitignore files to their own repository — ~/.gitignore only applies to the dotfiles repo at ~/, not to the separate Cairn repo. However, oxlint's file walker appears to naively walk up parent directories and apply every .gitignore it encounters, crossing the .git boundary. The * rule from ~/.gitignore causes it to skip every file.
Reproduction steps:
- Create a git repo at
~ (or any ancestor directory) with a .gitignore containing *.
- Have a separate project with its own
.git in a subdirectory.
- Run
oxlint . inside the project.
- Observe:
Finished in Xms on 0 files.
- Remove or rename the parent
.gitignore.
- Run
oxlint . again.
- Observe: files are now discovered and linted correctly.
Additional context:
- The
--no-ignore flag does not resolve the issue — it still reports 0 files.
- This also reproduces with a minimal JSON config (
{}) passed via -c, so the config format is not a factor.
- oxfmt (v0.43.0), from the same oxc project, does not have this issue. Running
oxfmt --check in the same project directory correctly discovers and formats 106 files. This suggests the bug is specific to oxlint's file walker, not shared infrastructure.
What version of Oxlint are you using?
1.58.0What command did you run?
oxlint .What does your
.oxlintrc.json(oroxlint.config.ts) config file look like?What happened?
What happened:
Running
oxlint .in a project with its own.gitdirectory consistently reports 0 files, even though the project contains 98 TypeScript/TSX files. Passing explicit file paths works correctly (e.g.oxlint app/(frontend)/providers.tsxfinds and lints the file). Shell-expanded globs also work (e.g.oxlint app/**/*.tsxlints 9 files).The cause is a
.gitignorefile in a parent directory above the project's git root. Specifically, I have a dotfiles repository at~with a~/.gitignorethat starts with*(ignore everything, then selectively un-ignore tracked dotfiles). This is a common pattern for managing dotfiles with git.My project lives at
~/Local Documents/Projects/.../Cairn/and has its own.gitdirectory. Git itself correctly scopes.gitignorefiles to their own repository —~/.gitignoreonly applies to the dotfiles repo at~/, not to the separate Cairn repo. However, oxlint's file walker appears to naively walk up parent directories and apply every.gitignoreit encounters, crossing the.gitboundary. The*rule from~/.gitignorecauses it to skip every file.Reproduction steps:
~(or any ancestor directory) with a.gitignorecontaining*..gitin a subdirectory.oxlint .inside the project.Finished in Xms on 0 files..gitignore.oxlint .again.Additional context:
--no-ignoreflag does not resolve the issue — it still reports 0 files.{}) passed via-c, so the config format is not a factor.oxfmt --checkin the same project directory correctly discovers and formats 106 files. This suggests the bug is specific to oxlint's file walker, not shared infrastructure.