fix: affected_packages's optimization flow
#9950
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| @@ -70,23 +69,21 @@ impl<'a> ScopeChangeDetector<'a> { | |||
| &lockfile_path, | |||
| ) { | |||
| debug!("lockfile did not change"); | |||
| return None; | |||
There was a problem hiding this comment.
this appears to have been sorta incorrect because the None state was intended to mean "there was a change but we don't know what it was" which maps, today, to LockfileContents::Unknown. But, as you can see here, it's being used in the codepath where LockfileContents::Unchanged is correct. Ultimately, it shouldn't be a behavioral change, though, because the codepaths have the same end behavior.
There was a problem hiding this comment.
Isn't "there was a change but we don't know what it was" Some(None)? And None is "no change"
| /// This describes the state of a change to a lockfile. | ||
| pub enum LockfileContents { | ||
| /// We know the lockfile did not change | ||
| Unchanged, |
There was a problem hiding this comment.
although at first I thought this might not be needed because we have the list of files and can simply see that the lockfile wasn't in there, it's used in change_detector with get_lockfile_contents.
| @@ -57,6 +57,7 @@ export class Workspace { | |||
| */ | |||
| affectedPackages( | |||
| files: Array<string>, | |||
| changedLockfile?: string | undefined | null | |||
| comparison?: string | undefined | null, | |||
There was a problem hiding this comment.
Not blocking, but I feel like from or base is less confusing name.
Defer to Git wizard @NicholasLYang, if you're finding affected packages between HEAD and another commit, is there a standard name for what to call that other commit?
There was a problem hiding this comment.
@NicholasLYang I agree with @chris-olszewski - happy to refer to you on this and in my next PR on the api side, I'll be sure to rename it there too, to match.
There was a problem hiding this comment.
Probably base is best
### Description In #9950 (comment) it was observed that `bun.lock` is missing from this list. I started by exposing and then consuming the constants right from the source (d9ea60f) and then added `bun.lock` to the list in (c5840db) ### Testing Instructions `bun.lock` should now invalidate. With #9783 being released, this is expected behavior.
### Description In vercel#9950 (comment) it was observed that `bun.lock` is missing from this list. I started by exposing and then consuming the constants right from the source (d9ea60f) and then added `bun.lock` to the list in (c5840db) ### Testing Instructions `bun.lock` should now invalidate. With vercel#9783 being released, this is expected behavior.
Description
This PR addresses the
affected_packagesAPI and its handling of the optimization for lockfiles. It should not change the current behaviors without this optimization.Testing Instructions
In Progress...