How do I use module aliases within a package?

[chriscoomber]

In my package, I want to add to its tsconfig.json:

  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  },

This means that when writing my package, I can avoid relative imports, e.g. instead of:

import { foo } from '../../utils'

I can write:

import { foo } from '@/utils'

However, this doesn't affect the emitted code at all. Indeed, just to make my tests work I need to add the following to jest.config.js:

moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1'
  }

It's even worse for consumers of my package. They will get lots of errors barfing at @/utils, even though these imports lie solely within my package. They could fix this (I think?) by configuring their babel/metro/webpack config to do the same alias, but that's a lot of configuration to inflict upon them.

Since react-native-bundler-bob is the thing packaging my code, is there some configuration I should do there to get it to work?

E.g. is there a way to resolve the aliases in my emitted source code (i.e. turn them back into relative aliases) on emit only?

I tried adding:

  plugins: [
    ['module-resolver', { root: ['./src'] }]
  ]

to babel.config.js in my package's directory, and passing "configFile": true in the react-native-bundler-bob config in package.json, but that didn't help.

[satya164]

It's not that simple. Since you're publishing a library, first you need to make sure that generated TypeScript definitions rewrite the imports - which TypeScript doesn't support. So you'll need to use some third party tool like ts-patch or something else to build your definitions achieve that.

Then you need to configure babel plugin module resolver both in the example app, and in the library - and make sure bob uses that as well using the configFile option.

In addition you need to remove the react-native entry from your package.json as it points to the source code, but consumers can't use that because it contains aliases.

If you are linting your code, you may also need to configure ESLint if any plugins deal with imports.

It's simpler not to use aliases. With auto-import etc. there isn't much practical benefit of doing that.