react-native: Babel error with custom .babelrc since 0.26

I integrate react-native in a existing application. I created a subfolder js with the javascript and start it with this activity:

mReactInstanceManager = ReactInstanceManager.builder()
            .setApplication(getApplication())
            .setBundleAssetName("index.android.bundle")
            .setJSMainModuleName("js/index.android")
            .addPackage(new MainReactPackage())
            .setUseDeveloperSupport(BuildConfig.DEBUG)
            .setInitialLifecycleState(LifecycleState.RESUMED)
            .build();

In the js folder I have a .babelrc containing:

{
    "presets": ["react-native"]
}

In my root folder (which also contains node_modules) I have another .babelrc which I need for other build-steps:

{
    "presets": ["es2015"]
}

Since 0.26 react-native complains when I have this file with “es2015” in it. When I delete it, it works:

> SyntaxError: <project>/node_modules/react-native/Libraries/vendor/emitter/EventEmitter.js: Unexpected token (56:13)
>   54 |    */
>   55 |   addListener(
> > 56 |     eventType: String, listener, context: ?Object): EmitterSubscription {
>      |              ^
>   57 |     return this._subscriber.addSubscription(
>   58 |       eventType,
>   59 |       new EmitterSubscription(this._subscriber, listener, context));

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 31 (14 by maintainers)

Most upvoted comments

@ide I’d say that not pre-compiling has actually resulted in tons of issues with Babel config and such,

  • It’s quite problematic to use with other code which is pre-compiled with Babel
  • Sourcemaps are screwed up when you’ve dependency that has a .babelrc with different config, sometimes it even breaks the code
  • It’s kinda difficult to use different configs for the other code when the project has different types of code mixed, so you’re pretty much locked to use RN’s preset for everything
  • Since the packager transpiles node_modules, we’ve to be careful about which transforms we enable not to affect third party code, for example, enabling strict mode breaks many third party modules

Though it’s not really RN not being pre-compiled, but packager transpiling code it’s not supposed to, the simplest solution is to pre-compile RN code. I personally had lots of issues with it which wouldn’t exist if RN was pre-compiled.

I think @cpojer also wanted to do this to improve Jest’s performance. @davidaurelio also said that he wanted to do this.