feat: Add prune support for Yarn 3

[chris-olszewski]

Add prune support for Yarn 3. In order to support this we also support marshalling to the yarn lockfile data format. Due to the strict nature of yarn install --immutable BerryLockfile has internal structures that aren't directly serialized to the generated lockfile. Future work will be required to make the Subgraph method correctly prune these internal structures.

A quick rundown of the structure of a yarn lockfile:

• Descriptors are packages with a version range used to index and find the resolved entry for a package. Resolved entries have multiple descriptors if workspace packages or transitive dependencies use the same package with overlapping semver ranges. All descriptors are joined with , to create the key to the lockfile entry
• Locators are the resolved version of a descriptor where instead of a version range there is a concrete version. Each locator maps directly to an entry in the lockfile and is found in the resolution field.

Known issues:

• This doesn't prune patches produced by yarn patch as this requires pruning of package.json which we don't support yet.
• Yarn bundles some dependencies that default plugins require. It appears that if your lockfile contains an entry for these dependencies, Yarn expects that you should include the descriptor that is used in the bundled version. To see the bundled dependencies search for ^7.8.3 in this file. Some of these are very common packages so I'm afraid that this might be a case that's easy to hit. Looking into if this is desired behavior for Yarn and if there's any way to figure this out without parsing the minified yarn JS.

[vercel]

@chris-olszewski is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[quinnturner]

Hi! If you're using the same YAML parser that existed before, you may need to order these based on their presence in the lockfile definition.

This order follows the order present in the Yarn Berry lockfile definition:

type BerryLockfileEntry struct {
 	// resolved version for the particular entry based on the provided semver revision
 	Version    string `yaml:"version"`
 	CacheKey   string `yaml:"cacheKey,omitempty"` // only present in the __metadata object
 	Resolution string `yaml:"resolution,omitempty"`
 	// the list of unresolved modules and revisions (e.g. type-detect : ^4.0.0)
 	Dependencies map[string]string `yaml:"dependencies,omitempty"`
 	// the list of unresolved modules and revisions (e.g. type-detect : ^4.0.0)
 	PeerDependencies     map[string]string          `yaml:"peerDependencies,omitempty"`
 	PeerDependenciesMeta map[string]map[string]bool `yaml:"peerDependenciesMeta,omitempty"`
 	Bin                  map[string]string          `yaml:"bin,omitempty"`
 	OptionalDependencies map[string]string          `yaml:"optionalDependencies,omitempty"`
 	Checksum             string                     `yaml:"checksum,omitempty"`
 	Conditions           string                     `yaml:"conditions,omitempty"`
 	LanguageName         string                     `yaml:"languageName,omitempty"`
 	LinkType             string                     `yaml:"linkType,omitempty"`
 }

The current version is missing OptionalDependencies. Is that intentional?

If the order doesn't matter due to the implementation approach, you can ignore this if you'd like!

[chris-olszewski]

I'm just using yaml to parse the lockfile. Sadly due to some oddities with the Yarn lockfile format I had to port the serialization logic to Go instead of using the yaml library.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
turbo-site	✅ Ready (Inspect)	Visit Preview	Sep 21, 2022 at 7:23PM (UTC)

[gsoltis]

Force-merging, error looks unrelated.