Upgrade to babel@7 #218
Comments
|
I agree on this but I wonder about backward compatibility. If an app still uses babel 6 and we migrate to babel 7, would it be a problem too? |
|
Well, they can keep using an older version until they upgrade to a newer babel version. The thing is that starting a new project and having to use older tooling is far from ideal (I wish I could use Ledger in a app I’m creating right now but can’t). An alternative would be running parallel configs that spits out code compatible with both versions. |
|
I would recommend to fork the lib on your side of you need it , we'll be careful on migrating to this. I've discussed with parceljs author recently and he suggested there could be a way to transpile code from Babel 7 back to babel 6 and apparently they used that. Worth taking a look 🧐 |
|
I tried making it work with Babel 7, but I couldn't really grasp how lerna works. I'll take another look. |
|
Actually it would be interesting to have the option to transpile the code using our own configuration. Not sure how this could be done, though. Edit: I'm saying this cause now my bundles have duplicate regenerators runtime and promise polyfill and a few others; I'd be happy to cut some of the bloat for my webapps. |
|
I am having the same issue. But the log message above is most likely because the dependency "babel-runtime" is not a runtime dependency of each package. But "use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
var _getIterator2 = require("babel-runtime/core-js/get-iterator");
var _getIterator3 = _interopRequireDefault(_getIterator2);
var _regenerator = require("babel-runtime/regenerator");
var _regenerator2 = _interopRequireDefault(_regenerator);
var _asyncToGenerator2 = require("babel-runtime/helpers/asyncToGenerator");
var _asyncToGenerator3 = _interopRequireDefault(_asyncToGenerator2);
var _getPrototypeOf = require("babel-runtime/core-js/object/get-prototype-of");
var _getPrototypeOf2 = _interopRequireDefault(_getPrototypeOf);
var _classCallCheck2 = require("babel-runtime/helpers/classCallCheck");
var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);
var _createClass2 = require("babel-runtime/helpers/createClass");
[...]I think this must go into each package. |
|
@webmaster128 Yes this is another issue |
|
I have the same problem in my next.js app. |
|
I've pushed a PR #241 to fix this. I've also pushed built packages to https://www.npmjs.com/org/liquality. Feel free to use them while PR gets merged. |
|
Fixed since v5.0.0 |
As of right now, ledgerjs libs don't work with latest babel (v7). I think the project should be upgraded to the latest version, bumping the major version. Here's the error I'm currently having when trying to use exported files:
That's because babel packages now use the
@babelscope (e.g.@babel/runtime).The text was updated successfully, but these errors were encountered: