refactor(transformations): simplify schema inheritance and split files #1143
+162
−182
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.
This refactors the transformation schema definitions to be cleaner and more maintainable, without changing any actual schema shapes or migration behavior.
The original structure used shared "Base" types (
TransformationStepBase,TransformationBase) that both V1 and V2 derived from. This was defensive design for a hypothetical V3 that might need different base fields, but added unnecessary indirection.The new structure uses direct inheritance: V1 defines all fields inline, V2 extends V1 via
.merge(). This reads more naturally and follows YAGNI. The file is also split intotransformation-steps.tsandtransformations.tsto separate concerns.Changes:
TransformationStepBase: V1 now defines all fields directly, V2 extends V1TransformationBase: TransformationV1 defines container + steps, V2 extends V1TransformationV1is now an arktype validator (was plain TypeScript type)Transformation,TransformationStep) instead of explicit V2migrateStepV1ToV2function into the.pipe()callbackVerified that all schema shapes and migration behavior are unchanged.