-
Notifications
You must be signed in to change notification settings - Fork 1.5k
fix(generate): add support for Expo Router app directory prompts #2905
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
base: feat/expo-sdk-53
Are you sure you want to change the base?
fix(generate): add support for Expo Router app directory prompts #2905
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! A few comments for discussion where I think we can shore things up. Also if you think we can add a test to double check the user gets prompted in the way you're expecting if both are omitted that's probably worth adding.
src/commands/generate.ts
Outdated
@@ -52,6 +52,53 @@ async function generate(toolbox: GluegunToolbox) { | |||
pascalName = pascalName.slice(0, -1 * pascalGenerator.length) | |||
command(`npx ignite-cli generate ${generator} ${pascalName}`) | |||
} | |||
// Check if src/app exists, denoting an Expo Router app | |||
if (generator === "screen") { | |||
const isExpoRouterApp = filesystem.exists("src/app") === "dir" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is the correct directory structure to determine expo-router in an Ignite application, however omitting the src/
nesting is totally valid and it is possible a dir structure looks like this:
- app (the routes)
- components
- hooks
- etc...
This is in fact the default expo application structure and Ignite generators should continue to be compatible for any project, not just our opinionated structure.
So perhaps we should look into a different mechanism for determining this? Maybe we check app
or src/app
to cover both. Or look for package.json
to have expo-router
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that definitely tracks. I think it would make sense to check for expo-router
. Do you think it make more sense to check within the package.json
dependencies or within the app.json
expo plugins?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say package.json
is easier because you know where it will live, under dependencies
, so you can search for the key there.
Issues with the app.json
route:
- It could also be in
app.config.js
orapp.config.ts
- Plugins is an array of a mix of strings and/or arrary, making searching through it a bit more difficult
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's fair, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Spotted a couple of things to look over
src/commands/generate.ts
Outdated
@@ -52,6 +52,54 @@ async function generate(toolbox: GluegunToolbox) { | |||
pascalName = pascalName.slice(0, -1 * pascalGenerator.length) | |||
command(`npx ignite-cli generate ${generator} ${pascalName}`) | |||
} | |||
// Check if src/app exists, denoting an Expo Router app |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this comment could use updating now that we changed the strategy to look at package.json
…ically setting default directory
…signment for screens
Sorry about not chiming in on the original issue! I have some thoughts.
The screen should always (IMO) be in
This creates a route file at This would allow us to have multiple routes that can import the same screen. It also eliminates this specialized generator logic which I think is going away from the spirit of the simple generators we want for Ignite. Ignite's generators got too complicated in earlier versions, which is why I rewrote them to be super simple in Ignite 6. The whole CLI was just over 900 lines of code at that point (vs 3k+ for previous versions), and I really don't want to continue to bloat it with additional logic if we can avoid that. |
I made some updates to this to help progress it along. Now, for expo-router projects, we restored the screen generator to keep it being placed in In addition to that, upon a new project it will generate a
resulting in
import { WelcomeScreen } from "@/screens/WelcomeScreen"
export default function Welcome() {
return <WelcomeScreen />
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took at look at these changes and tried them out locally across Expo Router/not Expo Router projects generated from a local build of the CLI. Looking good!
…r-screen-generator
</Screen> | ||
) | ||
export default function Index() { | ||
return <WelcomeScreen /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Praise: I love this! Less duplicated code in the boilerplate to maintain! 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm well the WelcomeScreen itself is still duped, but maybe I can get that even better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woot think I can reduce it further, changes incoming 🙏
utilize @demo macro removal to just touch up the boilerplate/app/screens/WelcomeScreen instead of having a copy
Description
This PR addresses a user who creates screens within an ignited app using
expo-router
. It checks for the existence ofsrc/app
(the expo router configuration) and then determines where to put the screen in 4 ways:destinationDir
set from the screen generator templatesrc/app/
Screenshots
src/app
and user just taps entersrc/app
Checklist
README.md
and other relevant documentation has been updated with my changes