feat(bin): add zx based generators

[joshuayoes]

trafficstars

Please verify the following:

• [ ] yarn test jest tests pass with new tests, if relevant
• [ ] README.md has been updated with your changes, if relevant

Describe your PR

There is a scripting tool called zx that is a hybrid between bash and node scripting. It has a lot of dev experience and productivity of gluegun.

To play around with it, I decided to implement some of the existing generators in ignite. This was relatively simple to do. And with this extension, you can even get syntax highlighting with the js strings.

This may be a nice alternative API for generators so that ignite users can update these scripts as a project grows.

Initially, I thought about creating an alternative typescript generator API that I create a proof of concept of. But the nice thing about using zx is that it would pretty much remove any maintenance cost with generators from ignite. Additionally, these scripts are portable, so they can dropped into existing projects.

I will leave this PR here for discussion and an artifact of that exploration

[joshuayoes]

This PR does not have the splash-screen or app-icon generator implemented, but I wanted to get some feedback about the reaction of this approach before implementing more sophisticated scripts like that

[joshuayoes]

Other interesting zx features of note:

• You can write these scripts as markdown files.
• You can execute remote scripts from a URL. So potentially cookbook recipes could be executed from the website
• Being able to import and export js modules means users can write their own "tools" as they need to in ignite projects.

[Ashraf-Ali-aa]

@joshuayoes would something like https://github.com/plopjs/plop make more sense

[joshuayoes]

@joshuayoes would something like https://github.com/plopjs/plop make more sense

This is very interesting, I'll need to take a deeper look at this. But at first glance, this seems like a more mature solution.

The idea of this PR is that generators are something that should be co-located in each project and should be able to evolve with it. I have found many projects with generators from frameworks eventually abandoning them because a team adopted a style that was not compatible with it.

[jamonholmgren]

@joshuayoes I think, unless there's a compelling reason to move, I'd like to keep our current generators. I see the benefits of what you're proposing here but the current ones work okay and that way we reduce churn.

If we used this on a real project for a while and people within IR liked it a lot, then I could see moving this direction. But I'm not seeing a lot of demand for this sort of change.

I do appreciate what you did here, though! You put a lot of thought into it, clearly.

[frankcalise]

So I will also add to this that our current generator breaks down at the screen level when using expo-router, since you'll have to specify a path (or it would make sense to)

Right now we'd have to keep updating the cli and publishing to add parameters