animated-value-initialization corrupts the 2nd+ occurrence of the same pattern in a file (crashes react-native-screens)

[dzengi]

Description

animated-value-initialization (the optimizer that rewrites useRef(new Animated.Value(0)).current into the built-in useAnimatedValue(0) hook) corrupts every occurrence after the first one when the same pattern appears more than once in a single function.

Reproduction

react-native-screens' InnerScreen (src/components/Screen.tsx) has three back-to-back instances of the pattern:

const closing = React.useRef(new Animated.Value(0)).current;
const progress = React.useRef(new Animated.Value(0)).current;
const goingForward = React.useRef(new Animated.Value(0)).current;

With animated-value-initialization enabled (the default for React Native 0.83+), Metro compiles this to:

var closing = (0, _reactNative.useAnimatedValue)(0);
var progress = _reactNative(0);        // <- calls the namespace import as a function
var goingForward = _reactNative(0);    // <- same here

Only the first occurrence gets the correct (0, _reactNative.useAnimatedValue)(0) call. The second and third become a bare call on the _reactNative namespace object itself, which throws at runtime:

Render Error
Object is not a function

This crashes on every screen mount, since InnerScreen is used by every react-navigation/react-native-screens screen.

Root cause

In animated-value-initialization's MemberExpression visitor (src/plugin → compiled to dist/plugin/index.js), the hook identifier returned by addFileImportHint is cached per nameHint on the file (to avoid inserting duplicate imports) and then reused by reference as the callee for every matching call site:

const hook = addFileImportHint({ file, nameHint: hookName, path, importName: hookName, moduleName });
const replacement = core.types.callExpression(
  hook, // <- same AST node object reused as callee at every call site
  constructor.expression.arguments.map((argument) => core.types.cloneNode(argument, true))
);

Because the exact same node object ends up as the callee of multiple distinct CallExpressions in the tree, a later Babel pass (the commonjs/interop transform that wraps a namespace-member call in (0, ns.method)(...)) only transforms it correctly the first time it visits that node instance and leaves the other call sites referencing the untransformed namespace object.

Fix

Cloning the import reference at each use site fixes it:

  const replacement = core.types.callExpression(
-   hook,
+   core.types.cloneNode(hook, true),
    constructor.expression.arguments.map((argument) => core.types.cloneNode(argument, true))
  );

We're carrying this as a local patch-package patch for now. Happy to open a PR with this one-line fix if useful.

Environment

• react-native-boost: 2.0.2
• react-native: 0.86.3
• react-native-screens: 4.28.0
• Config: withBoostConfig via Metro (react-native-boost/metro), default optimizations, Expo SDK 57

[dzengi]

One more observation while looking at the plugin internals for this bug: baking library-specific integrations (Uniwind, Unistyles) directly into react-native-boost's own optimizer code (integrations.uniwind, integrations.unistyles, the UNISTYLES_NATIVE_TEXT_MODULE/UNISTYLES_NATIVE_VIEW_MODULE constants, the Uniwind resolver branch in withBoostConfig, etc.) seems like the wrong layer for that knowledge to live in.

Each of those libraries changes independently of Boost's release cycle, and this bug is a good example of why: a shared helper (addFileImportHint) is reused across both the generic optimizers and the integration-specific code paths, so a bug in one code path (or a future one added for the next integration) risks the same kind of cross-contamination. Keeping third-party integrations as separate, opt-in plugins (or at least isolating their AST-mutation helpers from the generic optimizers') would reduce that coupling and let Uniwind/Unistyles support evolve without needing a Boost release for every change on their side.

[santhosh-umapathi-wikifolio]

Hit the same crash after upgrading from 1.6.0 to 2.0.2 on react-native 0.87.1 (bare CLI, New Architecture, Metro 0.87.1, Hermes), so it isn't specific to 0.86. Both iOS and Android crash on startup with Property '_useAnimatedValue' doesn't exist from react-native-screens/src/components/Screen.tsx.

I accidentally opened a duplicate (#116, closing it now). It has a few extra details that may help:

• Babel-only minimal repro. Two React.useRef(new Animated.Value(n)).current in one function, transformed with just @react-native/babel-preset + react-native-boost/plugin. The output is (0, _reactNative.useAnimatedValue)(0) for the first call and a bare _useAnimatedValue(1) for the second.
• Workaround without patching, via the Metro config:

  withBoostConfig(config, {
    optimizations: { 'animated-value-initialization': 'off' },
  });

• Possibly the same bug elsewhere: animated-wrapper-removal also uses the cached node returned by addFileImportHint directly. I couldn't verify it, since that optimization is off on RN 0.87.

+1 for the cloneNode fix.