need help to better understand cache keys behavior

[joaomelo]

Hi there,

First, thanks for the awesome work with this GitHub action :)

I'm planning to use the cache action to persist the npm cache of my node project. I read the article "Caching dependencies to speed up workflows," this action documentation, and some articles on medium and dev portals.

My understanding is that the standard is to use package-lock.json to build a hash for the cache key and restore keys for edge cases. But that raise some questions to me, and I couldn't find direct answers in my searches. Here we go:

1 - The way I use the package-lock.json version field invalidates the hash approach?

Every time I trigger my workflow, I also update the version on my package.json (which reflects on package-lock). Most of the time is an incremental bump on the patch part. The principle behind this is that, If I am running a delivery script, I assume this is a new SW version. I know this is not mandatory and probably even not standard.

But, to confirm, by going with this version design, am I invalidating the use of a key based on the "package-lock" file hash? Like this one: key: ${{ runner.os }}-npm-${{ hash files('**/package-lock.json') }}. Wouldn't that generate a new hash at every workflow trigger?

2 - By reaching for a static key or restore keys, cause a first eternal static cash?

Let's say as an alternative, I go with a simpler key like: key: ${{ runner.os }}-npm or rely on restores key like this:

        key: ${{ runner.os }}-build-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.os }}-build-${{ env.cache-name }}-
          ${{ runner.os }}-build-
          ${{ runner.os }}-

In practice, wouldn't that cause the first cache to become eternal?

My logic is this: the cache will be formed the first time by a complete miss. Then at every workflow, the main key will miss because the package-lock.json version field is continually changing, but the restore key will hit. The first cache will then restore, and eventual dependencies added since then will be installed.

What pains me is that the cumulative additional dependencies will be forever downloaded unless I manually change the key. Is this right thinking?

3-Is there a way out?

I thought that maybe repeated use of restore-keys could trigger some update. But I couldn't find any hint about that.

I also thought about the hash been built around a portion of the package-lock.json file and not the whole thing. Maybe skip the first two lines or parse only the dependencies fields. I can imagine that been built with some massaging of webpack, but maybe there is a smarter approach. I can't stop thinking I am missing something here.

Any hints or directions, folks?

Thank you very much for your time.
Bye.
JM