[repo] Remove ExpoKit leftovers (expo#10044)

# Why

We no longer support ExpoKit workflow.

# How

Went through the entire repository looking for `expokit`. Removed/changed stuff. Please see commits list to see steps done.

# Test Plan

CI should take care of programmatic stuff. Guides are executed by humans, so if anything is not clear we'll be able to fix it "online".

.github/ISSUE_TEMPLATE/release.md

@@ -61,11 +61,9 @@ assignees: ''
   - [ ] Android
   - [ ] iOS
 
-### [Stage 5 - ExpoKit and standalone apps](https://git.io/JeKCx#stage-5---expokit-and-standalone-apps)
+### [Stage 5 - Standalone apps](https://git.io/JeKCx#stage-5---standalone-apps)
 
-- [ ] [5.1. Updating ExpoKit](https://git.io/JeKCx#51-updating-expokit)
-  - [ ] Android
-  - [ ] iOS
+- [ ] [5.1. Updating JS dependencies required for build](https://git.io/JeKCx#51-updating-js-dependencies-required-for-build)
 - [ ] [5.2. Make shell app build](https://git.io/JeKCx#52-make-shell-app-build)
   - [ ] Android
   - [ ] iOS
@@ -77,7 +75,7 @@ assignees: ''
 ### [Stage 6 - Final release](https://git.io/JeKCx#stage-6---final-release)
 
 - [ ] [6.1. Release iOS/Android clients](https://git.io/JeKCx#61-release-iosandroid-clients)
-- [ ] [6.2. Deploy Turtle/ExpoKit to production](https://git.io/JeKCx#62-deploy-turtleexpokit-to-production)
+- [ ] [6.2. Deploy Turtle to production](https://git.io/JeKCx#62-deploy-turtle-to-production)
 - [ ] [6.3. Generate and deploy new docs](https://git.io/JeKCx#63-generate-and-deploy-new-docs)
 - [ ] [6.4. Add related packages to versions endpoint](https://git.io/JeKCx#64-add-related-packages-to-versions-endpoint)
 - [ ] [6.5. Promote versions to production](https://git.io/JeKCx#65-promote-versions-to-production)

android/app/build.gradle

@@ -88,12 +88,6 @@ configurations.all {
   }
 }
 
-// WHEN_PREPARING_SHELL_REMOVE_FROM_HERE
-/* UNCOMMENT WHEN DISTRIBUTING
-apply from: 'expo.gradle'
-END UNCOMMENT WHEN DISTRIBUTING */
-// WHEN_PREPARING_SHELL_REMOVE_TO_HERE
-
 apply from: "../../node_modules/react-native-unimodules/gradle.groovy"
 
 dependencies {
@@ -230,24 +224,6 @@ dependencies {
   implementation 'host.exp.exponent:expo-random:+'
   END UNCOMMENT WHEN DISTRIBUTING */
   // WHEN_DETACHING_REMOVE_TO_HERE
-
-  /* UNCOMMENT WHEN DETACHING
-  addUnimodulesDependencies([
-      modulesPaths : [
-        '../../node_modules'
-      ],
-      configuration: 'api',
-      target       : 'react-native',
-      exclude      : [
-        // You can exclude unneeded modules here, eg.
-        // 'unimodules-face-detector-interface',
-        // 'expo-face-detector'
-
-        // Adding a name here will also remove the package
-        // from auto-generated BasePackageList.java
-      ]
-  ])
-  END UNCOMMENT WHEN DETACHING */
 }
 
 // This has to be down here for some reason

android/settings.gradle

@@ -34,10 +34,6 @@ includeUnimodulesProjects(
         target      : 'react-native',
         exclude     : [
             'expo-module-template',
-// FLAG_BEGIN_REMOVE__UPDATE_EXPOKIT - used during `et android-build-packages`
-// section below previous line comment flag contains modules that need to be built for `expokit-npm-package`
-            'expo-in-app-purchases',
-// FLAG_END_REMOVE__UPDATE_EXPOKIT
         ]
     ]
 // WHEN_DISTRIBUTING_REMOVE_TO_HERE

guides/Creating Versioned Expo SDK for Android.md

@@ -1,6 +1,6 @@
 # Creating Versioned Expo SDK for Android
 
-This document will guide you through the process of creating a versioned snapshot of Expo SDK solely for Expo client's use. Instructions for creating a new version of `expokit` which is used in ejected projects, see `Updating Expokit Package For Ejected Android Projects` doc.
+This document will guide you through the process of creating a versioned snapshot of Expo SDK solely for Expo client's use.
 
 1. **Ensure that `@expo/xdl` dependency is up-to-date**
 

guides/Updating Expokit Package For Ejected Android Projects and Turtle.md

@@ -1,4 +1,4 @@
-# Updating Expokit Package For Ejected Android Projects and Turtle
+# Updating Prebuilt Android Packages For Turtle
 
 This document will guide you through the process of creating a new version of prebuilt Android packages which are used in Turtle. Instructions for creating a versioned snapshot of Expo SDK solely for Expo client's use, see `Creating Versioned Expo SDK for Android` doc.
 
@@ -12,48 +12,19 @@ This document will guide you through the process of creating a new version of pr
 
     If the script fails during the compilation step of any package, it will print out the raw error message from Gradle. You should fix the error in the affected package. You may then either discard all changes made by the script to `android/maven` (deleted contents in preparation for new archives) and to `android` (some changes should be committed after the script is done, some are temporary) and rerun the script entirely, or just rerun the script for the affected packages only. (Instructions will be printed from the script itself in this case.)
 
-2. **Update Expo ejected project template**
-
-    **Why:** When a developer runs `expo eject`, a template of an Android project is downloaded. For example it contains `android/app` folder (so it contains `build.gradle`, Java files, etc.)
-
-    **How:** If the working directory is clean, run (anywhere in the repository)
-
-      ```
-      et android-update-expokit --appVersion {appVersion} --sdkVersion {sdkVersion} --expokitVersion {expokitVersion} --expokitTag rc
-      ```
-
-      * `{appVersion}` — version of the template, usually one would use the same version that is used in `app/build.gradle` as the version of Expo client
-      * `{sdkVersion}` — SDK version for which the template is, (`XX.X.X`)
-      * `{expokitVersion}` — version under which `expokit-npm-package` should be published (`XX.X.X-rc.0`)
-      * `rc` — tag under which `expokit-npm-package` should be published 
-
-      This command will update the template on staging and publish `expokit` to NPM.
-
-3. **Test Turtle on staging**
+2. **Test Turtle on staging**
 
     **Why:** Turtle uses projects differently than developers of ejected projects, so we need to test this workflow separately.
 
     **How:** Given you pushed the changes to `sdk-XX` branch, open (or create if needed) a pull request of `sdk-XX` to `master`, go to _Checks_ tab, open `shell_app` CI workflow results for that branch and approve the `shell_app_android_approve_build` job from `shell_app` workflow. Wait for the `shell_app_android_build` job to finish, then copy the URL printed at the end and follow Turtle instructions of deploying a new version of SDK to staging. When deployed, run `EXPO_STAGING=1 expo build:android` in an upcoming SDK unejected project.
 
-4. **Test `expokit` package and ejected project template**
-    
-    **Why:** Ejected projects are structured differently than Expo client project so we need to test them separately.
-    
-    **How:** In an upcoming SDK unejected project (at least `expo init`, upgraded dependencies and `app.json`) run `EXPO_STAGING=1 expo eject`. This should download the archived template and install recently published `expokit`.
-
-5. **Publish `expokit` as latest stable version**
-
-    **Why:** Until now `expokit` should be published as `rc`. We should publish it as `latest`, final version for clearness.
-
-    **How:** Just as in step 2., run `et android-update-expokit` with final `expokitVersion` and `latest` as `expokitTag`.
-
-6. **Publish template to production**
+3. **Publish template to production**
 
     **Why:** Until now any changes were being made on staging, we now may want to push the changes to production.
 
     **How:** Run `et promote-versions`, verify that you consent the changes that are to be applied, and accept the diff.
 
-7. **Deploy Turtle to production**
+4. **Deploy Turtle to production**
 
     **Why:** So that people can build Android apps with new SDK.
 

guides/releasing/Release Workflow.md

@@ -29,14 +29,14 @@
   - [4.2. Making a simulator build](#42-making-a-simulator-build)
   - [4.3. Submit iOS client to App Store Review](#43-submit-ios-client-to-app-store-review)
   - [4.4. Release clients to external beta testers](#44-release-clients-to-external-beta-testers)
-- [Stage 5 - ExpoKit and standalone apps](#stage-5---expokit-and-standalone-apps)
-  - [5.1. Updating ExpoKit](#51-updating-expokit)
+- [Stage 5 - Standalone apps](#stage-5---standalone-apps)
+  - [5.1. Updating JS dependencies required for build](#51-updating-js-dependencies-required-for-build)
   - [5.2. Make shell app build](#52-make-shell-app-build)
   - [5.3. Make adhoc client shell app for iOS](#53-make-adhoc-client-shell-app-for-ios)
   - [5.4. Deploy Turtle with new shell tarballs](#54-deploy-turtle-with-new-shell-tarballs)
 - [Stage 6 - Final release](#stage-6---final-release)
   - [6.1. Release iOS/Android clients](#61-release-iosandroid-clients)
-  - [6.2. Deploy Turtle/ExpoKit to production](#62-deploy-turtleexpokit-to-production)
+  - [6.2. Deploy Turtle to production](#62-deploy-turtle-to-production)
   - [6.3. Deploy new docs](#63-deploy-new-docs)
   - [6.4. Add related packages to versions endpoint](#64-add-related-packages-to-versions-endpoint)
   - [6.5. Promote versions to production](#65-promote-versions-to-production)
@@ -239,13 +239,8 @@
 - **Android**:
   - The process for building a standalone app locally is to publish the app you want to build and then run `et android-shell-app --url <url> --sdkVersion XX.X.X`.
 - **iOS**:
-  - The easiest way for now is to eject to ExpoKit and then build the resulting project. ExpoKit is not yet published (there is no new tag on GitHub) so use the current commit hash instead in `Podfile` under ExpoKit dependency.
-    > This is not currently possible to test `standalone`/`ejected to ExpoKit` app in `expo` repository scope.
-    > One way is to:
-    >
-    > - copy `apps/native-components-list`/`test-suite` app outside repository scope and perform `eject to ExpoKit`,
-    > - use ExpoKit commit hash in Podfile,
-    > - install each unimodule specified in `package.json` from specific commit hash.
+  - In theory it should be possible to run `et ios-shell-app --url <url> --sdkVersion XX.X.X` + some more options to create a workspace that should be buildable in Xcode. Good luck!
+    > Note from @sjchmiela — I used `et ios-shell-app --action create-workspace -u "https://staging.exp.host/@sjchmiela/native-component-list/index.exp?sdkVersion=39.0.0" -s 39.0.0 --skipRepoUpdate` when I was testing SDK39 shell apps and it created a buildable Xcode workspace. I hope it does that for you too!
 
 ## 2.3. Web Quality Assurance
 
@@ -392,31 +387,25 @@ Web is comparatively well-tested in CI, so a few manual smoke tests suffice for
 
 - Coordinate with @cruzach and @byCedric on this. Most beta testers will use the simulator builds on staging, but we can also send TestFlight invitations if needed.
 
-# Stage 5 - ExpoKit and standalone apps
+# Stage 5 - Standalone apps
 
-## 5.1. Updating ExpoKit
+## 5.1. Updating JS dependencies required for build
 
 | Prerequisites                                                                               |
 | ------------------------------------------------------------------------------------------- |
 | [3.1. Publish any missing or changed packages](#31-publish-any-missing-or-changed-packages) |
 
-**Why:** Ejected apps use ExpoKit as a dependency containing the core of Expo and some modules that are not yet extracted to unimodules. Since this flow is still supported (we're going to deprecate it) we need to release its new version as well.
+**Why:** When building an iOS shell app XDL installs some extra packages needed for the build process.
 
 **How:**
 
 - Run `et update-versions -k 'packagesToInstallWhenEjecting.react-native-unimodules' -v 'X.Y.Z'` where `X.Y.Z` is the version of `react-native-unimodules` that is going to be used in ejected and standalone apps using this new SDK version.
-  **iOS:**
-  - From the release branch run `et ios-update-expokit`. - It creates a `ios/X.Y.Z` tag on GitHub where `X.Y.Z` is the iOS app version (`CFBundleShortVersionString` from `Info.plist`). - It automatically detects iOS app and SDK versions, but if you need, you can modify its defaults using `--appVersion` and `--sdkVersion` flags. - Please don't forget to make a GitHub release on this tag and add release notes there, so people will see what changed in this version (just copy corresponding entries from `CHANGELOG.md`).
-    **Android:**
-  - Check out the release branch.
-  - Run `et android-build-packages` and ensure that all the unimodule packages are up-to-date. Commit any changes.
-  - Run `et android-update-expokit --sdkVersion XX.X.X --appVersion <android client version> --expokitVersion XX.X.X --expokitTag next`. This will upload the ExpoKit template files to S3, and set values on the staging versions endpoint.
 
 ## 5.2. Make shell app build
 
-| Prerequisites                                 |
-| --------------------------------------------- |
-| [5.1. Updating ExpoKit](#51-updating-expokit) |
+| Prerequisites                                                                                                |
+| ------------------------------------------------------------------------------------------------------------ |
+| [5.1. Updating Updating JS dependencies required for build](#51-updating-js-dependencies-required-for-build) |
 
 **Why:** Shell app is a simple app on which Expo's Turtle work on to generate a standalone app. On iOS, shell app is compiled before it is uploaded to Turtle, so the process of building a standalone app is reduced to the minimum. We need to prepare such app for the new SDK, compile it, then put it into a tarball and put its url to Turtle's shellTarballs configs.
 
@@ -474,7 +463,7 @@ Once everything above is completed and Apple has approved the iOS client, the fi
   - Open `Android Client` workflow on GitHub Actions and when it completes, download the APK from Artifacts and do a smoke test -- install it on a fresh Android device, turn on airplane mode, and make sure Home loads.
   - Run `et dispatch client-android-release` to trigger appropriate job on GitHub Actions. About 45 minutes later the update should be downloadable via Play Store.
 
-## 6.2. Deploy Turtle/ExpoKit to production
+## 6.2. Deploy Turtle to production
 
 **How:**
 
@@ -511,7 +500,7 @@ Once everything above is completed and Apple has approved the iOS client, the fi
 | Prerequisites                                                                                   |
 | ----------------------------------------------------------------------------------------------- |
 | [6.1. Release iOS/Android clients](#61-release-iosandroid-clients)                              |
-| [6.2. Deploy Turtle/ExpoKit to production](#62-deploy-turtleexpokit-to-production)              |
+| [6.2. Deploy Turtle to production](#62-deploy-turtle-to-production)                             |
 | [6.3. Deploy new docs](#63-deploy-new-docs)                                                     |
 | [6.4. Add related packages to versions endpoint](#64-add-related-packages-to-versions-endpoint) |
 

ios/CONTRIBUTING.md

@@ -26,7 +26,6 @@ This code can be run in a few contexts:
 
 - As the Expo Client app.
 - As a standalone (shell) app. In this case, the project is pre-built, and then some tooling modifies configurations in the NSBundle to cause it to run as a standalone app.
-- As the ExpoKit library. In this case, AppDelegate and RootView are omitted, and all the other classes are installed via CocoaPods inside an external project.
 
 The `EXShellManager` class keeps track of how the code is being run. Mostly it reads the contents of a couple `.plist` files in the bundle.
 
@@ -35,7 +34,7 @@ The `EXShellManager` class keeps track of how the code is being run. Mostly it r
 We use CocoaPods to manage dependencies. Rather than committing `Podfile`, we use `template-files/ios/dependencies.json`. To add a dependency:
 
 - Add it to `dependencies.json`
-- Run `et ios-generate-dynamic-macros`. This will write `Podfile` (for the Expo Client) and `ExpoKit.podspec` (for ExpoKit, which uses almost all of the same code as Expo Client, and therefore has the same dependencies).
+- Run `et ios-generate-dynamic-macros`. This will write `Podfile` (for the Expo Client) and `ExpoKit.podspec` (for standalone apps, which use almost all of the same code as Expo Client, and therefore have the same dependencies).
 
 ## Testing
 
@@ -75,8 +74,8 @@ The Expo Client is an iOS app containing the Expo Kernel. The Kernel is a piece
 
 Almost everything in the project is included in the ExpoKit library (see `ExpoKit.podspec`). The Expo Client is just a special user of ExpoKit. Therefore it includes some extra classes to provide an entry point to the application:
 
-- `EXAppDelegate`: The app delegate. Try to keep this file small. Mostly it should call into `ExpoKit` methods, unless you really want to add functionality that is specific to Expo Client and should not work in other ExpoKit projects.
-- `EXRootViewController`: Same story as AppDelegate. This implements any view controller functionality which only needs to apply to Expo Client and not other ExpoKit proejcts.
+- `EXAppDelegate`: The app delegate. Try to keep this file small. Mostly it should call into `ExpoKit` methods, unless you really want to add functionality that is specific to Expo Client and should not work in standalone apps.
+- `EXRootViewController`: Same story as AppDelegate. This implements any view controller functionality which only needs to apply to Expo Client and not standalone apps.
 
 ### Versioned directory
 
@@ -87,7 +86,7 @@ Everything under this directory will be duplicated and namespaced when we releas
 
 ### ExpoKit directory
 
-This contains the public ExpoKit API exposed by the ExpoKit CocoaPod.
+This contains the public ExpoKit API exposed by the ExpoKit CocoaPod, which basically ends up being used only in standalone iOS apps.
 
 ### ReactAppManager
 

packages/expo-google-sign-in/README.md

@@ -1,6 +1,6 @@
 # expo-google-sign-in
 
-Enables native Google authentication features in your app! This module can only be used in ExpoKit, or a Standalone Expo app. For in-depth setup, check out this guide: https://blog.expo.io/react-native-google-sign-in-with-expo-d1707579a7ce
+Enables native Google authentication features in your app!
 
 # API documentation