[docs] Update Expo config references to "app config" (expo#22645)

# Why  During the initial audit done by Jon, it was brought that we should be consistent when using **app config** to represet **app.json**/**app.config.js** files. Currently, in many places, Expo config is used instead of **app config**. # How This PR updates all references of Expo config to app config.  # Test Plan  Changes have been tested by running docs locally. # Checklist  - [x] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Bartosz Kaszubowski <[email protected]>
crummy · May 28, 2023 · 1949884 · 1949884
1 parent 42bafeb
commit 1949884
Show file tree

Hide file tree

Showing 47 changed files with 165 additions and 152 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -199,7 +199,7 @@ cd expo/packages/expo-constants
 
 ```ts
 /**
- * The standard Expo config object defined in `app.json` and `app.config.js` files. For both
+ * The standard app config object defined in `app.json` and `app.config.js` files. For both
  * classic and modern manifests, whether they are embedded or remote.
  */
 expoConfig: ExpoConfig | null;

diff --git a/docs/pages/accounts/working-together.mdx b/docs/pages/accounts/working-together.mdx
@@ -8,7 +8,7 @@ You can grant other users access to the projects belonging to your Personal Acco
 
 You can invite new members to your Personal Account, or any account you administrate, from the [Members page](https://expo.dev/settings/members) in your dashboard. You can only add users with Expo accounts as members; you can direct them to [https://expo.dev/signup](https://expo.dev/signup) if they don't have an account yet. You may have up to 100 members and pending invitations combined for a single account.
 
-> When adding new developers to your projects, who are publishing updates or create new builds, make sure to add the [`owner`](../versions/latest/config/app.mdx#owner) property to your project's Expo config.
+> When adding new developers to your projects, who are publishing updates or create new builds, make sure to add the [`owner`](../versions/latest/config/app.mdx#owner) property to your project's app config.
 
 ## Managing Access
 

diff --git a/docs/pages/archive/managed-vs-bare.mdx b/docs/pages/archive/managed-vs-bare.mdx
@@ -19,7 +19,7 @@ The managed workflow is kind of like [Rails](https://rubyonrails.org) and [Creat
 
 Developers build managed workflow apps using [Expo CLI](/more/expo-cli) on their computer and a development client on their mobile devices (either the Expo Go app for more simple projects or a [development build](/develop/development-builds/introduction/) when your project grows). Managed workflow apps typically use one or more Expo services, such as [push notifications](/push-notifications/overview), [build](/build/introduction), and [updates](/eas-update/getting-started).
 
-**Expo tries to manage as much of the complexity of building apps for you as we can, which is why we call it the managed workflow**. A developer using the managed workflow doesn't use Android Studio or Xcode often (although it may be useful for debugging), they write JavaScript code and manage configuration, such as the app icon and splash screen, through [Expo config &mdash; **app.json/app.config.js**](/workflow/configuration) or [config plugins](/config-plugins/introduction/). The Expo SDK exposes an increasingly comprehensive set of APIs that give you the power to access device capabilities like the camera, biometric authentication, file system, haptics, and so on. Developers can also make use of most [libraries available in the React Native ecosystem](/workflow/using-libraries).
+**Expo tries to manage as much of the complexity of building apps for you as we can, which is why we call it the managed workflow**. A developer using the managed workflow doesn't use Android Studio or Xcode often (although it may be useful for debugging), they write JavaScript code and manage configuration, such as the app icon and splash screen, through [app config &mdash; **app.json/app.config.js**](/workflow/configuration) or [config plugins](/config-plugins/introduction/). The Expo SDK exposes an increasingly comprehensive set of APIs that give you the power to access device capabilities like the camera, biometric authentication, file system, haptics, and so on. Developers can also make use of most [libraries available in the React Native ecosystem](/workflow/using-libraries).
 
 While you can do a lot with the managed workflow, you can't do _everything_ with it, so what are your options when you encounter a [limitation](/faq/#limitations)?
 

diff --git a/docs/pages/archive/technical-specs/expo-updates-0.mdx b/docs/pages/archive/technical-specs/expo-updates-0.mdx
@@ -135,7 +135,7 @@ type Asset = {
     A conforming client SHOULD prefix a file extension with a `.` if a file extension is not empty and missing the `.` prefix.
   - `url`: Location at which the file may be fetched.
 - `metadata`: The metadata associated with an update. It is a string-valued dictionary. The server MUST send back an empty object at a minimum, but MAY send back anything it wishes within the object to be used for filtering the updates. The metadata MUST pass the filter defined in the accompanying `expo-manifest-filters` header.
-- `extra`: For specification of optional "extra" information such as third-party configuration. The server MUST send back an empty object at a minimum. Expo Updates does not specify or rely upon this field, but other libraries may. For example, if the update is hosted on Expo Application Services (EAS), the EAS project ID and Expo config (which is used by many Expo libraries through `expo-constants`) may be included:
+- `extra`: For specification of optional "extra" information such as third-party configuration. The server MUST send back an empty object at a minimum. Expo Updates does not specify or rely upon this field, but other libraries may. For example, if the update is hosted on Expo Application Services (EAS), the EAS project ID and app config (which is used by many Expo libraries through `expo-constants`) may be included:
 
 ```json
 "extra": {

diff --git a/docs/pages/bare/hello-world.mdx b/docs/pages/bare/hello-world.mdx
@@ -7,7 +7,7 @@ description: An overview of bare React Native app with Expo tools.
 import { BoxLink } from '~/ui/components/BoxLink';
 import { Terminal } from '~/ui/components/Snippet';
 
-A bare React Native app is a project where developers make direct changes to their native **android and **ios** project directories rather than continuously generating them on demand using the [Expo config (**app.json**) and prebuild](/workflow/prebuild). All tools and services offered by Expo including [EAS](/eas), Expo CLI, and the libraries in the Expo SDK, are built around bare React Native apps.
+A bare React Native app is a project where developers make direct changes to their native **android and **ios** project directories rather than continuously generating them on demand using the [app config (**app.json**) and prebuild](/workflow/prebuild). All tools and services offered by Expo including [EAS](/eas), Expo CLI, and the libraries in the Expo SDK, are built around bare React Native apps.
 
 Before you get started with a React Native app, make sure you set up your environment for [React Native CLI](https://reactnative.dev/docs/environment-setup).
 

diff --git a/docs/pages/build-reference/migrating.mdx b/docs/pages/build-reference/migrating.mdx
@@ -7,7 +7,7 @@ import { Terminal } from '~/ui/components/Snippet';
 
 This page covers practical differences you should know when migrating your Expo [managed app](/archive/managed-vs-bare/#managed-workflow) from `expo build` (also known as **classic builds**) to EAS Build. If this is your first time using EAS Build, you can use this page as a companion to [Creating your first build](/build/setup).
 
-One of the goals of EAS Build is to make it as easy as possible to migrate from `expo build`. For example, your app signing credentials will be automatically re-used, and the Expo SDK and your [Expo config](/workflow/configuration) (**app.json**) configuration will all work the same as before. However, some differences between the two build processes require additional configuration or small code changes.
+One of the goals of EAS Build is to make it as easy as possible to migrate from `expo build`. For example, your app signing credentials will be automatically re-used, and the Expo SDK and your [app config](/workflow/configuration) (**app.json**) configuration will all work the same as before. However, some differences between the two build processes require additional configuration or small code changes.
 
 ## SDK 41 and above projects are supported
 
@@ -69,7 +69,7 @@ Only the second purpose applies to the EAS Build system. All assets referenced i
 
 If you are using `Constants.manifest` to access fields, you should switch to `Constants.expoConfig` to access them from the [`expo-constants`](/versions/latest/sdk/constants) library.
 
-## Expo config
+## App config (**app.json/app.config.js**)
 
 ### `userInterfaceStyle` depends on `expo-system-ui` being installed
 

diff --git a/docs/pages/config-plugins/development-and-debugging.mdx b/docs/pages/config-plugins/development-and-debugging.mdx
@@ -91,7 +91,7 @@ as this will perform automatic validation on the plugins and surface error infor
 
 You can develop plugins easily using JS, but if you want to setup Jest tests and use TypeScript, you will want a monorepo.
 
-A monorepo will enable you to work on a node module and import it in your Expo config like you would if it were published to npm.
+A monorepo will enable you to work on a node module and import it in your app config like you would if it were published to npm.
 Expo config plugins have full monorepo support built-in so all you need to do is setup a project.
 
 In your monorepo's `packages/` folder, create a module, and [bootstrap a config plugin](https://github.com/expo/expo/tree/main/packages/expo-module-scripts#-config-plugin) in it.
@@ -243,7 +243,7 @@ export default createRunOncePlugin(
 - **Naming conventions**: Use `withFeatureName` if cross-platform. If the plugin is platform specific, use a camel case naming with the platform right after “with”. For example, `withAndroidSplash`, `withIosSplash`.
   There is no universally agreed upon casing for `iOS` in camel cased identifiers, we prefer this style and suggest using it for your config plugins too.
 - **Leverage built-in plugins**: Account for built-in plugins from the [prebuild config](https://github.com/expo/expo-cli/blob/master/packages/prebuild-config/src/plugins/withDefaultPlugins.ts).
-  Some features are included for historical reasons, like the ability to automatically copy and link [Google services files](https://github.com/expo/expo-cli/blob/3a0ef962a27525a0fe4b7e5567fb7b3fb18ec786/packages/config-plugins/src/ios/Google.ts#L15) defined in the Expo config.
+  Some features are included for historical reasons, like the ability to automatically copy and link [Google services files](https://github.com/expo/expo-cli/blob/3a0ef962a27525a0fe4b7e5567fb7b3fb18ec786/packages/config-plugins/src/ios/Google.ts#L15) defined in the app config.
   If there is overlap, then maybe recommend the user uses the built-in types to keep your plugin as simple as possible.
 - **Split up plugins by platform**: For example — `withIosSplash`, `withAndroidSplash`. This makes using the `--platform` flag in `npx expo prebuild` a bit easier to follow in `EXPO_DEBUG` mode.
 - **Unit test your plugin**: Write Jest tests for complex modifications. If your plugin requires access to the filesystem,
@@ -281,7 +281,7 @@ interface StaticObject {
 }
 ```
 
-Static properties are required because the Expo config must be serializable to JSON for use as the app manifest.
+Static properties are required because the app config must be serializable to JSON for use as the app manifest.
 Static properties can also enable tooling that generates JSON schema type checking for autocomplete and IntelliSense.
 
 If possible, attempt to make your plugin work without props, this will help resolution tooling like [`expo install`](#expo-install) or [VS Code Expo Tools][vscode-expo] work better.
@@ -442,7 +442,7 @@ Introspection only supports a subset of modifiers:
 > Introspection only works on safe modifiers (static files like JSON, XML, plist, properties), with the exception of `ios.xcodeproj` which often requires file system changes, making it non idempotent.
 
 Introspection works by creating custom base mods that work like the default base mods, except they don't write the `modResults` to disk at the end.
-Instead of persisting, they save the results to the Expo config under `_internal.modResults`, followed by the name of the mod
+Instead of persisting, they save the results to the app config under `_internal.modResults`, followed by the name of the mod
 such as the `ios.infoPlist` mod saves to `_internal.modResults.ios.infoPlist: {}`.
 
 As a real-world example, introspection is used by `eas-cli` to determine what the final iOS entitlements will be in a managed app,
@@ -658,20 +658,20 @@ For more info, see [the PR that adds support](https://github.com/expo/expo-cli/p
 
 ## expo install
 
-Node modules with config plugins can be added to the project's Expo config automatically by using the `expo install` command. [Related PR](https://github.com/expo/expo-cli/pull/3437).
+Node modules with config plugins can be added to the project's app config automatically by using the `expo install` command. [Related PR](https://github.com/expo/expo-cli/pull/3437).
 
 This makes setup a bit easier and helps prevent users from forgetting to add a plugin.
 
 This does come with a couple of caveats:
 
 1. Packages must export a plugin via **app.plugin.js**, this rule was added to prevent popular packages like `lodash` from being mistaken for a config plugin and breaking the prebuild.
 2. There is currently no mechanism for detecting if a config plugin has mandatory props. Because of this, `expo install` will only add the plugin, and not attempt to add any extra props. For example, `expo-camera` has optional extra props, so `plugins: ['expo-camera']` is valid, but if it had mandatory props then `expo-camera` would throw an error.
-3. Plugins can only be automatically added when the user's project uses a static Expo config (**app.json** and **app.config.json**).
+3. Plugins can only be automatically added when the user's project uses a static app config (**app.json** and **app.config.json**).
    If the user runs `expo install expo-camera` in a project with an **app.config.js**, they'll see a warning like:
 
 ```
 Cannot automatically write to dynamic config at: app.config.js
-Please add the following to your Expo config
+Please add the following to your app config
 
 {
   "plugins": [

diff --git a/docs/pages/config-plugins/introduction.mdx b/docs/pages/config-plugins/introduction.mdx
@@ -11,7 +11,7 @@ An automatic setup for adding a native module to your project is possible. Somet
 
 ## What is a config plugin
 
-Config plugin is a system for extending the [Expo config](/workflow/configuration) and customizing the prebuild process for your app. They can be used to add native modules that aren't included, by default, or to add any native code that needs to be configured further.
+Config plugin is a system for extending the [app config](/workflow/configuration) and customizing the prebuild process for your app. They can be used to add native modules that aren't included, by default, or to add any native code that needs to be configured further.
 
 Internally Expo CLI uses config plugins to generate and configure all the native code for a managed project. Plugins do things such as generate app icons, set the app name, and configure the **AndroidManifest.xml**, **Info.plist**, and so on.
 

diff --git a/docs/pages/config-plugins/plugins-and-mods.mdx b/docs/pages/config-plugins/plugins-and-mods.mdx
@@ -65,7 +65,7 @@ You may want to create a plugin in a different file, here's how:
 Consider the following example that changes the config name:
 
 ```
-╭── app.config.js ➡️ Expo Config
+╭── app.config.js ➡️ App config
 ╰── my-plugin.js ➡️ Our custom plugin file
 ```
 
@@ -146,7 +146,7 @@ export default {
 
 A modifier (mod for short) is an async function that accepts a config and a data object, then manipulates and returns both as an object.
 
-Mods are added to the `mods` object of the Expo config. The `mods` object is different from the rest of the Expo config because it doesn't get serialized
+Mods are added to the `mods` object of the app config. The `mods` object is different from the rest of the app config because it doesn't get serialized
 after the initial reading, which means you can use it to perform actions _during_ code generation.
 If possible, you should attempt to use basic plugins instead of mods, as they're simpler to work with.
 
@@ -334,7 +334,7 @@ You can quickly create a plugin in your project and use it in your config.
 - <NoIcon /> `'./my-config-plugin.js'`
 
 ```
-╭── app.config.js ➡️ Expo Config
+╭── app.config.js ➡️ app config
 ╰── my-config-plugin.js ➡️ ✅ `module.exports = (config) => config`
 ```
 
@@ -348,7 +348,7 @@ If an **app.plugin.js** file is present in the root of a Node module's folder, i
 - <NoIcon /> `'expo-splash-screen/app.plugin.js'`
 
 ```
-╭── app.config.js ➡️ Expo Config
+╭── app.config.js ➡️ App config
 ╰── node_modules/expo-splash-screen/ ➡️ Module installed from NPM (works with Yarn workspaces as well).
     ├── package.json ➡️ The `main` file will be used if **app.plugin.js** doesn't exist.
     ├── app.plugin.js ➡️ ✅ `module.exports = (config) => config` -- must export a function.
@@ -364,7 +364,7 @@ A config plugin in a node module (without an **app.plugin.js**) will use the `ma
 - <NoIcon /> `'expo-splash-screen/build/index'`
 
 ```
-╭── app.config.js ➡️ Expo Config
+╭── app.config.js ➡️ App config
 ╰── node_modules/expo-splash-screen/ ➡️ Module installed from NPM (works with Yarn workspaces as well).
     ├── package.json ➡️ The `main` file points to **build/index.js**
     ╰── build/index.js ➡️  ✅ Node resolves to this module.
@@ -379,7 +379,7 @@ A config plugin in a node module (without an **app.plugin.js**) will use the `ma
 This is different to how Node modules work because **app.plugin.js** won't be resolved by default in a directory. You'll have to manually specify `./my-config-plugin/app.plugin.js` to use it, otherwise **index.js** in the directory will be used.
 
 ```
-╭── app.config.js ➡️ Expo Config
+╭── app.config.js ➡️ App config
 ╰── my-config-plugin/ ➡️ Folder containing plugin code
     ╰── index.js ➡️ ✅ By default, Node resolves a folder's index.js file as the main file.
 ```
@@ -394,7 +394,7 @@ We support this to make testing, and plugin authoring easier, but we don't expec
 - <NoIcon /> `'expo-splash-screen/build'`
 
 ```
-╭── app.config.js ➡️ Expo Config
+╭── app.config.js ➡️ App config
 ╰── node_modules/expo-splash-screen/ ➡️ Module installed from npm (works with Yarn workspaces as well).
     ├── package.json ➡️ The `main` file will be used if **app.plugin.js** doesn't exist.
     ├── app.plugin.js ➡️ ❌ Ignored because the reference reaches into the package internals.
@@ -439,13 +439,13 @@ This is because Node environments are often different to iOS, Android, or web JS
 
 Because of this reasoning, the root of a Node module is searched instead of right next to the **index.js**.
 Imagine you had a TypeScript Node module where the transpiled main file was located at **build/index.js**,
-if Expo config plugin resolution searched for **build/app.plugin.js** you'd lose the ability to transpile the file differently.
+if app config plugin resolution searched for **build/app.plugin.js** you'd lose the ability to transpile the file differently.
 
 ## Next step
 
 <BoxLink
   title="Development and debugging"
-  description="Learn about development best practices and debugging techniques for Expo config plugins."
+  description="Learn about development best practices and debugging techniques for app config plugins."
   href="/config-plugins/development-and-debugging"
 />