Skip to content
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

feat(bin): add zx based generators #2317

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

feat(bin): add zx based generators #2317

wants to merge 2 commits into from

Conversation

joshuayoes
Copy link
Contributor

@joshuayoes joshuayoes commented Nov 19, 2022

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

color: colors.palette.primary500,
}
`,
{ Name: name },
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using template literals for file strings, I decided to go with doing a regex replace.

This was for a few reasons:

A trade off is that it's not immediately obvious which strings are variables in a template string. But I still find it to be pretty readable, and one can always use Ctrl+F to see what is getting find and replaced

Comment on lines +11 to +15
/**
* @callback UpdateCallback
* @param file {string} contents of the file
* @returns {string} updated file contents
*/
Copy link
Contributor Author

@joshuayoes joshuayoes Nov 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zx can be used with typescript, but it requires some specific package.json and tsconfig settings that I don't see on many projects. However, the existing globals have nice type defs already. And we can use jsdoc to create types otherwise. Another approach here may be to add .d.ts files and import them using jsdoc

@joshuayoes
Copy link
Contributor Author

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

joshuayoes commented Nov 19, 2022

Other interesting zx features of note:

@Ashraf-Ali-aa
Copy link

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

@joshuayoes
Copy link
Contributor Author

@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
Copy link
Member

@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.

@jamonholmgren jamonholmgren removed their request for review May 31, 2024 16:41
@frankcalise
Copy link
Contributor

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

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