-
Notifications
You must be signed in to change notification settings - Fork 66
feat: Add hs app migrate
command
#1406
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
Conversation
hs app migrate
command and hs project migrate
command
hs app migrate
command and hs project migrate
commandhs app migrate
command
process.exit(EXIT_CODES.ERROR); | ||
} | ||
|
||
await trackCommandMetadataUsage( |
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'm not sure what the best way to do this would be, but it might be nice to be able to differentiate between this new migration and the soon-to-be-deprecated one in our tracking
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.
Yeah, maybe I could add a tracking to the hs project migrate-app
handler that is like migrate-app-deprecated
? That seems kind of gross, but we can at least subtract those from the migrate-app
total and get an idea.
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.
Yeah something like that could work. You could also call this one app-migrate
and differentiate that way
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.
But the more I think about it. Maybe it's not really important to differentiate. I'm not sure if we'd even need that info
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.
Gotcha, I'll leave it alone as is. Actually in hindsight, we are going to deprecate and delete hs project migrate-app
so once we release the next major we will only have hs app migrate
projectName?: string; | ||
} | ||
|
||
export interface MigratableApp extends BaseMigrationApp { |
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.
Should these go in the types/
folder?
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 left them here because we don't really seem to have a hard a fast rule for putting them in the types/
folder. We seem to have types living in files next to the methods that use them as return types, so I went this that approach since they don't really make sense as standalone types.
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 being said I don't have a strong opinion and if we want to move this to types LMK and I will move them in a follow up, going to merge this as is.
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! I ran through some local tests and it all seems to be WAD
Description and Context
This PR does the following:
hs project migrate-app
andhs project clone-app
hs project migrate-app
command to a new commandhs app migrate
--platform-version
flag to both commands that when added migrates the app to revamped APITesting steps
hs app migrate --platform-version unstable