Idea: Mitosis bot to handle generating build changes

Came out of a conversation with @mandx. Writing it here to not lose the idea.

When building a Mitosis project whose outputs are all independent npm packages, there's one issue: every PR with changes in src, but also the same files in output/vue/src, output/svelte/src, output/react-native/src, etc. This makes every PR huge, and unreasonable to easily review. The problem scales with the number of outputs.

One alternative is to .gitignore the output, but that means that consumers of your open-source npm package do not have an easy way to read the final, generated source-code for their framework. Reading Mitosis code might be confusing if they want to see the actual React/Svelte/Vue component and how it works. The only way to do that becomes to install the package locally and inspect their node_modules, which adds a bit of friction.

Copying Armando's answer below, which suggests a mitosis-bot that would create a follow-up PR containing the new built code.

Maybe a bot is the answer:

• You create a PR with just changes on src
• The mitosis-bot could:
  • Take your PR, build the stuff at output/<every framework>/src and make a new PR against yours.
  • When your PR is merged, it could take it’s PR, rebase against main, build and merge.
• Listen for pushes to main and rebuild output/<every framework>/src on every push
  • Open a new PR with the changes (preferred)
  • YOLO it and push to main
• Do something like the above, but only when mentioned

Followup questions:

• how would this work with testing? If there are integration tests that rely on the generated output, it seems like this setup wouldn't really work. You would want the tests to work against the latest version of the output in the "original" PR, but those changes are not committed...

Start by tracing how changes in src are built into output//src for each framework, and inspect the existing integration-test setup. Clarify whether the bot should create follow-up PRs for source PRs, rebuild after pushes to main, or act only when mentioned. Done would include an agreed workflow for generated outputs and a testing strategy for uncommitted generated changes.