feat: Initial setup of a generic application type

[DafyddLlyr]

What does this PR do?

• Sets up a new schema, temporarily named "App", which models how we could make a more specific schema for various application types
• We can vary this based on either the primary or granular application type. In the example here I'm using just the primary application type (i.e. pp from pp.full.minor.technicalDetails)
• Uses dummy type and properties to illustrate how various primary application type based models could be used

Why is this necessary?

• This will allow us to vary which fields are required, based on application type
• As the schema has grown, more and more variables have been added which are application type specific. Out of necessity, many of these variables are currently optional as they're not provided on many user journey.
• A stricter and richer schema should be both easier to work with, and more meaningful to consumers.

Next steps...

• Test and peer-review this approach, and then work up some examples
• Expand this approach to cover the current DigitalPlanningApplication schema

[DafyddLlyr]

Before hitting on this I spent a bit of time working on constructing the list of keys using string literal types which was the approach we originally discussed.

type PrimaryAmendment = 'amendment';
type SecondaryAmendment = 'minorMaterial' | 'nonMaterial';
type Amendment =
  | PrimaryAmendment
  | `${PrimaryAmendment}.${SecondaryAmendment}`;

This felt like a pretty nice approach and did work (see tooltip in above screenshot), but had a few shortcomings compared to the approach using infer.

• It's a whole lot more verbose
• It lends itself very well to easily setting up a large number of permutations. Our list of application types doesn't match this pattern - for example the pp list has many unique combinations of secondary and tertiary keys.
• It makes the "enum" of application types harder to parse and understand (and maintain?)

Here's the infer approach in action -

[DafyddLlyr]

I've actually had to revisit this approach. Despite this being valid TypeScript, I've not found a meaningful way for ts-json-schema-generator to parse this - the combination of infer and template literal types isn't currently supported.

I've resorted to a more verbose, but perfectly workable, approach where we need to provide both the primary and granular variables.

[DafyddLlyr]

This is required to be above or at an equal hierarchy level of anywhere TGranular or TPrimary is passed in.

This means if we need variants based on TGranular or TPrimary outside of data.application (I think we do?), we can't just keep this in data.application.applicationType.

[DafyddLlyr]

TGranular is repeated here in order to make this change slightly less disruptive. Note that this is just the string value and not the value/description object (we could still support this!).

[DafyddLlyr]

@internal is required to not expose generic types when building the JSON schema, and to force ts-json-schema-generator to roll this up into its nearest parent type.

Here's what happens to the JSON schema if we remove the @internal notation -

Generic type exposed in the schema...

...as opposed to being included in its nearest parent

[DafyddLlyr]

This is a really neat solution (thanks again @jessicamcinchak!) and again points towards a simpler way of encoding enums, e.g.

type WTTApplicationType =
  /**
   * @description Something
   */
  | "wtt"
  /**
   * @description Something else
   */
  | "wtt.consent"
  /**
   * @description Something else again
   */
  | "wtt.notice";

type ApplicationType = WTTApplicationType | PPApplicationType | PAApplicationType;

export type WorksToTreesApplications = ApplicationSpecification<
  'wtt',
  WTTApplicationType
>

This would solve the issue of missing or mismatched types, and having to repeat them here, if they were just defined once. I'll take a closer look at this in another PR.

[jessicamcinchak]

A bit hard to review this one as I think a lot of your initial comments/questions are now outdated - but this looks really good and very nice to be able to play with this setup without fully replacing existing Application schema yet - so I say ready to merge/fix forward on main whenever 👍

[jessicamcinchak]

nit: can we call this "NextApp" or "TestApp" or "PrototypeApp" or something similar that makes it clear it's work-in-progress adn not just short-hand for existing "Application" ?

[DafyddLlyr]

Very good shout - will make this change before I merge.