feat: Add Pre-Commit Copyright Date Check & Fix Automation

[SteinGabriel]

Summary

Automates Ping-owned copyright year updates so developers no longer need
to hand-edit headers. A pre-commit hook fixes and re-stages any staged
files with stale Ping copyright years before lint and build checks run.

Adds a pre-commit hook that automatically keeps Ping-owned copyright
year headers up-to-date in staged files, removing the need for manual
year updates on every change.

Changes

File	Change
tools/copyright/sync-header-years.mjs	New script — fix/check logic
tools/copyright/sync-header-years.test.mjs	9 unit tests (Node built-in runner)
.husky/pre-commit	Prepend copyright sync step
package.json	Add copyright:sync and copyright:check scripts

How it works

1. On git commit, the pre-commit hook reads the list of staged files.
2. For each file it finds a stale Ping copyright year, it rewrites the
   header in place and re-stages the file.
3. If any staged file has a Ping copyright header with no recognisable
   year at all, the commit is aborted with an error listing the incorrect files.
4. All other files (non-Ping headers, binary, unreadable) are skipped.

Supported formats updated automatically:

Copyright 2020 Ping Identity. → Copyright 2020 - 2026 Ping Identity.
Copyright 2020-2024 Ping Identity. → Copyright 2020 - 2026 Ping Identity.
Copyright 2020-2026 Ping Identity. → Copyright 2020 - 2026 Ping Identity.
© Copyright 2020 - 2024 PingIdentity. → © Copyright 2020 - 2026 Ping Identity.
Copyright (c) 2023 - 2024 Ping Identity Corporation. → Copyright (c) 2023 - 2026 Ping Identity Corporation.

Testing

  node --test tools/copyright/sync-header-years.test.mjs

Known gaps / follow-ups

• CI enforcement (copyright:check on PRs) deferred to a follow-up.

Rollout notes

• No CI step added — pre-commit only for now.
• Removing the hook does not break anything; it is additive only.

[changeset-bot]

⚠️ No Changeset found

Latest commit: b780c49

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[nx-cloud]

View your CI Pipeline Execution ↗ for commit b780c49

Command	Status	Duration	Result
nx affected -t build lint test docs e2e-ci	✅ Succeeded	<1s	View ↗
nx-cloud record -- nx format:check --verbose	✅ Succeeded	6s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-03-18 19:01:22 UTC

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/ForgeRock/forgerock-javascript-sdk/@forgerock/javascript-sdk@583

pnpm add https://pkg.pr.new/ForgeRock/forgerock-javascript-sdk/@forgerock/ping-protect@583

pnpm add https://pkg.pr.new/ForgeRock/forgerock-javascript-sdk/@forgerock/token-vault@583

commit: b780c49

[ancheetah]

This is amazing. Thank you for doing this Gabriel! Will save us a lot of time. Just left a comment on the tests.

[ancheetah]

In a lot of these tests the input looks identical to the value being asserted. For example, in this test shouldn't the input have something like years 2020 - 2025 before it is updated?

[SteinGabriel]

I could swear I had this right and I was loosing my mind wondering why my input date updates weren't showing up, until I realized that the pre-commit script was actually "fixing" the input date header in the test files, making it the same as the value being asserted. lol
Anyways, I added a check to prevent it from running on specific paths, such as test files. Thanks for pointing it out!

[ryanbas21]

This is cool. I'd like us to weigh this approach versus https://www.npmjs.com/package/eslint-plugin-license-header as an eslint rule with auto fixing.

Could you, when available to, maybe present the differences / overlap / benefits to each approach? Maybe theres a better eslint rule out there also, I just happened to find this one and it seems up to date / maintained.

[SteinGabriel]

This is cool. I'd like us to weigh this approach versus npmjs.com/package/eslint-plugin-license-header as an eslint rule with auto fixing.

Could you, when available to, maybe present the differences / overlap / benefits to each approach? Maybe theres a better eslint rule out there also, I just happened to find this one and it seems up to date / maintained.

The main limitation I can see is that ESLint rules enforce a fixed template. They are great at spotting missing headers, but they cannot keep the start year and only bump the end year. If we used a standard rule, I think we would lose our start years (e.g., 2020–2025 would become 2026). The pre-commit script is much more flexible for those range updates. Also, we have some pattern variation in the headers (such as Copyright (c), © Copyright, and © Copyright) which an ESLint rule might not handle.

That being said, ESLint rules could add value in enforcing header presence on new files. We could have an ESLint rule scoped to detecting missing headers only (with auto-fix disabled for year ranges), while keeping this pre-commit script for year updates.

[ryanbas21]

(e.g., 2020–2025 would become 2026).

I think this is actually okay. I'm not 100% sure if the year range is a hard requirement. I think adding both could be valuable though, even if we don't allow the eslint rule to autofix.