Seems quick! where's the cache?

[KyleSanderson]

Title is a bit tongue in cheek.

It doesn't look like there's a way to set a damage file or anything for purposes of a cache in the action.
This is normally configured in the actions/setup-node action on GH actions.

It doesn't look like bun has that, which is a bit disappointing because it feels like there might be an even deeper win here if that was available.

[xhyrom]

What do you mean by damage file? Saving dependencies/whole bun into cache?

[KyleSanderson]

When a file is damaged (changed), the cache should be dropped and refreshed.

setup-node calls it cache-dependency-path, which is a fine modern name I guess.

EDIT2: Yes please. If there was caching for the built dependencies subsequent runs would be even faster(?).

[Wazbat]

It might be possible to use github action's hashFiles expression to hash bun.lockb and package.json and use that as the cache key?

Alternatively shouldn't we just always cache the ~/.bun/install/cache folder?

[KyleSanderson]

It might be possible to use github action's hashFiles expression to hash bun.lockb and package.json and use that as the cache key?

Yeah, that seems reasonable (until there's a better option).

Alternatively shouldn't we just always cache the ~/.bun/install/cache folder?

You could, but it doesn't align to the other node projects. If there's no problem with it in bun that's fine, but the other products expressly look at this.

[Wazbat]

Alternatively shouldn't we just always cache the ~/.bun/install/cache folder?

You could, but it doesn't align to the other node projects. If there's no problem with it in bun that's fine, but the other products expressly look at this.

I haven't had a chance to use bun much yet, but from what I can see from the docs, it supposedly always downloads packages to that folder, then uses hardlinks to add the packages to the node_modules folder

If that's the case, then that's the only folder that needs to be cached. You could cache it with the same key every time, or use that same hashFiles expression to create a key, to stop the cache growing in size over time

[Electroid]

We haven't implemented dependency caching yet, because early testing showed bun install was faster than using Github's caching mechanism.

[ceIia]

can the hashFiles() technique really work? since the hash changes every time you run bun install :/
(i might completely be misunderstanding how caching in github actions is supposed to work)

[jylin]

I tested the solution mentioned above with:

- uses: actions/cache@v3
  with:
    key: key
    path: ~/.bun/install/cache

It reduces the bun install time from 10 seconds to 2 seconds, but the cache restore time is 8 seconds, so it's a bit of a wash.

[bgentry]

For me, this cache config adds 2 seconds to restore the cache and then drops my bun install time from 6-10s to <2s. Of course sometimes the cache restore takes longer due to network variability, but that variability impacts install time too if fetching all deps every time. Seems worthwhile overall to put something like this in by default (exact ideal key config is up for debate).

      - uses: actions/cache@v4
        with:
          path: ~/.bun/install/cache
          key: ${{ runner.os }}-${{ matrix.bun }}-bun-${{ hashFiles('**/bun.lockb') }}
          restore-keys: |
            ${{ runner.os }}-${{ matrix.bun }}-bun-