feat: generator schema migration

[cristianoventura]

Description

This PR adds migrations to the generator schema, ensuring that changes to its structure remain backward-compatible. This allows the generator to work properly even when the schema is updated.

The pattern adopted in this PR is based on the settings migration #371.

How to Test

• make changes to the latest version of the schema /schemas/generator/v1/index.ts such as renaming a property.
• change the migrate function in /schemas/generator/v0/index.ts to return the new schema.
• make appropriate changes to the remaining implementation so the new schema is used. This may require changing the slices and several other parts of the code.
• ensure the generator JSON file has version: '0' and all old properties before testing.
• open the old generator file and check that options were migrated.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (npm run lint) and all checks pass.
• I have run tests locally (npm test) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Screenshots (if appropriate):

Related PR(s)/Issue(s)

Resolves #370

[allansson]

Migration logic works! 💯

One thing though. The following files are all a part of the schema so they should be moved to the v1 folder:

src/schemas/rules.ts
src/schemas/testData.ts
src/schemas/testOptions.ts

And the instructions should be to copy the entire schema in the v1 folder and rename it v2. If you don't copy, then you run the risk of changing previous versions of the schema e.g. by making changes to the TestOptionsSchema.

[cristianoventura]

@allansson Nice catch, I've missed those. I've now updated the schemas + the readme.

[going-confetti]

LGTM with a minor remark.
Apologies for changes requested - I only chose it because we recently merged an update to ESLint config and I wanted to make sure the branch is updated before merging.

[going-confetti]

v1 is essentially the same as v0 here, right? I don't understand what do we need the TODO comment for - is it for future non-breaking changes to v1? If so, I'd prefer a regular descriptive comment, so that TODOs are reserved for debt

[cristianoventura]

They are the same schema, but the implementation of the migrate function is incomplete because there is nothing to migrate to since v1 is the latest version.

The TODO comment here indicates that the implementation needs to change when another version exists (to migrate from v1 to v2).

[going-confetti]

While out of scope for this PR, I think we should explore autogenerating new schema versions in future - instead of manually creating a copy of the vN folder and its content, we'd be able to run something like whatever-code-gen-is-trendy-rn studio:generator and have it do it automatically.

[cristianoventura]

We can explore that separately and probably do the same for settings too! 👍