You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optionality transforms currently inherit versioning history that can reject their output or undo it in older snapshots. Comparing source and result is insufficient: making an already-optional property optional still needs to override its historical requiredness.
This is the explicit structural-override prototype for #11592, an independent alternative to #11968, not a follow-up to merge alongside it.
Transforms express intent through an experimental compiler API:
OptionalProperties<T> adopts this contract. Versioning consults override provenance rather than recognizing helper names, so both @madeRequired and already-optional @madeOptional properties stay optional through is, spreads, and version snapshots. Required overrides work symmetrically. Unrelated history remains intact, and newly authored optionality annotations still apply and are validated.
Design trade-off: this adds compiler cloning and decorator-replay support instead of inferring intent from boolean differences. Custom transforms must adopt the API and decorators must pass their context; direct assignments do not record semantic overrides. This is an optionality-only experiment, not a general metadata-invalidation or derivation-replay framework.
Add experimental explicit optionality overrides for derived properties. Overrides retain same-value transform intent and inherited annotation provenance through compiler and typekit cloning.,> ,> ts,> import { unsafe_overridePropertyOptionality } from "@typespec/compiler/experimental";,> ,> // In a decorator, pass its context so cloning does not repeat the transform.,> unsafe_overridePropertyOptionality(derivedProperty, true, context);,>
Keep OptionalProperties properties optional in every version, including spreads and properties already made optional. Honor explicit structural overrides instead of inherited @madeRequired and @madeOptional history, while preserving presence, rename, and type history and validating newly authored annotations.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Optionality transforms currently inherit versioning history that can reject their output or undo it in older snapshots. Comparing source and result is insufficient: making an already-optional property optional still needs to override its historical requiredness.
This is the explicit structural-override prototype for #11592, an independent alternative to #11968, not a follow-up to merge alongside it.
Transforms express intent through an experimental compiler API:
OptionalProperties<T>adopts this contract. Versioning consults override provenance rather than recognizing helper names, so both@madeRequiredand already-optional@madeOptionalproperties stay optional throughis, spreads, and version snapshots. Required overrides work symmetrically. Unrelated history remains intact, and newly authored optionality annotations still apply and are validated.Design trade-off: this adds compiler cloning and decorator-replay support instead of inferring intent from boolean differences. Custom transforms must adopt the API and decorators must pass their context; direct assignments do not record semantic overrides. This is an optionality-only experiment, not a general metadata-invalidation or derivation-replay framework.