Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bugs when transformer.allowOptionalDependencies=true #836

Open
motiz88 opened this issue Jun 18, 2022 · 1 comment
Open

Bugs when transformer.allowOptionalDependencies=true #836

motiz88 opened this issue Jun 18, 2022 · 1 comment

Comments

@motiz88
Copy link
Contributor

motiz88 commented Jun 18, 2022

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
Copy link
Contributor

Does anyone know how to solve this problem?

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

No branches or pull requests

2 participants