It really sucks that there are so many JavaScript-knockoff languages and frameworks that don't maintain compatibility with JavaScript and expect you to break compatibility or add lots of boilerplate to get them to work with The Real McCoy.
I'm just seeing this now.
It looks like this breaks browser compatibility.
I think this should fix it, would you mind testing?
```js
-var _index = require('./index.js');
-
-
-
-var Unibabel = _interopRequireWildcard(_index).Unibabel;
-
-
-
-function _interopRequireWildcard(obj) {
-
- if (obj && obj.__esModule) {
-
- return obj;
-
- } else {
-
- var newObj = {};
-
- if (obj != null) {
-
- for (var key in obj) {
-
- if (Object.prototype.hasOwnProperty.call(obj, key)) newObj[key] = obj[key];
-
- }
-
- }
-
- newObj.default = obj;
-
- return newObj;
-
- }
-
-}
```
To:
```js
var Unibabel = exports.Unibabel || require('./index.js').Unibabel;
```
It really sucks that there are so many JavaScript-knockoff languages and frameworks that don't maintain compatibility with JavaScript and expect you to break compatibility or add lots of boilerplate to get them to work with The Real McCoy.
This pull request has changes conflicting with the target branch.
This PR makes unibabel.hex to be used as a module.
unibabel.hex can be used like:
import { Unibabel } from 'unibabel/unibabel.hex.js';Loo
I'm just seeing this now.
It looks like this breaks browser compatibility.
I think this should fix it, would you mind testing?
To:
It really sucks that there are so many JavaScript-knockoff languages and frameworks that don't maintain compatibility with JavaScript and expect you to break compatibility or add lots of boilerplate to get them to work with The Real McCoy.