[request] Option to include additional fields in package.json in fingerprint.

[filimon-danopoulos-stratsys]

I've had an issue recently where I changed the exports of a package in a monorepo. I expected this to invalidate the cache so that a build would fail but the build restored from cache instead masking the issue.

Work arounds

1. Add the entire package.json as input. This invalidates the cache way to often. E.g. changing the linting script will invalidate the build script's cache.
2. Manually extracting parts of package.json into separate files and depending on those.

{
  "scripts": {
    "build": "wireit"
    "extract-meta": "wireit"
  },
  "wireit": {
    "build": {
      "command": "tsc",
      "dependencies": [{
        "script": "extract-meta",
        "cascade": false
      }],
      "input": [
        "src/**",
        "meta/**"
      ],
       "output": [
         "dist/**",
         "typings/**"
       ]
    },
    "extract-meta": {
       "command": "node extract-meta.js",
       "input": [
         "package.json",
         "extract-meta.js"
       ],
       "output": [
         "meta/**"
       ]
     }
   }
}

This becomes verbose and error prone.

Suggestion

Include an option packageJsonFields (or similar) that allows us to include arbitrary package.json fields in the fingerprint. This reduces the configuration to:

{
  "scripts": {
    "build": "wireit"
  },
  "wireit": {
    "build": {
      "command": "tsc",
      "packageJsonFields": [
        "exports"
      ],
      "input": [
        "src/**",
        "meta/**"
      ],
       "output": [
         "dist/**",
         "typings/**"
       ]
    }
   }
}

Apart from solving the exports issue I faced it also allows other tools that use package.json for storing settings to be fingerprinted more efficiently with wireit.

[mimshins]

This feature holds significant promise for our workflow! It will be particularly valuable when dealing with intricate package.json scripts. The ability to invalidate caches based on specific script modifications will undoubtedly be a game-changer in those scenarios.

[aomarks]

Very good point. I think we should automatically include all of the behavior-affecting fields of package.json files in the cache key. The list at https://nodejs.org/api/packages.html#nodejs-packagejson-field-definitions seems right (name, main, type, exports, imports).

I'm not sure we need to allow the user to customize this, can you think of any fields you might want to include that aren't in that list?

[filimon-danopoulos-stratsys]

I don't have any usecase outside of those. For any complex scenario involving other package.json fields it is possible to extract that info in the manner I do in workaround 2.