feat(validator): add ValidationContext type and support optional context in validate()

[daine]

📝 Summary | Résumé

When reviewing the PR that introduces the new format (iso) for DateInput, I noticed that we can't support a "format" check for the DateInput validator. I think it'll be great to add support for different formats in the validator code itself and not the component code so it can be re-used by other components.

This PR introduces a ValidationContext type to support passing additional contextual information into validation logic, (i.e. the component and other validation parameters).

It also updates the validation API from:

validate(x)

to:

validate(x, context?)

This change is backwards compatible. Existing functionality is not affected because the new context argument is optional and supported through TypeScript function overloading.

This change is needed to make validation logic more flexible and easier to extend without changing any code that uses the existing validate function. By providing contextual information to validators, we can support more component-aware validation behaviour and reduce the need for ad hoc patterns or future API changes.

No screenshots are included because this change is internal/API-focused and does not introduce a visual change.

🧩 Related Issues | Cartes liées

Related issues

• feat: yyyy-MM-dd date input #969
• PR feat(gcds-date-input): add ISO date format #996

🧪 Test instructions | Instructions pour tester la modification

1. Check the current behaviour

• Checkout the main branch
• Run npm install
• Run npm run test
• Confirm all tests pass

2. Validate the change

• Checkout this branch
  • gh pr checkout <pr_number> or
  • git checkout -b feat/update-validator
• Run npm install
• Run npm run test
• Confirm all tests still pass
• Confirm new test passes
• Confirm no regressions in existing validation behaviour

✍️ Author checklist | Liste de vérification de l'auteur

Choose one:

• This PR is a patch (use fix:)
• This PR introduces a minor change (use feat:)
• This PR introduces breaking changes to the API (use feat!:)
• This PR does not introduce changes that need to be published on NPM (use chore:, docs:, ci:)

Breaking changes flag:

• This PR does not break existing functionality. I have completely tested the functionality of these changes.
• This PR does not introduce any changes to component names, properties, values, or behaviour.
• If this PR introduces API or behaviour changes, backwards compatibility has been implemented and documented under Impact and Risks.
• If this PR introduces a breaking change, release notes and versioning have been prepared.

Ready for review: (all items must be checked)

• I have tested the English and French versions of the changes, and can verify that all content is accurate and properly displayed in both languages. (not applicable)
• I have tested these changes on mobile viewports. (not applicable)
• I have tested these changes across multiple supported browsers. (not applicable)
• I have checked accessiblity and ensured all accessiblity tests pass. (not applicable)
• I have added tests for added functionality or changed existing tests, as needed.
• I have added or updated documentation, if needed. (not applicable, but I can let content design know since they're working on form validation)
• For visual or design-affecting changes, I have posted in dev-design slack channel. (not applicable)
• Visual or content changes remain aligned with design tokens and component API standards.
• Test instructions are clear and reproducible.

🧐 Reviewer checklist | Liste de vérification du réviseur

Developer checklist

For PRs that are complex, in lieu of a simple approval or an "LGTM" ✅, paste the following info with your approval:

• I have tested the changes and functionality using the test instructions.
• I have confirmed test coverage is adequate.
• I have reviewed the code for clarity, maintainability and potential issues.

Design checklist (if needed)

For designers, include the following info with your approval:

• I have tested the changes and functionality using the test instructions.
• The changes meet design expectations and align with the design system.
• Any design inconsistencies have been raised on slack or tracked via an issue.

Content checklist (if needed)

For content, include the following info with your approval:

• I understand the context and intent of the content changes.
• I have reviewed all content for clarity, readability, and tone.
• I have reviewed English and French content for accuracy and parity.

⚠️ Impact/Risks | Risques

This PR introduces a small API expansion to the validate() function by allowing an optional context argument to be passed into validate().

There are no breaking changes:

• existing calls to validate(x) continue to work as before
• the new argument is optional
• backwards compatibility is maintained through TypeScript overloads

[radmorecameron]

This PR is great 😄

One thing, for full it should probably be:

Suggested change

	requiredDateInput.validate('1991-13', {
	requiredDateInput.validate('1991-13-', {

[daine]

I updated the test to cover both scenarios, and added some tests for compact too :D Thanks for the review, appreciate it!

[ethanWallace]

LGTM

• I have tested the changes and functionality using the test instructions.
• I have confirmed test coverage is adequate.
• I have reviewed the code for clarity, maintainability and potential issues.