[config] Create dynamic config "app.config.js"

[EvanBacon]

Why

Problems with the existing solution: app.json

• can't swap between modes like development and production
• no way to comment and document your config
• can't share parts of your config across multiple projects
• hard to discover what features are available
• hard to know what everything in the config does
• config types aren't in the monorepo and can't be easily changed

How

If a project has an app.config.js, that will take priority over an app.json. You can use the app.config.js to modify your app.json using environment variables or custom JS plugins. Here is how you might modify your project's app.json using the new app.config.js:

// config is generated from the package.json and the app.json.
module.exports = function({ projectRoot, config, mode }) {
  // Use the mode to control how the app works in dev vs prod
  config.name = mode === 'development' ? 'dev app' : 'prod app';
  // Return the modified config
  return config;
}

Also add support for the following config types:

• app.config.js

• app.config.json

• app.config.json5 - disabled via @ide request

• Added but disabled:

  • app.config.ts
  • app.config.yml
  • app.config.yaml
  • app.config.toml

• I'm somewhat against the idea of having multiple different languages for the config. At the very least we could just add them later after app.config.js has migrated.

• Only allow sync configs to maintain usability with Next.js.

Test Plan

• Add tests for reading from and validating each language
• Add a test for ensuring that app.config has higher priority than app.json
• Add a test to ensure the app.config.js method is passed the app.json and a mode option
• Ensure that other language app files don't get read (like app.yml, app.json5)
• Enforce that the config is always serialized to JSON so it can be used for the manifest.

[brentvatne]

one tradeoff worth noting here is that we won't be able to automate updating config for people after this, at least not with the .js extension.

so when we run expo upgrade we can't change the sdk version, and automating updating things like version/buildNumber etc will be more difficult in the future and for packages like @byCedric's semantic-release-expo.

re: sdk version, honestly we should move the source of truth for this to package.json anyways, and just use whatever sdk version corresponds to the expo package. that might be something we want to do before landing this.

are there any other tradeoffs you can think of?

[EvanBacon]

Currently we do read the sdkVersion from the expo/package.json. sdkVersion is only used for locking down a version or using UNVERSIONED. Having a js config opens up room for plugins so we could potentially migrate scripts to dynamic classes that you add in the config.

[brentvatne]

oh i did not realize we had made that change, nice!

[byCedric]

Don't worry about the semantic release, it wasn't using Expo components anyways. I'll rework that library. If other automation tools are using the proper packages, like @expo/config, I don't think anyone else will have a lot of issues here.

Also, the getExpoSDKVersion is 🔥

[brentvatne]

this is pretty big so i don't think i'll deploy it until the new year. will review it then as well :)

[EvanBacon]

Maybe we should also add expo icon to VSCode for app.config.js https://github.com/vscode-icons/vscode-icons/wiki/ListOfFiles

[EvanBacon]

Added a method to ensure the config is always serialized before being read.

[fson]

This is very good I think.

I made a few comments regarding the developer experience – let's make sure the new format is easily debuggable and errors very clear from the beginning.

[fson]

Maybe we want to get rid of this capability, and make the JSON/JS configurations mutually exclusive, for a few reasons:

• Having the configuration split across two files is more confusing for new users or anyone coming across a project that does this. Now you must know two ways to do the same thing. Now you need to check two files to confirm what configuration value is used.
• When responding to issues the common question "please show us your app.config.js" becomes "please show us your app.config.js and app.json (and package.json)"
• JS can include JSON inside it. It can also import configuration from an arbitrary JSON file, if a static format is desired for some values.

[EvanBacon]

Having the configuration split across two files

We support this functionality for values that are generated by Expo CLI like bundleIdentifier. I'm totally open to better ideas though. I imagine a new project's config would look something like:

module.exports = function({ config }) {
  return {
  ...config,
  icon: 'assets/icon.png',
  /* etc... */
  }
}

The spread of another config is somewhat unpleasant.

responding to issues

We can add a mechanism for printing out the serialized config after it's been returned from app.config.js.

if a static format is desired for some values.

I imagine eventually app.json will be the static location for generated values.

[brentvatne]

When responding to issues the common question "please show us your app.config.js" becomes "please show us your app.config.js and app.json (and package.json)"

maybe we could add this to expo diagnostics? and we could automatically filter out any potentially sensitive fields

[EvanBacon]

all we'd have to do to support this is switch the method used to read the config file.