bare workflow for 3 brands in one project: reasonable and possible?

Expo Development Tools
1

Hello to the community,

I would like to have advices on bare workflow of Expo.
Currently, I have one managed workflow with 3 configurations files (3 brands)
For one of these brands, I need to eject Expo to include InApp purchase because Apple reject any new updates because of that.

I tried to eject Expo and it created 2 new folders (iOS and android) with the main configuration file (app.config.js on project root).
Do you think is it possible to have these folders for each brand in only one project to keep the same JS core? Or I need to create 3 repos for each project?

Another question: if I eject Expo from one of these brands and keeps the others two brands in managed workflow, do you think it’s easily maintainable for only one developer?

I precise that the JS core is the same for each brands that’s why I use managed workflow with 3 config files. So if I eject one project, I’ll need to fix potentials bugs twice.

I know that Expo team released EAS to help developers to build apps in bare workflow. I’ll try this in the future.

Thanks for your help and to take time to answer me.

Regards,

2

Have you found any solution to this? I’m experiencing the same issue currently.

3

It’s possible to configure your native projects in android and ios directories to build for different “targets”, but it’s not simple if you didn’t work with native code that much. Also if you want to use EAS it’s not yet supported to have configs with different bundle identifiers/package names for the same project.

If the only thing you want to share between the project is js the easiest way is to setup monorepo, one directory with common code and for each project/brand separate directory with app.json, some light js wrapper that will bootstrap code from that common package and ios/android directories if applicable.

eject should work inside monorepo, but it’s possible that some relative paths to node_modules might need to be changed

this is example of project like that using EAS eas-monorepo-example/packages at main · byCedric/eas-monorepo-example · GitHub . I’m not sure if it’s up to date, but you can get general idea how to do that

4

Thanks @wkozyra for your reply.

Something like that:

folderX
  - ios
  - android
folderY
  - ios
  - android
folderZ
  - ios
  - android
core
  - src

The core folder will includes all the React Native app JS.

And what do you think to create an npm package for the core folder? The dependency for each project. It’s maybe the same approach than above but with multiple repo. It’s maybe more maintainable if the apps have a different configuration and to build apps from AppCenter.

Thanks for your time.

5

It’s maybe the same approach than above but with multiple repo.

The current auto-linking setup does not implement full node package resolution (we are working on improving that), so there might be cases where this linking might fail because packages are in different node_modules

Two option that should work now:

  • if all modules are hoisted up to root (you would need to use only one version of each package across all projects)
  • if you disable hoisting, but then every project in folderX, folderY… would need to have all expo modules specified in app.json

With the first option you will need to specify path to correct node_modules:

1 Like
6

Thanks @wkozyra!
I created a folder which includes the JS core (Core) with App.js file and src folder.

is there a way to register root component from this folder?

in the index.js of folderX, I :
import App from ../Core/App

but I’ve got an error :
Unable to resolve module ../Core/App from /Users/user_name/mobile/folderX/index.js

I find the entryPoint key in Expo app config documentation, but it doesn’t work for me.
I maybe don’t understanding something.

Maybe the main key in package.json, but same thing, it doesn’t work either.

Thanks for your help.

7

Sorry i might have been not clear on that, by monorepo I meant to suggest the use of yarn workspaces, so all those 4 top level folders would be separate packages. You would not need to publish them, it’s just for internal linking.

1 Like