Customize babel config by merging new config in, not completely replacing the default config

[chriscoomber]

I'm using my library with a custom babel.config.js file:

babel.config.js

module.exports = {
  presets: ['@react-native/babel-preset'],
  plugins: [
    [
      'module-resolver',
      {
        root: ['./src'],
        alias: {
          'awesome-package/src': './src/'
        }
      }
    ]
  ]
}

In my package.json I do:

"react-native-builder-bob": {
    "source": "src",
    "output": "lib",
    "targets": [
      [
        "commonjs",
        {
          "configFile": true
        }
      ],
      [
        "module",
        {
          "configFile": true
        }
      ],
      [
        "typescript",
        {
          "project": "tsconfig.build.json"
        }
      ]
    ]
  }

However, this means I lose the well-honed default babel config (see compile.ts) since it gets completely replaced. I don't know enough to know what I'm missing; it was working fine before I added a custom babel.config.js, but I needed to add the module-resolver plugin for other reasons.

Should there a way to just add this one extra plugin to the default config?

Why do I care

I need to do a few things that aren't in the default config:

1. Add the alias you see above
2. I want to use the "new" JSX transform so that my library doesn't need to keep importing React. @react-native/babel-preset does this by default.

Unfortunately, with the solution I have above, I would need to provide presets: [['@react-native/babel-preset', { disableImportExportTransform: true }]], just for ESM, to stop it stripping import/export syntax. This means I need two babel config files. It would be much easier to just add in my module-resolver plugin, and add

    ["@babel/preset-react", {
      "runtime": "automatic"
    }]

to the default config.

[satya164]

Such modifications are currently not supported properly as it's not straightforward and needs more work.

If you're shipping source code (in the react-native field in package.json), if you change the way your library code is compiled, it means consumers also need to change their babel config so your library's source code is compiled properly as long as you're shipping the source code.

And if you're using module resolver, you also need to make sure that it doesn't conflict with paths in your example app.

As of now, I recommend not customizing the babel config.

[chriscoomber]

Hmm, ok thanks for the reply. I see your point regarding supporting both consumers of the source code, and consumers of the compiled code.

Apologies if I'm giving too much detail in my response below. I'm trying to make a case that what I'm doing isn't crazy. But I'm always willing to replace my approach with a more standard approach (I just don't know enough to know how these things should work!)

The first section is probably the most relevant to you. The rest are more of a cry for help!

Should react-native-builder-bob have a config option for the "New JSX transform"

I think adding a config option to user the new JSX transform would be nice, even if we can't add plugins in general (this other discussion mentions it too). You already include @babel/preset-react in your default babel config, we just need to set runtime: 'automatic' on it. This would be:

• better for me, the library maintainer, because I don't have to import React at the top of every JSX source file (and make sure my eslint rules warn me if I forget)
• better for consumers of the compiled code, because according to that first link, the new transform can reduce bundle size
• slightly worse for consumers of the source code, because they need to also use the new JSX transform.
  • However, I'm only arguing that this should be an option in react-native-builder-bob, so as the library maintainer I can decide whether to use the transform (requiring source-code consumers to also use it).
  • Also, it sounds like the plan is for every react environment to switch over to the new transform: react-native init, create-expo-app and NextJS already use the new transform. I reckon most consumers wouldn't need to do any setup here.

Is what I'm doing with the module resolver sane?

You're right that I need to be careful using the module resolver, as that only affects the compiled code, so consumers of my source code would need to add the same setup. I can tell you a bit about my setup, and how I think I'm using it in a safe way.

My library (let's call it "awesome-package") code has two main users:

• one within the same monorepo, consuming the source code directly, since it's a react-native (expo) app: "awesome-app"
• one somewhere else, consuming the compiled code, which is a react (nextJS) website: "awesome-website"

(awesome-package is is a bunch of react-native components, so I already require some configuration in awesome-website to alias react-native to react-native-web. I just followed this guide: https://docs.expo.dev/guides/using-nextjs/)

I have a bunch of soft requirements:

1. In awesome-app, I'd like to import "deeply", e.g. import Foo from 'awesome-package/path/to/Foo';
2. In awesome-website, I'd like to import "deeply", e.g. import Foo from 'awesome-package/path/to/Foo';
   • This is particularly important because awesome-website needs to dynamically import some components at some times, without importing everything together, for performance reasons (e.g. SSR and CSR), so exposing the whole of awesome-package in a single index.js file would be bad.
3. In awesome-package, I'd like to be able to import other files using absolute paths, e.g. import Foo from 'awesome-package/path/to/Foo'; rather than import Foo from '../../../../path/to/Foo';.

For (1), this just works, because I'm just importing source code. So I can do import Button from 'awesome-package/src/components/Button';. (There's probably some details I'm omitting, like I think I needed to tell awesome-app's babel.config.js that it was in a monorepo.)

For (2), importing source files would be bad, as the website needs to consume the compiled ESM files. So, I added to awesome-package's package.json:

  "exports": {
    ".": {
      "types": "./lib/typescript/index.d.ts",
      "import": "./lib/module/index.js",
      "require": "./lib/commonjs/index.js"
    },
    "./src/*": {
      "types": "./lib/typescript/*.d.ts",
      "import": "./lib/module/*.js",
      "require": "./lib/commonjs/*.js"
    },
  },

This means that when it tries to import from 'awesome-package/src/components/Button', it's actually importing from 'awesome-package/lib/module/components/Button.js'. I still kept src in the import path, because eslint doesn't understand the exports field of package.json (???), so I am kind of tricking eslint by using a path of a real file 'awesome-package/src/components/Button' but switching it with a different file.

For (3), if the consumer is consuming the source, then this just works, because 'awesome-package/src/components/Button' resolves to a valid source file. However, if the consumer is consuming the compiled code, it would be very wrong for that compiled code to import source code. That's where the module resolver babel plugin I posted above comes in, and that's why I think I need it.

My current workaround

I ended up with, after a day or so of banging my head against this:

babel.config.js:

module.exports = {
  presets: [['@react-native/babel-preset', { disableImportExportTransform: true }]],
  plugins: [[
      'module-resolver',
      {
        root: ['./src'],
        alias: {
          'common/src': './src/'
        },
        extensions: [
          '.ios.tsx',
          '.android.tsx',
          '.web.tsx',
          '.tsx',
          '.json'
        ]
      }
    ]
  ]
};

babel.config.commonjs.js:

const base = require('./babel.config');
module.exports = {
  ...base,
  presets: [['@react-native/babel-preset', { disableImportExportTransform: false }]]
};

package.json:

{
  "main": "lib/commonjs/index.js",
  "module": "lib/module/index.js",
  "types": "lib/typescript/index.d.ts",
  "react-native": "src/index.ts",
  "source": "src/index.ts",
  "exports": {
    ".": {
      "types": "./lib/typescript/index.d.ts",
      "import": "./lib/module/index.js",
      "require": "./lib/commonjs/index.js"
    },
    "./src/*": {
      "types": "./lib/typescript/*.d.ts",
      "import": "./lib/module/*.js",
      "require": "./lib/commonjs/*.js"
    },
    "./package.json": "./package.json"
  },
  "react-native-builder-bob": {
    "source": "src",
    "output": "lib",
    "targets": [
      [
        "commonjs",
        {
          "configFile": "./babel.config.commonjs.js"
        }
      ],
      [
        "module",
        {
          "configFile": "./babel.config.js"
        }
      ],
      [
        "typescript",
        {
          "project": "tsconfig.build.json"
        }
      ]
    ]
  },
  ...etc...
}

Edit to add:
My hope is that just using @react-native/babel-preset is good enough. But that's where my original question came in. Would it be a good idea for me to try to replicate your default config (in compile.ts) as closely as possible, with just my additions?

[satya164]

It's now possible to extend the configuration of react-native-builder-bob by using the react-native-builder-bob/babel-preset.

Should react-native-builder-bob have a config option for the "New JSX transform"

I don't think we'll add an option for this, but we're going to enable it by default (#577). But this requires us removing react-native field from package.json similar to other babel config related changes.

Is what I'm doing with the module resolver sane?

The main blocker is react-native field from package.json. We're going to remove it soon and then it's possible to do any customization you want. And you can remove that field in your own package already.

For the exports field in package.json, the current way of compiling the code is insufficient, at least in NodeJS. ES modules require file extensions in imports as well as .mjs and .cjs extensions for disambiguation. So it's not safe to use it right now. We're working on this (#577).

Also note that Metro doesn't support exports field without experimental flags.

For exposing deep imports, I'd generally suggest to create a folder at the root of the package with a package.json - and the fields in the package.json can refer to the files in lib/module, lib/commonjs etc. It should be supported by all tools and is possible to do right now.