Skip to content

Conversation

@jdunck
Copy link

@jdunck jdunck commented Dec 6, 2025

Help remove or maintain entries that are no longer referencing existing files.

@jdunck jdunck requested a review from noahm as a code owner December 6, 2025 02:25
"ice-cream-flavor": "vanilla",
"owner": "@jdunck",
"timezone": "PST",
},
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

intentional ;)

const entrySatisfaction: [OwnerEntry, boolean][] = this.ownerEntries.map((entry) => {
const full = path.join(this.codeownersDirectory, entry.path);
try {
const iterator = globIterateSync(full, {});
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This checks if the glob has any entries without walking the whole result, just terminates the Generator as soon as the answer is known. (TBH I am not sure if glob is lazy or eagerly precomputes the result and just supports this interface.)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have suggested using the newer built-in glob feature of NodeJS v22 instead of a new dependency, but it has no comparable option for lazy evaluation.

I double checked the implementation in the package's source and I think it is indeed lazily evaluated, so this is an ideal approach.

Copy link
Owner

@noahm noahm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a smart addition! I'm going to be doing a bit of additional testing with it and hopefully get it into a release this weekend!

Thanks for the contribution!

const entrySatisfaction: [OwnerEntry, boolean][] = this.ownerEntries.map((entry) => {
const full = path.join(this.codeownersDirectory, entry.path);
try {
const iterator = globIterateSync(full, {});
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have suggested using the newer built-in glob feature of NodeJS v22 instead of a new dependency, but it has no comparable option for lazy evaluation.

I double checked the implementation in the package's source and I think it is indeed lazily evaluated, so this is an ideal approach.

@noahm noahm merged commit f793ae7 into noahm:main Dec 13, 2025
@noahm
Copy link
Owner

noahm commented Dec 13, 2025

@jdunck This is now published as 3.0.0-alpha.1 under the next tag. I have some additional testing to do with it later on next week, but I think it's in pretty good shape already.

@jdunck
Copy link
Author

jdunck commented Dec 13, 2025

@jdunck This is now published as 3.0.0-alpha.1 under the next tag

Very cool, thanks - just a bit of usage outside the original PR/tests -- I have a local project with 354k files, and a codeowner file of 84 rules -- it correctly lists orphans in that file.

$ time node  ~/code/open/codeowners/dist/cli.js orphans
...
node ~/code/open/codeowners/dist/cli.js orphans  1.12s user 2.16s system 113% cpu 2.898 total

This is on a Macbook M4 Pro -- I haven't tested on linux or windows, though.

@jdunck
Copy link
Author

jdunck commented Dec 13, 2025

I realized I didn't update the README with the command, want me to do that, or leave it to you?

@jdunck
Copy link
Author

jdunck commented Dec 13, 2025

And one more note -- I had a need for some other things around codeowners files, so I started these two things:
https://github.com/jdunck/codeowners-tools
https://github.com/jdunck/codeowners-tools-corpus

The idea of the -corpus repo is to build a bunch of commits with various edge cases. It's not super-mature, but maybe useful to you. And the -tools repo (so far) just mimics github's codeowner review mechanism with check.sh - the idea being that it could be used to make a comment on a PR (or whatever) to make it more transparent/measurable what is and is not driving codeowner reviews (whether those are desirable or not is a policy decision).

@noahm
Copy link
Owner

noahm commented Dec 14, 2025

I did notice those two repos! And I used the corpus as some ad-hoc test cases for the orphans check which ended up having a bit more nuance than this PR originally anticipated. (You can compare against the original logic in 3.0.0-alpha.0) At some point I will probably want to figure out a decent way to incorporate it or something like it into the unit tests for this project, as the current method of reusing the project's own anemic CODEOWNERS file is of limited use.

If you want to update the readme with the new command, feel free to open another PR! Otherwise I'll handle it before I publish the final 3.0.0

@noahm
Copy link
Owner

noahm commented Dec 14, 2025

And orphans usage also works for my primary test project of ~24k files and over 1k lines of CODEOWNERS:

________________________________________________________
Executed in    8.68 secs    fish           external
   usr time    3.40 secs    0.23 millis    3.40 secs
   sys time    4.04 secs    1.22 millis    4.04 secs

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants