Allow excluding fields from inferred package.json input in @nx/js/typescript (and other inferred-input plugins)

[ryan-mcginty-alation]

Summary

The @nx/js/typescript plugin unconditionally adds {projectRoot}/package.json as a raw file input to every inferred typecheck task. In a workspace using nx release with projectsRelationship: "fixed", every release commit bumps the version field of every published package.json, busting the typecheck cache for every affected project even though the version field has zero effect on the typecheck output.

It would be great if the plugin accepted an option to use field-based hashing ({json: ..., excludeFields: [...]}) for the package.json input it emits, so that volatile-but-irrelevant fields like version could be excluded.

Why this matters

Nx already supports field-based hashing on namedInputs and explicit inputs arrays. We use this in our own default named input today:

"namedInputs": {
  "default": [
    "{projectRoot}/**/*",
    "!{projectRoot}/package.json",
    {
      "excludeFields": ["version"],
      "json": "{projectRoot}/package.json"
    },
    "sharedGlobals"
  ]
}

This works perfectly for lint (["default", "{workspaceRoot}/eslint.config.mjs"]) and test targets that reference default/production. Release version-bumps no longer invalidate caches for those targets, while non-version edits (dependencies, peerDependencies, main, exports, etc.) still do — which preserves correctness for @nx/dependency-checks and other rules.

But for typecheck, the plugin-inferred input list bypasses our namedInputs entirely. The relevant code is in @nx/js/src/plugins/typescript/plugin.js (paraphrasing the current shape):

const inputs = [];
if (includePaths.size) {
  if (existsSync(join(workspaceRoot, config.project.root, "package.json"))) {
    inputs.push("{projectRoot}/package.json");   // raw file string — no field-based form
  }
  inputs.push(...configFiles, ...includePaths);
}

The pushed string is a bare "{projectRoot}/package.json", so version is hashed. The TscPluginOptions interface exposes compiler, typecheck.targetName, typecheck.configName, build, verboseOutput — no inputs override.

Why a workspace-level workaround is brittle

targetDefaults.typecheck.inputs is documented to replace plugin-inferred inputs, not merge. To avoid hashing version, a workspace would have to fully replicate the plugin's inferred input set (~28–46 entries depending on whether the project has Storybook etc.) and hand-maintain it across nx version bumps. That works once but freezes a one-size-fits-all input list for every project, losing per-project tailoring (the plugin generates the list from each project's own tsconfig.lib.json include/exclude patterns).

Proposed API

Extend TscPluginOptions.typecheck with an optional field hashing config that the plugin would apply when emitting the package.json input:

interface TscPluginOptions {
  typecheck?: boolean | {
    targetName?: string;
    configName?: string;
    packageJsonInput?: {
      excludeFields?: string[];   // e.g. ["version"]
      // or fields?: string[];   // allowlist form, mirroring existing JSON-input schema
    };
  };
  // ...
}

Usage:

{
  "plugins": [
    {
      "plugin": "@nx/js/typescript",
      "options": {
        "typecheck": {
          "targetName": "typecheck",
          "packageJsonInput": { "excludeFields": ["version"] }
        }
      }
    }
  ]
}

The plugin would then emit {json: "{projectRoot}/package.json", excludeFields: ["version"]} instead of the raw string, leaving the rest of the inferred input set untouched.

The same shape would be useful on other inferred-input plugins (e.g. @nx/eslint/plugin, @nx/vite/plugin, @nx/playwright/plugin) that may include package.json in their inferred input lists.

Alternatives considered

• Workspace-level targetDefaults.typecheck.inputs — full replacement, brittle to plugin upgrades and per-project shape divergence. Rejected.
• Static placeholder version in source, inject at publish time — incompatible with nx release (git: { commit: true, tag: true } writes the bumped version to source).
• paths mappings in tsconfig.base.json — doesn't change which files the plugin hashes; the plugin emits package.json as an input regardless of TS resolution strategy.

Use case context

We use nx release with fixed-version projects relationship. Releases happen 1–2× per day. Every release commit bumps the version field of every release-managed package.json. With the workspace-level fix above, lint and test caches survive this cleanly. typecheck is the only remaining target busting on pure-version flips, and we can't fix it without owning a per-workspace fork of the plugin's inferred input list.