[kwy404]

Closes #1315

Changing the exports of a package (or its type, main, imports or name) can change what a build produces, but Wireit didn't notice: no input file changed, so the script was skipped as fresh or restored from cache, which hid the broken build described in the issue. The only workarounds were listing the whole package.json as an input, which invalidates on every unrelated edit, or extracting fields into separate files.

Following @aomarks's suggestion in the issue, the fingerprint now automatically includes the behavior-affecting fields from the Node.js package.json field definitions: name, main, type, exports and imports. As discussed there, the list is not configurable.

How it works

• PackageJson reads the values of those fields once, when the file is analyzed.
• The analyzer stores them on each script config as packageJsonFields.
• Fingerprint.compute adds them to the fingerprint data, so they are also part of the local and GitHub Actions cache keys. Because dependency fingerprints cascade, scripts that depend on the package's scripts run again too.

Other fields, such as description or version, are still ignored, so editing them doesn't cause re-runs. Since the fingerprint has a new field, each script runs once more (or misses the cache once) after upgrading.

Example

{
  "name": "my-lib",
  "exports": {".": "./lib/index.js"},
  "scripts": {"build": "wireit"},
  "wireit": {
    "build": {
      "command": "tsc",
      "files": ["src/**/*.ts"],
      "output": ["lib/**"]
    }
  }
}

Editing exports now makes build stale, and scripts that depend on build run again as well.

Tests and docs

• freshness.test.ts: changing each of the five fields makes the script stale, and changing another field (description) keeps it fresh.
• README: the new input in the Fingerprint section. CHANGELOG: an entry under Unreleased.