undefined is not a function (evaluating 'babelHelpers.typeof(obj)') using nes library

[byoigres]

Hey there!

I'm trying to use nes library with react-native with no success.

I included nes in a fresh react-native project like this:

import React, { Component } from 'react';

import {
  AppRegistry,
  StyleSheet,
  Text,
  View
} from 'react-native';

import { Client as NesClient } from 'nes/client';

But I'm getting the following error:

And after trying to add nes in one or another way I came out with this:

If I modify the file nes/dist/client.js like this:

var _typeof = typeof Symbol === "function" && typeof Symbol.iterator === "symbol" ? function (obj) { return typeof obj; } : function (obj) { return obj && typeof Symbol === "function" && obj.constructor === Symbol ? "symbol" : typeof obj; };

(function (root, factory) {

    // $lab:coverage:off$
/*
    if ((typeof exports === 'undefined' ? 'undefined' : _typeof(exports)) === 'object' && (typeof module === 'undefined' ? 'undefined' : _typeof(module)) === 'object') {
        module.exports = factory(); // Export if used as a module
    } else if (typeof define === 'function' && define.amd) {
            define(factory);
        } else if ((typeof exports === 'undefined' ? 'undefined' : _typeof(exports)) === 'object') {
            exports.nes = factory();
        } else {
            root.nes = factory();
        }
*/
    module.exports = factory();
    // $lab:coverage:on$
})( /* $lab:coverage:off$ */typeof window !== 'undefined' ? window : global /* $lab:coverage:on$ */, function () {
 // ...
});

Everything works perfectly, But I can't totally understand with running _typeof({}); throws the same error as the image above.

Also, if I open the remote debugger (with the above "solution") get the following error:

> node -v
v5.9.0
> react-native -v
react-native-cli: 0.2.0
react-native: 0.26.3

package.json
index.android.js

[satya164]

Seems the nes module is pre-compiled with babel using the es2015 preset.React Native uses a different babelHelpers file which might be causing issues. The only workaround I know as of now is to fork React Native and replace it's babelHelpers file with a standard babelHelpers file as documented here -

react-native/packager/react-packager/src/Resolver/polyfills/babelHelpers.js

Line 13 in 235b16d

// require('babel-core').buildExternalHelpers('_extends classCallCheck createClass createRawReactElement defineProperty get inherits interopRequireDefault interopRequireWildcard objectWithoutProperties possibleConstructorReturn slicedToArray taggedTemplateLiteral toArray toConsumableArray '.split(' '))

I had this issue with one of our own modules earlier and ended up switching that module to use the react-native preset so that we don't have to maintain a fork of React Native.

The proper fix will be to add the ability to specify a babelHelpers file to react-native packager. PRs are welcome.

[byoigres]

Well, I ended using this solution and it works perfectly.

[satya164]

Awesome. I had actually used that solution in past, but it broke with RN upgrade.

[MoOx]

I got a similar error multiple times while I was starting with react-native on the last 2 days.

First I previously add a development section in my babel conf where es2015 where using, so boom. Took me a while to understand that, even with all those errors.

After that, (I now launch npm start with NODE_ENV=native to avoid babel using development section - which is the default behavior), I used react-router-native (which rely on react-router) which rely on babel-preset-stage-1.

Having this babelHelpers.typeof is not a function error is really not explicit.

I am still new with react-native, but I saw that some times, errors are caught and displayed with nice explanations (like when using react/react-dom - which is a good thing).

Don't you think this generic error could be caught and enhanced to prevent people wasting time on this, like I just did for a couple of hours?

[lacker]

@MoOx It seems like a good idea to add an extra warning when this happens. Interested in sending a pull request? ;-)

Otherwise, it seems like this is an issue with a known workaround, rather than an outstanding bug, so I am going to close this issue. I think the right fix is to stop transpiling npm modules but for now there are workarounds.