-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: save generator after migration #400
Conversation
generatorStateData: Partial<GeneratorFileData>, | ||
generatorFileData: Partial<GeneratorFileData> | ||
) => { | ||
// Convert to JSON instead of doing deep equal to remove |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a question not related to this particular PR:
I think it shouldn't be a problem here, but since JSON.stringify does not guarantee the order of keys, can two equal objects be considered unequal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's possible. We might want to switch to isEqual
if this proves to be a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC, I've used JSON.stringify because generatorFileData would include all the undefined values, but stored JSON wouldn't have them, and if would show up as false dirty. So we'd need to do some cleanup if we switch to isEqual
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works like a charm! 🙌 Though, I'm a bit worried about the "hidden" write operation when opening a generator. If we mess up a migration, could this lead to broken generators? Without this change it would still break them on save, but I imagine that would be less impactful, because failing to open a generator I would try others, corrupting them as well.
As an alternative to consider: could we migrate in memory while doing the isDirty
check, without writing anything to the file? And only save new migrated version to file after user modified and saved generator.
This sounds like a reasonable and neat solution 👀 |
This reverts commit 4ea95b6.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed the hidden write operation and let Zod to parse the state internally.
options: generator.options, | ||
testData: generator.testData, | ||
rules: generator.rules, | ||
allowlist: generator.allowlist, | ||
includeStaticAssets: generator.includeStaticAssets, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue was actually related to the order of the fields in the migration, which caused the JSON.stringify
comparison to return false
. I made a ticket to address this behaviour #403
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
Description
This PR fixes an issue where the UI detects changes in the generator if it has been migrated during runtime.
How to Test
version
property of a generator to0
version: 1.0
Checklist
npm run lint
) and all checks pass.npm test
) and all tests pass.Screenshots (if appropriate):
Screen.Recording.2025-01-09.at.12.27.46.PM.mov
Related PR(s)/Issue(s)
Resolves #399