(refactor) add lockfile abstraction #1789
Conversation
|
@chris-olszewski is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
6609272 to
72513c1
Compare
There was a problem hiding this comment.
Looks mostly good to me. Maybe @nathanhammond can provide more comments.
| // ResolvePackage Given a package and version returns the key, resolved version, and if it was found | ||
| ResolvePackage(name string, version string) (string, string, bool) | ||
| // AllDependencies Given a lockfile key return all (dev/optional/peer) dependencies of that package | ||
| AllDependencies(key string) (map[string]string, bool) |
There was a problem hiding this comment.
This is the graph, resolved to a set.
| import "io" | ||
|
|
||
| // Lockfile Interface for general operations that work accross all lockfiles | ||
| type Lockfile interface { |
There was a problem hiding this comment.
Do we want to maybe throw a graph library underneath this?
There was a problem hiding this comment.
As in provide a way to access the contents as a DAG? Are there any favorite graph libraries in Go world?
There was a problem hiding this comment.
Well, not as a DAG because npm allows cycles, but so that we're able to leverage basic graph algorithms for reduction. I think it'd be a worthwhile addition, but agreed not for this PR.
There was a problem hiding this comment.
At the moment this interface only deals with data operations and no IO/marshalling. I went with an interface instead of a single struct with an instant for each impl as the contents of a lockfile differ greatly between package managers. Tested pruning a yarn mono repo made with `create-turbo` and verified the lockfile produced was the same as before this commit.
Change so we build up the lockfile in memory as opposed to writing/reading an intermediate to disk. This should allow for better testing of the lockfile marshalling logic
72513c1 to
9da959d
Compare
|
Resolved most comments that were brought up. Few notes:
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This PR introduces a new lockfile abstraction that will allow us to easily add more lockfile support to other package managers. It also
Notable changes:
Contextnow stores the lockfile interface instead of a yarn specific lockfilePackageJsonnow only stores the package names as they appear in the lockfile, these will be mapped to their entries when the pruned lockfile is createdFrom my understanding of Golang I think having
Lockfileas an interface makes sense since each package manager has a different data layout for their lockfile e.g. pnpm has 6 top level entries and yarn's top level entries are the package entries themselves.Testing:
The e2e tests cover yarn prune, but I also tested that prune produces the an identical lockfile before and after these changes on a repo created with
npx create-turbo.