Example of a PR where the labeling gets out of hands and spams the discussion page: systemd/systemd#40624

Hi 👋 thanks again for working on this — the option added in #923 to cap how many changed-files labels get applied is very useful for preventing label spam in large PRs.

One nuance though: it seems to address a slightly different problem than the original request in #486.

changed-files-limit currently limits how many labels are applied, while #486 was more about limiting labeling based on the overall size of the change (e.g., only apply file-based labels if fewer than N files changed).

Would you be open to extending this PR or adding a follow-up to support something like:

max-files-changed: N

If the total changed files exceed N, file-based labeling could be skipped entirely. This would align more closely with the original goal in #486 and also avoid unnecessary pattern scanning on very large PRs.

While reviewing the implementation and README, I also noted a few smaller suggestions:

1. Naming & Semantics

The name changed-files-limit can be somewhat ambiguous since it sounds like it limits the number of changed files, while it actually limits the number of labels generated by changed-files rules.

Suggestion

Consider renaming to something clearer like changed-files-labels-limit.

If renaming could break configs, we could support both names and treat changed-files-limit as a deprecated alias.

2. Stricter Configuration Parsing

The current parsing uses parseInt, which can silently accept invalid inputs.

Examples:

• "10abc" → interpreted as 10
• "3.2" → interpreted as 3

To make configuration validation stricter and safer:

• If the value is a string, require it to match /^\d+$/ before parsing.
• If the value is a number, validate with:

• Number.isInteger(value)
• Number.isFinite(value)

Potential tests:

• "10abc" → should throw an error
• "3.2" → should throw an error
• 3.2 (float) → should throw an error

3. Clarifying the Definition of a “Changed-Files Label”

One subtle behavior worth documenting is how the limit interacts with mixed rules.

Example:

changed-files-limit: 0

mixed-label:
 - any:
     - head-branch: "^test/"
     - changed-files:
         - any-glob-to-any-file: ["components/a/**"]

Even if the label matches via the branch rule, the presence of a `changed-files` rule causes it to be treated as a changed-files label and therefore subject to the limit.

It might help to document something like:

Any label definition that includes a `changed-files` rule is considered a changed-files label and is subject to changed-files-limit, regardless of which condition caused the label to match.

Adding a small dedicated test fixture could also help make this behavior explicit.

4. README Documentation

The new Configuration Options section is a great addition 👍. It might help to explicitly mention:

• The limit counts only new labels derived from changed-files rules (labels already present on the PR are ignored).
• Labels are skipped only when newChangedFilesLabels > limit. If newChangedFilesLabels === limit, they are still applied.
• If the limit is exceeded, all new changed-files labels are skipped for that run.
• Labels based on branch conditions (head-branch, base-branch) are not affected.

@chiranjib-swain thanks for the review, applied all suggestions and requests

Fixes the formatting issue (hopefully)

@chiranjib-swain anything else I can do here? Thanks

Hi @bluca ,Really nice work on this 👏 — the addition of max-files-changed is a great improvement and should help a lot in reducing label noise on large PRs.

🔹 Suggestion: Improve parseNonNegativeInteger

One small suggestion regarding parseNonNegativeInteger used here: https://github.com/bluca/labeler/blob/a07363b7e377762584a79fe87e6a744d5a385058/src/api/get-label-configs.ts#L33

Currently the regex check runs directly on the raw string value. This means inputs like " 30 " would be rejected even though they represent a valid integer. It might be worth trimming the string before applying the regex so that common whitespace cases are handled more gracefully.

Since the regex already guarantees that the string contains only digits, we could also use Number(trimmed) instead of parseInt. That avoids relying on parseInt’s permissive behavior while keeping the logic clear.

Finally, the non-negativity check (value < 0) could potentially be included directly in the numeric branch condition to simplify the validation flow slightly.

Something along these lines could work:

const trimmed = value.trim()

if (!/^\d+$/.test(trimmed)) {
  throw new Error(
    `Invalid value for '${optionName}': must be a non-negative integer (got '${value}')`
  )
}

parsed = Number(trimmed)

This is a fairly small refinement, but it could make the validation a bit more robust while keeping the current behavior intact.

🔹 Suggestion: Clarify Threshold Semantics

Additionally, one small suggestion regarding threshold semantics:

If both limits are introduced/configured (e.g., max-files-changed and changed-files-labels-limit), it might help to clearly define their interaction. For example:

When both are configured, max-files-changed is evaluated first. If it triggers, changed-files-labels-limit is not evaluated.

Documenting this precedence explicitly could help avoid confusion and make the behavior more predictable.

🔹 Suggestion: Reserved Keys Clarification

Using keys like max-files-changed as labels in .github/labeler.yml causes failures because they are treated as reserved config options and parsed as integers.

Currently, this results in an error like:

Invalid value for 'max-files-changed': expected a non-negative integer

We should either document these as reserved keys or improve the error message, e.g.:

'max-files-changed' is a reserved top-level option and cannot be used as a label. Please rename it.

🔹 Suggestion: PR Title Improvement

Your current title:
Add 'changed-files-labels-limit' and 'changed-files-labels-limit' configs to allow capping number of labels added

has a typo (the same option is repeated) and it doesn’t mention max-files-changed.

@chiranjib-swain thank you, updated as requested, PTAL

CI failures look to be unrelated (dependencies audit)

Thanks for the improvements here — the new caps for changed-files labeling look really useful, especially for large refactors.

One thing before we can proceed: the dist check is currently failing on this PR. Could you please re-run the build step that generates the dist/ artifacts and commit the updated output so the check passes?

Also, small docs nits for clarity:

• Could we use “Pre-existing labels” (hyphenated) instead of “Preexisting”?
• Could we add a NOTE clarifying that when both max-files-changed and changed-files-labels-limit are set, max-files-changed is evaluated first, and if it triggers then changed-files-labels-limit is not evaluated?

Thanks again!

Hi - I've ran npm run build but it generates no diff for me? The file stays the same

Could we use “Pre-existing labels” (hyphenated) instead of “Preexisting”?

Changed

Could we add a NOTE clarifying that when both max-files-changed and changed-files-labels-limit are set, max-files-changed is evaluated first, and if it triggers then changed-files-labels-limit is not evaluated?

There already is:

If both `max-files-changed` and `changed-files-labels-limit` are configured at the same time, `max-files-changed` is evaluated first, and if it triggers, `changed-files-labels-limit` is not evaluated.

Would you like me to reword it or move it?

Hi - I've ran npm run build but it generates no diff for me? The file stays the same

This is on Debian unstable with NPM 9.2.0

Hi @bluca

The Labeler repository now officially runs on Node.js 24, as reflected in its workflows and documentation.

Please use Node.js version 24 / npm version 11+ when running the command to ensure the check dist workflow passes.

Hi @bluca

The Labeler repository now officially runs on Node.js 24, as reflected in its workflows and documentation.

Please use Node.js version 24 / npm version 11+ when running the command to ensure the check dist workflow passes.

@HarithaVattikuti got it thanks, rerun with npm 11.12.0 and now it did update it, pushed it