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.

satya164 on May 23, 2016