(client-utils): make layer compat policy window names explicit - #28067
(client-utils): make layer compat policy window names explicit#28067Navin Agarwal (agarwal-navin) wants to merge 1 commit into
Conversation
The members of LayerCompatibilityPolicyWindowMonths were named by adjacent-layer pair alone, so which layer is the newer one and which is the older one was conveyed only by word order. DriverLoader and LoaderDriver differ solely in that ordering, and at a call site such as `generation - LayerCompatibilityPolicyWindowMonths.DriverLoader` the intended direction is not obvious. Each member now names both sides explicitly: DriverLoader -> NewDriverOldLoader LoaderDriver -> NewLoaderOldDriver RuntimeLoader -> NewRuntimeOldLoader LoaderRuntime -> NewLoaderOldRuntime RuntimeDataStore -> NewRuntimeOldDataStore DataStoreRuntime -> NewDataStoreOldRuntime The values are unchanged, so every call site resolves to the same number and there is no behavior change. A typeValidation broken entry is added for Variable_LayerCompatibilityPolicyWindowMonths because the exported shape of the object changed. Follow-up to review feedback on microsoft#27516.
|
Hi! Thank you for opening this PR. Want me to review it? Based on the diff (79 lines, 9 files), I've queued these reviewers:
How this works
|
There was a problem hiding this comment.
Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Bundle size comparisonBase commit: Notable changesNo bundles changed by ≥ 500 bytes parsed. Per-bundle deltas
|
Mark Fields (markfields)
left a comment
There was a problem hiding this comment.
LGTM, thanks!
| * "Variable_LayerCompatibilityPolicyWindowMonths": {"backCompat": false} | ||
| */ | ||
| // @ts-expect-error compatibility expected to be broken | ||
| declare type current_as_old_for_Variable_LayerCompatibilityPolicyWindowMonths = requireAssignableTo<TypeOnly<typeof current.LayerCompatibilityPolicyWindowMonths>, TypeOnly<typeof old.LayerCompatibilityPolicyWindowMonths>> |
There was a problem hiding this comment.
Why do we have type tests for internal exports?
Description
LayerCompatibilityPolicyWindowMonthsdefines the support window for each layer boundary, but its members were named by adjacent-layer pair alone —DriverLoader,LoaderDriver,RuntimeLoader,LoaderRuntime, and so on. Which layer is the newer one and which is the older one was conveyed only by word order, andDriverLoader/LoaderDriverdiffer solely in that ordering. At a call site likegeneration - LayerCompatibilityPolicyWindowMonths.DriverLoader, the intended direction is easy to misread.Each member now names both sides explicitly:
DriverLoaderNewDriverOldLoaderLoaderDriverNewLoaderOldDriverRuntimeLoaderNewRuntimeOldLoaderLoaderRuntimeNewLoaderOldRuntimeRuntimeDataStoreNewRuntimeOldDataStoreDataStoreRuntimeNewDataStoreOldRuntimeThe values are unchanged, so every call site resolves to the same number and there is no behavior change. All 16 references are updated across the Loader, Runtime and DataStore layer-compat state files, plus the three Driver ones added by #27516 (
local-driver,odsp-driver,routerlicious-driver), along with the doc comments that name the constant.Variable_LayerCompatibilityPolicyWindowMonthsis added totypeValidation.brokenin@fluid-internal/client-utilsbecause the exported shape of the object changed.LayerCompatibilityPolicyWindowMonthsis@internaland appears in no API report, so there is no customer-facing API change and no changeset.Follow-up to review feedback on #27516 (comment).
Reviewer Guidance
The review process is outlined in the pull request guidelines.
This is a pure rename — no values, logic, or documentation changed. The one judgment call worth a look is casing:
NewDriverOldLoader(PascalCase) keeps continuity with the previousDriverLoaderstyle, though some const-object "enums" in the repo (e.g.FluidErrorTypes) use camelCase instead.