Skip to content

Enable allowOptionalDependencies by default (#1775)#1775

Closed
robhogan wants to merge 1 commit into
mainfrom
export-D111577052
Closed

Enable allowOptionalDependencies by default (#1775)#1775
robhogan wants to merge 1 commit into
mainfrom
export-D111577052

Conversation

@robhogan

@robhogan robhogan commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Summary:

Flip the default value of the transformer.allowOptionalDependencies Metro config option from false to true in metro-config's own defaults.

This allows for patterns like:

let dep = null;
try {
  // If not installed, allowOptionalDependencies ===
  //   true => throw at runtime, handled by catch
  //   false => throw at build time
  dep = require('maybe-installed-dependency');
} catch {
  dep = require('./my-fallback');
}

Which comes up in popular packages, eg lru-cache.

Note that this is already the default in:

There were previously known problems with allowOptionalDependencies and the behaviour of subsequently declared dependencies, and they were also broken under HMR if their existence changed. These were both fixed a year ago in #1522.

The heuristic was also quite limited, for example a try { require() } was considered optional but an import().catch() was not. That was fixed in #1697.

I can't think of any good reason not to enable this and fix the misalignment with RN/Expo.

With this enabled, dependencies referenced inside try/catch blocks (and dynamic import()s with rejection handlers) are treated as optional by default: an unresolvable optional dependency no longer fails the build, matching the common expectation for guarded requires. Projects can still opt out by explicitly setting allowOptionalDependencies: false.

Since this change doesn't alter observable runtime behaviour (it allows bundles to build that would otherwise fail to build), I'm inclined to regard it as non-breaking.

 - **[Feature]**: `allowOptionalDependencies` defaults to `true` to align with RN and Expo

Reviewed By: huntie

Differential Revision: D111577052

@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jul 13, 2026
@meta-codesync

meta-codesync Bot commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

@robhogan has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111577052.

Summary:

Flip the default value of the `transformer.allowOptionalDependencies` Metro config option from `false` to `true` in `metro-config`'s own defaults.

This allows for patterns like:

```js
let dep = null;
try {
  // If not installed, allowOptionalDependencies ===
  //   true => throw at runtime, handled by catch
  //   false => throw at build time
  dep = require('maybe-installed-dependency');
} catch {
  dep = require('./my-fallback');
}
```

Which comes up in popular packages, eg [`lru-cache`](https://github.com/isaacs/node-lru-cache/blob/16b3a916662ab449d496b7b4b4f04132565d1d28/src/diagnostics-channel-esm.mts#L24-L29).

Note that this is *already the default* in:
 - `react-native/metro-config`: https://github.com/react/react-native/blob/a632f9efe24bac8b3a113c78469948f55bde0f5d/packages/metro-config/src/index.flow.js#L86
 - And `expo/metro-config`: https://github.com/expo/expo/blob/ab042edb8228e3873bdbd8e04b7c61cd3e00372e/packages/%40expo/metro-config/src/ExpoMetroConfig.ts#L423

There were previously known problems with `allowOptionalDependencies` and the behaviour of subsequently declared dependencies, and they were also broken under HMR if their existence changed. These were both fixed a year ago in #1522.

The heuristic was also quite limited, for example a `try { require() }` was considered optional but an `import().catch()` was not. That was fixed in #1697.

I can't think of any good reason not to enable this and fix the misalignment with RN/Expo.

With this enabled, dependencies referenced inside `try/catch` blocks (and dynamic `import()`s with rejection handlers) are treated as optional by default: an unresolvable optional dependency no longer fails the build, matching the common expectation for guarded requires. Projects can still opt out by explicitly setting `allowOptionalDependencies: false`.

Since this change doesn't alter observable runtime behaviour (it allows bundles to build that would otherwise fail to build), I'm inclined to regard it as non-breaking.

```
 - **[Feature]**: `allowOptionalDependencies` defaults to `true` to align with RN and Expo
```

Reviewed By: huntie

Differential Revision: D111577052
@meta-codesync meta-codesync Bot changed the title Enable allowOptionalDependencies by default Enable allowOptionalDependencies by default (#1775) Jul 13, 2026
@meta-codesync meta-codesync Bot force-pushed the export-D111577052 branch from 272ce4c to ca92b8f Compare July 13, 2026 13:47
meta-codesync Bot pushed a commit that referenced this pull request Jul 13, 2026
Summary:

Flip the default value of the `transformer.allowOptionalDependencies` Metro config option from `false` to `true` in `metro-config`'s own defaults.

This allows for patterns like:

```js
let dep = null;
try {
  // If not installed, allowOptionalDependencies ===
  //   true => throw at runtime, handled by catch
  //   false => throw at build time
  dep = require('maybe-installed-dependency');
} catch {
  dep = require('./my-fallback');
}
```

Which comes up in popular packages, eg [`lru-cache`](https://github.com/isaacs/node-lru-cache/blob/16b3a916662ab449d496b7b4b4f04132565d1d28/src/diagnostics-channel-esm.mts#L24-L29).

Note that this is *already the default* in:
 - `react-native/metro-config`: https://github.com/react/react-native/blob/a632f9efe24bac8b3a113c78469948f55bde0f5d/packages/metro-config/src/index.flow.js#L86
 - And `expo/metro-config`: https://github.com/expo/expo/blob/ab042edb8228e3873bdbd8e04b7c61cd3e00372e/packages/%40expo/metro-config/src/ExpoMetroConfig.ts#L423

There were previously known problems with `allowOptionalDependencies` and the behaviour of subsequently declared dependencies, and they were also broken under HMR if their existence changed. These were both fixed a year ago in #1522.

The heuristic was also quite limited, for example a `try { require() }` was considered optional but an `import().catch()` was not. That was fixed in #1697.

I can't think of any good reason not to enable this and fix the misalignment with RN/Expo.

With this enabled, dependencies referenced inside `try/catch` blocks (and dynamic `import()`s with rejection handlers) are treated as optional by default: an unresolvable optional dependency no longer fails the build, matching the common expectation for guarded requires. Projects can still opt out by explicitly setting `allowOptionalDependencies: false`.

Since this change doesn't alter observable runtime behaviour (it allows bundles to build that would otherwise fail to build), I'm inclined to regard it as non-breaking.

```
 - **[Feature]**: `allowOptionalDependencies` defaults to `true` to align with RN and Expo
```

Reviewed By: huntie

Differential Revision: D111577052
@meta-codesync meta-codesync Bot closed this in 948f730 Jul 13, 2026
@meta-codesync meta-codesync Bot added the Merged label Jul 13, 2026
@meta-codesync

meta-codesync Bot commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

This pull request has been merged in 948f730.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged meta-exported

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant