Do not ivalidate the cache entirely on lock file change

[dsame]

Description:

Add a function cache-utils.ts:repoHasYarn3ManagedCache returns true if there's at least one project with yarn3 managed cache

Yarn3 managed cache enables safe use of the previous cache cache.restoreCache(cachePaths, primaryKey, [keyPrefix])
because obsolete dependences are removed by Yarn not letting cache to grow endlessly

Related issue:
#325

The PR initially contained Node version in the key but it was removed due to
#325 (comment)

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[marko-zivic-93]

From the code standpoint it looks ok to me. I am not sure about the semantics :)

[nikolai-laevskii]

Looks good to me

[nikolai-laevskii]

I'll keep my green light. Couldn't find something out of order, still looks good to me. But don't forget to rename branch from yarn-perfomance to yarn-performance before merging it into actions

[marko-zivic-93]

LGTM!

[belgattitude]

Hey thanks ! a small question

Does it disable the node_modules folder caching when yarn3 zip files are enabled ?

[dsame]

Does it disable the node_modules folder caching when yarn3 zip files are enabled ?

Hello @belgattitude, the PR does not change the caching strategy in part of node_modules folder, but yarn3 replaces node_modules with PnP that is supposed to be managed through VCS

[arcanis]

Hey - I'm trying to understand this change. Does it mean that the best thing a Yarn project running with this action can do is to NOT use the global cache (enableGlobalCache: false) AND to also NOT check-in the .yarn/cache folder?

In Yarn v4 we're changing the default to make enableGlobalCache: true the default - would it make sense for us to keep it to false when the install is running on a GitHub action, and only there?

[arcanis]

Ping @dsame ? We'll soon release the 4.0 stable; do we need to automatically set enableGlobalCache: false on GH Actions?

[belgattitude]

Personally I wouldn't.

The enableGlobalCache new default won't be enough to get the benefits (action cache keys are part of the recipe too). I would let the setup responsability to setup/node or any tool/action/script that help setting up caches.

Applying different defaults depending on env might also create confusion.

I'd prefer a section in the yarn doc that focuses on a simple recipe for ci and caches (possibly with less emphasis on offline mode or a reference to it as an advanced use case.).

That would help people implementing cache strategies (azure, vercel... ) to identify quickly what variables are important, what they do and apply a strategy within their "platform" possibilities.

Congrats for Yarn 4.0

[MaksimZhukov]

Hello @arcanis!

I'm trying to understand this change. Does it mean that the best thing a Yarn project running with this action can do is to NOT use the global cache (enableGlobalCache: false) AND to also NOT check-in the .yarn/cache folder?

Yes, if the user uses the local cache and .yarn/cache folder is not in the repository, the action will automatically try to restore previous cache even if it is outdated in order to speed up the build.

In Yarn v4 we're changing the default to make enableGlobalCache: true the default - would it make sense for us to keep it to false when the install is running on a GitHub action, and only there?

Thank you for contacting us and letting us know, we really appreciate it! In our opinion, it is not necessary to leave enableGlobalCache set to false for GitHub Actions, because this inconsistency can lead to confusion. Users can change this option if they want to use the local cache. We will reflect this behaviour in the action documentation to make it clear.

[belgattitude]

@arcanis for context, I realized there was a thread about the new setup node cache. It starts from there #325 (comment)