Huge files checked in with .expo-source

[mattermoran]

https://forums.expo.io/t/should-i-add-expo-source-to-gitignore/29

says:

Nope, you'll want that checked in

it's all the exponent source code
You'll need to keep it if you detach/eject or you won't be able to build the project.

but the repository ends up being huge (40MB+) with these files as the main culprits:

-21718221	.expo-source/android/maven/org/webkit/android-jsc-intl/r216113/android-jsc-intl-r216113.aar
-12961995	.expo-source/android/maven/org/webkit/android-jsc/r216113/android-jsc-r216113.aar
-2640956	.expo-source/android/maven/com/facebook/react/react-native/21.0.0/react-native-21.0.0.aar
-2344641	.expo-source/android/maven/com/facebook/react/react-native/21.0.0/react-native-21.0.0-javadoc.jar
-2239804	android/app/libs/ReactAndroid-release.aar
-1232048	.expo-source/android/maven/host/exp/exponent/expoview/21.0.0/expoview-21.0.0.aar
-821324	.expo-source/android/maven/com/facebook/react/react-native/21.0.0/react-native-21.0.0-sources.jar
-737526	android/app/libs/exponentview-release.aar
-372241	.expo-source/android/maven/expolib_v1/com/squareup/okhttp3/okhttp/3.6.0/okhttp-3.6.0.jar
-346320	.expo-source/android/maven/host/exp/exponent/expoview/21.0.0/expoview-21.0.0-sources.jar

any workaround to lighten our source repos while keeping it buildable? should we zip up .expo-source and distribute it separetely?

[terribleben]

Hey, thanks for the report. Is there a specific issue or symptom this is causing for you? How will we measure which files are small enough not to cause an issue for you?

[slorber]

@terribleben was wondering the same.

it seems like this folder contains maven dependencies. Why would we require them to be in git repo instead of just being fetched (like we do with cocoa pods)

for example, there's the "expoview" aar package. can't it be downloaded from a maven repository as a build step instead of being added to git?

[jesseruder]

We compile a special version of react-native and put it in the maven repository. We need to use a local maven repository because it needs to have the same artifact name as regular react-native for other libraries to work, so we can't upload it to jcenter/maven central as it would conflict with the official react-native package. We could upload some of our other modified dependencies to jcenter/maven central but prioritized keeping everything together to make our release process easier.

Hope that makes sense.

[jesseruder]

If this is a big problem for people we'll probably have to do something where we have a prebuild step that downloads these artifacts from S3 and then unzips them. The current solution seemed simpler when we were building it since the files are well below Github's size limit (we have them checked in to our internal repos).

[slorber]

@jesseruder ok thanks I understand.

It's not a big problem for me currently but as ExpoKit doc is not very detailed it might be a problem for users trying to upgrade their ExpoKit. Will they know they also have to update this folder? and where to find the new folder content?

[jesseruder]

We have instructions for updating the directory here: https://docs.expo.io/versions/latest/guides/expokit.html#upgrading-expokit

Eventually we want to make it more automatic but we've been changing it enough recently that we just have those manual instructions.

[DylanVann]

Using a detached expo project seems really painful, just a general observation. I'm not sure if this is intentionally to lock people in or if it's accidental.

If the files are needed locally but can't be put on maven then maybe putting them on npm would be suitable?

[jesseruder]

@DylanVann npm is a good idea. I think that would work. I'll try playing around with that and see if we run into any issues.

I'm sorry that detached projects have been so painful :(. A lot of the problems are a symptom of us trying to keep detached projects similar to our internal projects so that we have less surface area to test. We're working on a project that should simplify a lot of this.

[DylanVann]

@jesseruder Thanks for the quick response.

Yeah it seems to me like a lot of what is being integrated into Expo could be done in ways more compatible with how the wider react-native community does native packages.

Sorry to be so accusatory. I'm currently trying to get some bug fixes from GLView into react-native-webgl but everything is too coupled for me to pull them in. Integrating the Expo SDK also doesn't seem to be viable as it's a huge change to an existing project.

In an ideal world I'd imagine the Expo repo being a monorepo which would include things like:

• @expo/react-native-vector-icons at packages/expo-react-native-vector-icons
• @expo/react-native-glview at packages/expo-react-native-glview

This might be a better architecture, and it would definitely be nice for the wider React Native community to be able to use some of the functionality in Expo if they're unable to go all in on it.

[jesseruder]

Yeah definitely! We agree and we're moving in that direction. Just want to be clear that we built it in a coupled manner because it made things easier for us, not because we were trying to lock people in. Now that we have a better idea of what our internal APIs need to look like we're going to start pulling individual packages out.

[DylanVann]

Awesome, I'm looking forward to seeing how things evolve. I'd love to use Expo more in the future and maybe contribute as well.

I actually did manage to resolve that particular issue so I guess the coupling wasn't as bad as I thought: rnc-archive/react-native-webgl#62

[slorber]

hey all, as of SDK28, the .expo-sources folder is empty yet still created. Is this solved or should we still consider future SDKs might use this folder?

[jesseruder]

You can delete .expo-sources. SDK 29 will have that deleted and also have the large files moved to npm like @DylanVann suggested!

[slorber]

great thanks for the infos