Set transformer.allowOptionalDependencies to true by default

[brentvatne]

Describe the Feature

facebook/metro#511 added support for allowOptionalDependencies to Metro. This allows us write code like this:

try {
  require('does-not-exist');
} catch {
  console.log('could not load does-not-exist')
}

This is particularly useful for library authors, and would have been helpful during the "lean core" efforts (react-native-community/discussions-and-proposals#120) but will continue to be useful in environments where libraries want to either: a) support multiple implementations of some primitive and automatically switch between them depending on which one the developer uses b) provide some behavior in their library that works if the developer has installed an optional peer dependency or fallback to something else and/or provide some warning otherwise.

Possible Implementations

We would just need to add allowOptionalDependencies: true to the default transformer config in

cli/packages/cli/src/tools/loadMetroConfig.ts

Lines 108 to 116 in 22a3c25

	transformer: {
	babelTransformerPath: require.resolve(
	'metro-react-native-babel-transformer',
	),
	assetRegistryPath: 'react-native/Libraries/Image/AssetRegistry',
	asyncRequireModulePath: require.resolve(
	'metro-runtime/src/modules/asyncRequire',
	),
	},

This should not break any existing apps, but libraries that adopt optional imports will only work on newer versions of Metro/this CLI that use this config.

Related Issues

• add optional dependency support facebook/metro#511
• Optional imports in Metro discussions-and-proposals#120

[thymikee]

Sure, sounds reasonable and non-breaking. Happy to accept a PR :)

[brentvatne]

@thymikee - will open a PR for this shortly!

one more question - do you think it would be possible to backport this and a version bump to depend on metro@0.59 (the first release that includes this feature - it shipped in March of last year) to a CLI version that is compatible with react-native@0.63? we're hoping to leverage this functionality to move away from .expo.js extensions

[thymikee]

Yup, we can do it!

[brentvatne]

merged in #1350