Skip to content

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

Merged
merged 42 commits into from
Apr 10, 2025
Merged

feat: Add hs app migrate command #1406

merged 42 commits into from
Apr 10, 2025

Conversation

joe-yeager
Copy link
Contributor

@joe-yeager joe-yeager commented Mar 21, 2025

Description and Context

This PR does the following:

  • Deprecates hs project migrate-app and hs project clone-app
  • Moves the hs project migrate-app command to a new command hs app migrate
  • Adds a --platform-version flag to both commands that when added migrates the app to revamped API
  • Adds the functionality to migrate a non-projects app to the revamped API

Testing steps

  • Create a non project app inside a Developer account, and leave it empty. Don't add any components, currently only empty apps are allowed as apps is the only team that has onboarded to the system.
  • Auth into that account and run hs app migrate --platform-version unstable
  • Select the app you would like migrate and confirm what component types will be migrated
  • Follow the prompts and enter a project name, a dest for the source code
  • You will be prompted to enter a UID for your application, enter one and hit enter
  • Wait for the migration to complete and it should download the source code in the provided location

@joe-yeager joe-yeager requested a review from j0b0sapi3n March 25, 2025 15:54
@joe-yeager joe-yeager changed the title Jy/migration v2 feat: Add hs app migrate command and hs project migrate command Apr 3, 2025
@joe-yeager joe-yeager changed the title feat: Add hs app migrate command and hs project migrate command feat: Add hs app migrate command Apr 3, 2025
@joe-yeager joe-yeager marked this pull request as ready for review April 7, 2025 18:45
@joe-yeager joe-yeager requested a review from kemmerle April 7, 2025 22:51
process.exit(EXIT_CODES.ERROR);
}

await trackCommandMetadataUsage(
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor Author

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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@brandenrodgers brandenrodgers left a 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

@joe-yeager joe-yeager merged commit ffe7e32 into main Apr 10, 2025
1 check passed
@joe-yeager joe-yeager deleted the jy/migration-v2 branch April 10, 2025 22:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants