Unable to Resolve Module Alias with react-native-builder-bob Configuration

[lucasftcruz]

Description

Issue Description

I've created scaffolded a new library and example app using npx create-react-native-library@latest awesome-library. When trying to add alias paths I am encountering an issue with resolving the new module alias @components in the example app that relies on react-native-builder-bob. Despite configuring the alias in tsconfig.json, babel.config.js, and metro.config.js, I still receive the following error when running the example app:

Error: Unable to resolve module @components/TestView from /Users/lucas.torres/Desktop/Test/awesome-library/example/src/App.tsx: @components/TestView could not be found within the project or in these directories:
  node_modules
  ../node_modules
  1 | import { View, StyleSheet } from 'react-native';
> 2 | import { TestView } from '@components/TestView';
    |                           ^
  3 |
  4 | export default function App() {
  5 |   return (
    at ModuleResolver.resolveDependency (/Users/lucas.torres/Desktop/Test/awesome-library/example/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:148:15)
    at DependencyGraph.resolveDependency (/Users/lucas.torres/Desktop/Test/awesome-library/example/node_modules/metro/src/node-haste/DependencyGraph.js:235:43)
    at /Users/lucas.torres/Desktop/Test/awesome-library/example/node_modules/metro/src/lib/transformHelpers.js:160:21
    at resolveDependencies (/Users/lucas.torres/Desktop/Test/awesome-library/example/node_modules/metro/src/DeltaBundler/buildSubgraph.js:42:25)
    at visit (/Users/lucas.torres/Desktop/Test/awesome-library/example/node_modules/metro/src/DeltaBundler/buildSubgraph.js:83:30)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 2)
    at async visit (/Users/lucas.torres/Desktop/Test/awesome-library/example/node_modules/metro/src/DeltaBundler/buildSubgraph.js:92:5)
    at async Promise.all (index 0)
    at async buildSubgraph (/Users/lucas.torres/Desktop/Test/awesome-library/example/node_modules/metro/src/DeltaBundler/buildSubgraph.js:103:3)

Importing the relative path works as expected import { TestView } from '../../src/components/TestView';

I have ensured that the alias is consistently defined across all configuration files, but the issue persists. Any guidance on resolving this would be greatly appreciated.

A section in the faq.md would be very useful

Packages

• create-react-native-library
• react-native-builder-bob

Selected options

Link to repro

https://github.com/lucasftcruz/awesome-library

Environment

System:
  OS: macOS 14.7.3
  CPU: (12) arm64 Apple M2 Pro
  Memory: 118.16 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.18.1
    path: ~/.nvm/versions/node/v18.18.1/bin/node
  Yarn:
    version: 3.6.1
    path: ~/.nvm/versions/node/v18.18.1/bin/yarn
  npm:
    version: 9.8.1
    path: ~/.nvm/versions/node/v18.18.1/bin/npm
  Watchman:
    version: 2024.07.15.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/lucas.torres/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.1
      - iOS 18.1
      - macOS 15.1
      - tvOS 18.1
      - visionOS 2.1
      - watchOS 11.1
  Android SDK:
    API Levels:
      - "31"
      - "32"
      - "33"
      - "34"
      - "35"
    Build Tools:
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
    System Images:
      - android-33 | Google APIs ARM 64 v8a
      - android-33 | Google APIs Intel x86_64 Atom
      - android-33 | Google Play ARM 64 v8a
      - android-33 | Google Play Intel x86_64 Atom
      - android-34 | Google APIs ARM 64 v8a
      - android-34 | Google APIs Intel x86_64 Atom
      - android-34 | Google Play ARM 64 v8a
      - android-34 | Google Play Intel x86_64 Atom
    Android NDK: Not Found
IDEs:
  Android Studio: 2024.2 AI-242.23339.11.2421.12550806
  Xcode:
    version: 16.1/16B40
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.11
    path: /usr/bin/javac
  Ruby:
    version: 3.1.4
    path: /Users/lucas.torres/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.1
    wanted: 15.0.1
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.77.0
    wanted: 0.77.0
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: false

[lucasftcruz]

@atlj We managed to get it working by passing overrides to example/babel.config as below (no need changes are needed in metro.config)

const path = require('path');
const { getConfig } = require('react-native-builder-bob/babel-config');
const pkg = require('../package.json');

const root = path.resolve(__dirname, '..');

module.exports = getConfig(
  {
    presets: ['module:@react-native/babel-preset'],
    overrides: [
      {
        plugins: [
          [
            'module-resolver',
            {
              root: path.join(root, 'src'),
              extensions: ['.tsx', '.ts', '.jsx', '.js', '.json'],
              alias: {
                // This needs to be mirrored in tsconfig.json
                '@components': path.join(root, 'src/components'),
              },
            },
            'awesome-library',
          ],
        ],
      },
    ],
  },
  { root, pkg }
);

[satya164]

There are many problems that need to be solved for module aliases to be viable in libraries.

If you're using aliases you need to make sure that the aliases don't exist in the published library and everything is transformed to regular paths. Otherwise those aliases need to exist on the user's app, where they may already have aliases with the same name.

It is possible to transform paths for the compiled JS if you configure babel properly, however the generated type definitions will still include aliases that'll break.

So current recommendation is to avoid using aliases unless you can make sure that all of the published code including both compiled JS and type definitions contain transformed paths instead of aliases.