Bugs when transformer.allowOptionalDependencies=true

[motiz88]

This issue tracks known bugs in the implementation of allowOptionalDependencies in #511.

While allowOptionalDependencies is off by default in Metro, it is on by default for apps built using the React Native CLI: react-native-community/cli#1350.

Bug 1: Unresolved optional dependencies are broken at runtime, along with subsequent requires/imports in the same file.

Repro: https://github.com/motiz88/metro-optional-deps-bug-1

const A = require('./a.js');
let B;
try {
  B = require('./b.js');
} catch {}
const C = require('./c.js');

The above module compiles to

const A = metroRequire(dependencyMap[0]);
let B;
try {
  B = metroRequire(dependencyMap[1]);
} catch {}
const C = metroRequire(dependencyMap[2]);

Where dependencyMap is assumed to have an entry for each required module. But if ./b.js is unresolved at build time, dependencyMap will only have entries for A and C. Therefore the following lines behave incorrectly:

B = metroRequire(dependencyMap[1]); // B evaluates to require('./c.js') !
const C = metroRequire(dependencyMap[2]); // C evaluates to metroRequire(undefined), which throws an error

Bug 2: If an optional dependency is unresolved and later becomes resolvable (e.g. the package is installed while Metro is running), Metro will not detect this unless the origin file is also modified (or Metro is restarted).

This is because we don't always invalidate dependency resolutions correctly. In this case, we do not track the relationship between the initially-missing dependency (and the paths it might appear in) and the origin file, so Metro has no reason to mark the origin file as modified when the dependency later appears. (This is a broader problem with our resolver architecture that affects more than just optional dependencies.)

[zhiqingchen]

Does anyone know how to solve this problem?

[lucasloisp]

Useful context here, is this is a known limitation, even if (arguably) not easy to learn about:

Dependencies after an unresolved optional dependency (such as c.js after b.js) are, as you mention, dropped altogether from the dependency map, which means B evaluates as C and C is the one that fails.

This can be worked around by spltting your files so whatever optional requires you have are the last require done in any given file. Fixing this (see linked source below) requires propagating the "null/optional" resolution through metro so dependencyMap knows about it in the end.

More context in the source code:

https://github.com/facebook/metro/blob/a3d021a0d021b5706372059f472715c63019e044/packages/metro/src/DeltaBundler/buildSubgraph.js#L93

[jbroma]

@robhogan was this fixed by #1522 ?