fix(enum-values): access optional prop child props

[darkbasic]

Changes

Fixes #2138 and #2140

How to Review

How can a reviewer review your changes? What should be kept in mind for this review?

Checklist

• Unit tests updated
• docs/ updated (if necessary)
• pnpm run update:examples run (only applicable for openapi-typescript)

[netlify]

👷 Deploy request for openapi-ts pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	b2e45cd

[changeset-bot]

⚠️ No Changeset found

Latest commit: b2e45cd

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

[darkbasic]

I've committed some further modifications to handle corner cases like the following that I've found in my codebase:

FormFieldBulkStoreRequest: {
    data: {
        composite_fields?: {
            type: "TextSingleLine" | "TextMultiLine" | "Integer" | "Boolean" | "Date" | "Datetime" | "Reference" | "Asset";
        }[] | null;
    }[] | null;
};

[duncanbeevers]

I'm not for this approach.

Currently we export consts which reference into the existing types.
This PR continues with that approach, layering on a utility type to deal with the complexity of keying into those existing types.

Instead, the consts themselves should represent the basis for the type, and the paths / operations / components structures should reference the types derived from those concrete values.

This is the approach I've already taken in #2051, so I'll prioritize making those changes backwards-compatible with the 7.x branch, which should address both #2138 and #2140.

[darkbasic]

I definitely prefer your approach, I just aimed for the easiest and quickest solution.
Does #2051 fix #941? The enum could be used to compute the union types used in paths / operations / components from its keys.

[duncanbeevers]

I think #2051 doesn't address #941 as it expresses the concrete values as const array, and side-steps indexed access.
However, the plan is to change the representation to a const object with symmetric keys + values, and one driver of that is the desire to enable the namespace-like access.

There's still open discussion about naming.
One possibility is overloading the names, (eg; Prisma approach)
Another is exposing the type and the concrete value with distinct names.

[darkbasic]

@duncanbeevers why don't we base everything on top of the enum?

export enum StatusEnum {
  ACTIVE = 'active',
  INACTIVE = 'inactive'
}
export type Status = `${StatusEnum}`
export const StatusValues: Status[] = Object.values(StatusEnum)
export interface components {
  schemas: {
    Status: Status
  }
}

The approach is the same of your PR but you get #941 for free.