Too much configuration required

This is the suggested configuration to cache npm:

    - name: Cache node modules
      uses: actions/cache@v1
      with:
        path: node_modules
        key: ${{ runner.OS }}-build-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.OS }}-build-${{ env.cache-name }}-
          ${{ runner.OS }}-build-
          ${{ runner.OS }}-

This is the suggested configuration to cache npm on Travis:

Not a mistake. It’s empty. It’s the default.

Can better defaults be provided? GitHub Actions workflows are 5x to 10x longer than Travis’ for the most common configurations.

[fregante]

Any code not in my repo is code I don’t have to maintain. If GitHub comes up with a better way to cache dependencies it can apply it to everyone. If I copy-paste that one to my repo it will become my code.

You can make it both powerful and have sensible defaults.

1. Could it detect and cache npm if it was called without arguments?
2. Could it cache npm/yarn with with: {node: true}
3. Could GitHub also wrap this action into another dependencies-specific action (which would include config for most languages)?

I’m sure many specific caching actions will pop up in userland soon enough if you don’t make one, with varying degrees of quality, but your docs will still suggest that wordy configuration if there isn’t an official one.

[kcgen]

@chrispat: I am curious. Other than pure aesthetics why is shorter better?

I mean this with the most respect: I’m baffled to see an employee of a progressive software company not understand and even question the validity of this principle. The best code is no code at all, followed next by the least amount of maintainable code.

The principle of “shorter is better” is at the heart of most computer and software endeavours: from language design (assembly -> compiled -> interpreted), to concepts like “KISS”, “lean”, “agile”, and “elegance”. It drives UI design and hardware interface design. It’s influenced markup language evolution from GML -> SGML -> XML -> Json/YAML. There’s a /lot/ more at stake here than apples vs. oranges aesthetics!

In this case, we’re talking about the cache’s required boiler-plate: is it possible to reduce it further?

Perhaps key: could be optional, in which case it could be derived from path: and a logical Boolean used to invalidate/save a new cache. Perhaps path: could then be moved out of the with: block, eliminating the need for that entirely (unless with: is an imposed constraint by the workflow system).