tophat / yarn-plugin-licenses

Describe the bug

On Yarn 3.1.0, this plugin adds a version of fsevents to the Yarn cache if it isn't already present at a suitable version.

To reproduce

Steps to reproduce the behavior:

Upgrade to Yarn 3.1.0 in a Linux-only project.
Run yarn licenses audit.

Expected behavior

The local Yarn cache isn't modified. Modifying the cache is problematic since the cache is version controlled when using Zero-Installs.

Environment (please complete the following information):

OS: Ubuntu 21.10
Plugin Version: 914560d
Node Version: 17.0.1

Additional context

fsevents is a macOS-only dependency that is part of the dependency tree of many very popular packages. yarn install (or, more specifically, yarn dedupe --strategy highest) removes the added dependency on fsevents since Linux-only projects by definition don't depend on fsevents. Hence, yarn install ends up in a tug of war with this plugin. I don't know whether the problem affects projects on Yarn 3.0 that don't depend on fsevents. Note the following excerpt from the Yarn 3.1.0 changelog:

Yarn won't install anymore packages that don't match the current OS. Should you need to (for example if you check-in your cache), use the supportedArchitectures field to manually enforce the presence of specific architectures.

For projects that support macOS, they already need to specify "darwin" as a supported OS in their .yarnrc.yml when upgrading to Yarn 3.1.0, so they won't encounter this problem if they happen to depend on a suitable version of fsevents. For projects that don't support macOS, I don't know of a great workaround beyond removing the added fsevents package each time after running this plugin (e.g., via an alias). I believe this issue might be addressed (or at least remediated?) simply by upgrading the plugin itself to Yarn 3.1.0?

The build didn't change when I updated to yarn 3.1.0.

The most we do is a "restoreInstallState":

yarn-plugin-licenses/src/index.ts

Line 55 in 914560d

await project.restoreInstallState()

.

Thank you for the quick reply. It's possible that installing via the API like that causes Yarn to consider all operating systems supported. What OS are you on?

Mac + Ubuntu, but only tested this on mac locally. We should be able to reproduce this via a github workflow

I tried upgrading to Yarn 3.1.0 and the latest version of this plugin on Ubuntu, but I still encounter the same issue. I don't really see a way of resolving this besides removing the restoreInstallState() call and expecting the user to run yarn install themselves when necessary?

Yeah, faced this too with 3.1.0. For me, it happens on Linux and macOS too.

We can try bump the dependencies. We should be rebuilding this for 3.1.1 anyway -- and I need to update my release strategy for these plugins so they're versioned correctly rather than just pushing a single artifact to the main branch

I just rebuilt the plugin targeting 3.2.1. Can you try that out?

Also, I'm wondering what the best versioning strategy is for this plugin. Right now I only maintain "master". I'm thinking of not using semver but instead of the major and minor version match the yarn release and then have the patch be a build number. It does mean we can't release breaking changes though.. I have this problem in my other yarn plugins too.

Thank you for giving this a shot! The symptom remains the same, unfortunately. plugin-licenses-audit.cjs at d4169d7 is identical to the one at 914560d.

Your versioning strategy seems reasonable to me with the caveat that I have no experience maintaining a Yarn plugin. Maybe someone in https://github.com/yarnpkg/berry/discussions would have more insight? If you aren't using SemVer, you are entitled to release all of the breaking changes you want in my personal opinion, although obviously that's a power best wielded with restraint.

I tried adding supportedArchitectures to .yarnrc.yml, but the bug persists at Yarn 3.2.3, which makes me wonder what exactly is causing this issue in the first place.

Fixed by adding cache options to fetcher:

const { packageFs, prefixPath } = await fetcher.fetch(pkg, {
    project,
    fetcher,
    cache,
    cacheOptions: {
        mockedPackages: project.disabledLocators,
        unstablePackages: project.conditionalLocators,
    },
    report,
    checksums: project.storedChecksums,
})

Inspired by https://github.com/yarnpkg/berry/blob/9287251b7182df1631d3ad2689339d9a2fae8072/packages/yarnpkg-core/sources/Project.ts#L1061-L1065

Fixed in the latest commit. Thank you @sarahsporck!

Plugin Modifies Yarn 3.1.0 Cache of Projects Not Dependent Upon `fsevents`