How do you set up an environment that allows both bare/managed workflow to co-exist?

Expo Development Tools
1

This is in relation to my other post about the gitignore for prebuild.

My specific scenario is as follows.

I have a development team that had been using Expo Go and been under the managed workflow for a while now. Even some of the designers that need early access go through Expo Go builds to quickly see what the ramifications of design decisions are.

However, we need to be able to integrate with some 3rd party that would not work with Expo managed workflow (i.e. Pendo).

From what I can tell the first step is to perform an expo prebuild. And there’s a way of doing a check if you’re running in Expo Go so you can skip the non-supported sections. I don’t think I will be modifying native code, just adding a new library.

So my questions from that point are…

  • what should be in .gitignore? The ios and android folder seem to contain other files that are generated when the application is started and are not ignored.
  • should I expect developers to perform expo prebuild every time on their local machine if they’re working on non-managed components?
  • should I expect developers to perform expo prebuild every time on their local machine if they’re NOT working on non-managed components?
  • can I still do expo upgrade? to ensure that the dependencies are still in-sync, not necessarily SDK 45->46?
  • can I still manage things using app.config.ts? Namely the build numbers are computed from the environment variables during build time.
2

Hi @trajano

Ideally (in my opinion) you would stick with the managed workflow and write a config plugin (if necessary) to integrate Pendo into your app during the build process.

If you do not want to write a config plugin, yes, you would use expo prebuild to switch to the Bare workflow.

Yes, see: Custom native code in Expo Go - Expo Documentation

This is a good reason, in my opinion, to try a config plugin first. I had a quick look and it was not clear to me what you need to do to integrate Pendo into a bare Expo project. I did see some mention of “codeless React Native” support, but it wasn’t clear what that means. Could you post some installation instructions here?

  • If you switch to the bare workflow, but avoid calling Pendo code in Expo Go: Commit the ios and android directories and do not ignore them.
  • If you get a config plugin working, do not run expo prebuild and do not commit the ios and android directories. You can add them to your .gitignore if you like.

No. Assuming you switch to the Bare workflow, you would basically run it once, then integrate the Pendo SDK and commit the results. You would only need to worry about it if you want to change the app’s name, icons, splash screen, Info.plist, AndroidManifest.xml, etc. or upgrade React Native or integrate some other dependency with native code. (If you stick to the managed workflow then you can continue to use app.json to update things like the app name, icons, splash screen, etc., etc.)

No.

You can run expo upgrade, although you’ll need to do a bunch of other stuff too. For example, check the “Bare workflow” section in the Expo SDK 45 release blog post. Again, sticking to the managed workflow is simpler for upgrades.

Most stuff in app.json / app.config.js no longer applies in the bare workflow. I am pretty sure build numbers would need to be updated in the native projects after you switch to the bare workflow.

1 Like
3

The single line of

Apply any relevant changes from the React Native Upgrade Helper.

in Expo SDK 45 announcement is likely going to cause problems for people upgrading the first time.

From the way it looks Config Plugins would likely be the best thing to implement Pendo. But there’s a part I am missing (which I can probably open up as a new topic) where do you put the part that adds the native code? it’s a long document so I may have missed that part or I am just not sure how it works in general.

4

Could you post the Pendo installation instructions? It wasn’t clear to me from looking at the documentation what you need to do to install it in a bare React Native app.

1 Like
5

Hello,
there might be a simpler solution: two separate apps that shares the JS code (with appropriate checks in order to enable / use the appropriate libraries).

I had resolved this very same issue with having a free and paid app sharing the same JS code, but I had to eject the free one in order to use native frameworks for advertisements.

This is done by having three folders, App1, App2 and AppJS.
App1 contains the regular managed app, App2 contains the regular ejected app, both have their own package.json and app.json and both have the index/app.js entry point.

In the entry point I call the JS tree under the AppJS folder thanks to metro.config.js aliases:

metro.config.js

const path = require('path')
const { getDefaultConfig } = require('expo/metro-config')

// redirects dependencies referenced from shared/ to local node_modules
const redirectDependencies = (target, name) => name in target
  ? target[name]
  : path.join(process.cwd(), `node_modules/${name}`)

const shared = path.resolve(__dirname, '../AppJs')
const assets = path.resolve(__dirname, './assets')

const defaultConfig = getDefaultConfig(__dirname)
defaultConfig.watchFolders.push(shared)
defaultConfig.resolver.extraNodeModules = new Proxy({ shared, assets }, { get: redirectDependencies })

module.exports = defaultConfig

I have now two items, assets and shared.

Shared is used in each app index.js to import the app JS code from

index.js

import 'expo-dev-client'
import { registerRootComponent } from 'expo'
import { App } from 'shared'

registerRootComponent(App)

While assets is used inside the JS code to import images and media from each project’s asset directory.
This is not required (assets could live inside the JS folder), but in my case each app has different graphics.

import { themes } from 'assets/themes'

Hope that helps

6

Not sure if your soluition is for me. What I want is basically to allow two sets of developers.

a) normal things team so managed workflow and focus on getting the day to day done
b) abnormal things team which have to put some weirdness into the code (e.g. pendo, pushy.me, some obscure device integration) that expose interfaces for the normal things team so they work in managed flow but have the release version of the device work.

7

If you’re OK with the “normal things team” not having access to the “abnormal” stuff, then you can use Expo Go as you suggested. But of course you could also build a custom dev client and/or a “preview”/internal distribution build for them to use instead. Then your “normal stuff team” would not be limited to the things that are available in the Expo SDK.

So your “abnormal things team” could do the integration of e.g. Bluetooth support and release a new development or internal distribution build. Then your “normal things team” would install the new build and use it to make use of the Bluetooth functionality.

1 Like
8

Yup I think that’s what you wrote on the post I marked as solution already.

As for as Pendo integration, it’s on hold at the moment, but hopefully they see this tread and consider doing the config-plugin route as from what I can tell with limited knowledge of the product since I am not actively working on it at the moment.

1 Like
9

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.