Add and export types with the Validation error string literal values

[joneubank]

Summary

Add additional type exports that contain the validation reason string literal types. These are derived from the Validation Error union types so if new validation rules are added the Reason types will inherit the added reasons.

Description of Changes

Validation

Added four new exported types which are unions of the error reason literals, for programmatic reference by importing libraries:

export type FieldValidationErrorReason = FieldValidationError['reason'];
export type RecordValidationErrorReason = RecordValidationError['reason'];
export type SchemaValidationErrorReason = SchemaValidationRecordErrorDetails['reason'];
export type DictionaryValidationErrorReason = DictionaryValidationError['reason'];

which resolve, at the moment, as:

type FieldValidationErrorReason = "INVALID_BY_RESTRICTION" | "INVALID_VALUE_TYPE";
type RecordValidationErrorReason = "INVALID_BY_RESTRICTION" | "INVALID_VALUE_TYPE" | "UNRECOGNIZED_FIELD";
type SchemaValidationErrorReason = "INVALID_BY_RESTRICTION" | "INVALID_BY_UNIQUE" | "INVALID_BY_UNIQUE_KEY" | "INVALID_VALUE_TYPE" | "UNRECOGNIZED_FIELD";
type DictionaryValidationErrorReason = "INVALID_RECORDS" | "UNRECOGNIZED_SCHEMA";

Readiness Checklist

• Self Review
  • I have performed a self review of code
  • I have run the application locally and manually tested the feature
  • I have checked all updates to correct typos and misspellings
• Formatting
  • Code follows the project style guide
  • Autmated code formatters (ie. Prettier) have been run
• Local Testing
  • Successfully built all packages locally
  • Successfully ran all test suites, all unit and integration tests pass
• Updated Tests
  • Unit and integration tests have been added that describe the bug that was fixed or the features that were added
• Documentation
  • All new environment variables added to .env.schema file and documented in the README
  • All changes to server HTTP endpoints have open-api documentation
  • All new functions exported from their module have TSDoc comment documentation

[leoraba]

🎉

[justincorrigible]

this PR adds four new *Reason type aliases to @overture-stack/lectern-validation, but they're not re-exported from @overture-stack/lectern-client. is that something we want to consider? the curated list in packages/client/src/index.ts (i.e. already re-exporting these other existing types like DictionaryValidationError, FieldValidationError, etc.) doesn't include these new ones.

consumers likely import exclusively from lectern-client, not lectern-validation directly, so importing e.g. DictionaryValidationErrorReason the same way they already import DictionaryValidationRecordErrorDetails may be helpful (otherwise cause an error, or worse split where they import things from).

[justincorrigible]

Circling back since this is the one item still open (#450 (review)), everything else here looks good now (the TSDocs are thorough, and the SchemaValidationErrorReason clarification makes sense). Concretely, not just "worth considering": any consumer importing from @overture-stack/lectern-client, which is how real consumers actually use this (confirmed in the lyric monorepo, for example), will hit a TS2305 trying to import any of the four new *Reason types, since packages/client/src/index.ts's re-export list wasn't updated alongside them.

Small fix: adding the four names to that list, but without it these types aren't actually reachable by the libraries this PR is meant to serve.

[justincorrigible]

Le squasharoo 🦘