I want you to design a plan to convert the two repositories in this workspace into a mono repo. The two repositories:
qpp-submissions-feedback-api: A NestJS based Node serverqpp-submissions-feedback-ui: An Angular web app
The plan should include a very detailed guide to create a mono repo with these two repositories in it. The guide should consist of these parts:
- A step-by-step guide to a "minimum viable product" (MVP) migration where the two repositories are in a single mono repo and the CI/CD is updated to continue supporting deployments and PR checks as before, with as minimal changes to anything as possible
- A detailed list of later actions to take after the MVP migration is complete to consolidate things and make the mono repo more stable, useful, and aligned to industry best practices
- A list of risks
- A discussion on alternative approaches with pros and cons
DO NOT ACTUALLY IMPLEMENT THIS SOLUTION. The output of this task is a Markdown file document with the guide as described above. You may create temporary local Git repositories to experiement with ideas, but DO NOT push any code to remotes.
- Keep changes to an absolute minimum to achieve an MVP
- The source code for each repository should remain separate in separate folders, though if there are configurations or extra scripts that need to be available for the MVP outside of those two folders, they should be well organized outside them (there can be other folders outside those two if needed)
- If at all possible, attempt to keep as much Git history for the code as you can. If you can't, explain why (and potential alternative ideas) in part 3 and/or part 4.
- The two projects should remain independently buildable and runnable
- No code consolidation between the respositories should happen unless absolutely necessary (consolidation ideas can be discussed in part 2 of the guide)
- All necessary AWS configuration changes to support this should be described so that PR checks can still run and deployments will be possible. The exact AWS configurations currently in place don't need to be used if they don't make sense, but the behavior of the configuration should match.
- Use industry best practices for mono repos as best as possible, and where compromises are made for the sake of minimal changes, note what the compromise was and include improvements in part 2 of the guide.
- When possible, include actual terminal commands or scripts to help with any given step of a the migration
- Focus on aligning the mono repo with industry best practices and making development very easy
- Try to isolate each recommendation as much as possible so each could be implemented one at a time
- Find and recommend code consolidation possibilities, especially for models and mock data
- Find and recommend ideas for simplifying our CI/CD pipeline
- Generally try to order the recommendations by most- to least-useful
- This list can be extensive, but does not require the level of detail in part 1. General explanation of each suggestion are fine, with no need for specific steps to achieve them
- Give a rough one-to-ten estimate on the difficulty level for implementing each recommendation
This does not have to be very extensive if there just aren't many risks. Just call out places where mistakes could be made or where you aren't very sure about your recommendation.
Provide a high level overview of any other directions we could go, either within the concept of a mono repo or avoiding a mono repo altogether. I just want a check against whether my ideas and your ideas are really the best way to go.
Again, the output of this is just a Markdown document. DO NOT MAKE ACTUAL CHANGES other than within temporary local Git repos for testing things. You may make web searches if you need to. If certain things are not clear or there are things you need from me (that can't just be included in the "later recommendations" list), you can ask me.