Config files loaded through node_modules/<pkg> symlinks cannot resolve the package's declared dependencies

[mwolson]

• Repro repo: https://github.com/mwolson/tmp-aube-issues
• Repro case: package-config-symlink-resolution
• aube version: 1.15.0 linux-x64 (2026-05-17)
• Node version: v24.15.0
• pnpm comparison: the reduced repro also fails with pnpm 11.1.3

Summary

I hit this while testing an Expo / React Native app under aube. Expo's react-native.config.js requires one of Expo's declared dependencies, but when the config is loaded through the package's top-level node_modules/expo/... symlink, that dependency is not resolvable. Loading the same config file after fs.realpathSync(...) works.

The reduced repro is intentionally tiny:

• The app depends on a tarball package named config-owner.
• config-owner declares is-number as its own dependency.
• config-owner/react-native.config.js does require("is-number").
• The app uses require-from-string to load node_modules/config-owner/react-native.config.js, matching the kind of config-loader path that exposed this in Expo autolinking.

Repro

git clone https://github.com/mwolson/tmp-aube-issues
cd tmp-aube-issues/package-config-symlink-resolution
./repro.sh

repro.sh exits zero when the config load works and non-zero when the issue is observed.

Current output excerpt with aube 1.15.0:

aube: 1.15.0 linux-x64 (2026-05-17)
node: v24.15.0

Observed issue:
- Loading through node_modules symlink failed: Cannot find module 'is-number'
- Loading through fs.realpathSync(...) succeeded and resolved .../is-number/index.js

Real-world impact

In the original Expo / React Native case, expo/react-native.config.js contains a direct require of expo-modules-autolinking/exports. When that config load fails, autolinking appears to ignore Expo's config and falls back to parsing the native Android sources. That produced a generated PackageList.java with this stale import:

import expo.core.ExpoModulesPackage;

The correct config-provided import is:

import expo.modules.ExpoModulesPackage;

Adding expo-modules-autolinking@2.0.8 directly to the app made the Gradle autolinking command generate the correct import, but that feels like a workaround. expo already declares that dependency.

Question

Is this expected behavior for a pnpm-style isolated symlink layout, where config loaders need to call fs.realpathSync(...) before evaluating package-owned config files? Or is this something aube should mitigate or document more explicitly?

I noticed that the reduced repro also fails under pnpm 11.1.3, so I am not claiming aube diverges from pnpm here. The aube-specific concern is that this is easy to hit through toolchains that evaluate package config files by path, and the failure mode can be indirect: the config load is swallowed, then a fallback generates incorrect native autolinking output.

Relevant docs I checked:

• https://aube.en.dev/package-manager/node-modules
• https://aube.en.dev/settings/#node_modules
• https://aube.en.dev/troubleshooting

Potential options I can see for mitigation:

• Have aube fix this issue
• Document that package config loaders should resolve symlinks before evaluating config files.
• Suggest node-linker=hoisted for toolchains that load dependency-owned config through top-level symlink paths.

[jdx]

Thanks for the detailed repro. Since the reduced case also fails under pnpm 11.1.3, I do not think this is an aube parity bug. It is a pnpm-style isolated symlink layout compatibility issue with config loaders that evaluate dependency-owned config files through node_modules/<pkg>/... without resolving the real path first.

The important distinction is that config-owner/expo can declare the dependency correctly and still fail if the loader preserves the top-level symlink path as the config file identity. The package dependencies are linked next to the package real path under the virtual store, so loaders should fs.realpathSync(...) the discovered config path before evaluating it.

For aube, I opened a docs PR to call this out more explicitly and mention node-linker=hoisted as the compatibility workaround when the upstream loader cannot be changed: #759

If you want to push this upstream, the best target is probably the React Native / Expo autolinking loader path rather than pnpm. I did not find an exact open upstream issue for this specific realpath/config-loader failure mode, though there are related Expo/RN + pnpm compatibility issues.

This comment was generated by Codex.