--ignore-expo cli option

[killerchip]

This option forces ignoring expo projects and treats them as bare-workflow/ejected projects. It helps manually overcome issues when react-native-version falselsy identifies expo presence.

Work-around for issue #105

[bayoremit]

This is wonderful

[LuisRodriguezLD]

This is gold, can we merge this?

[MidknightMan]

+1 a merge would be sensational

[scriptspry]

I am afraid this may not be merge ready yet. Even after ejecting expo project, the expo key in app.json would be used by some expo modules that started to support even bare flow like expo-updates.

So this needs logic fix as well. Or, might need running it first with out the flag and then with flag? (have not thought this through)

[agape-apps]

I am currently using this PR via patch-package, while the maintainers take their time to decide if this or the other PR (Adds two CLI options: --is-bare-expo-workflow and --is-self-hosting-bundles ) has the superior logic.

The current Expo bare-workflow bug needs a "logic fix" and it has been more than a year without such a fix. Either of these two solutions seem to do the job.

patch-package lets app authors instantly make and keep fixes to npm dependencies. It's a vital band-aid for those of us living on the bleeding edge.

# fix a bug in one of your dependencies
vim node_modules/some-package/brokenFile.js
# run patch-package to create a .patch file
npx patch-package some-package
# commit the patch file to share the fix with your team
git add patches/some-package+3.14.15.patch
git commit -m "fix brokenFile.js in some-package"

Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn.
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

[manuelbieh]

Would also love to have this option. Any news on that? 🙂

[saladestomateoignon]

Hello it would be cool to have this option indeed. Any news about it :) ?