babel-runtime needs to update to regenerator 0.8.28

[mrm007]

regenerator 0.8.28 breaks compatibility with babel because it's added a new method runtime.awrap which is not present in babel-runtime. A new version of babel-runtime needs to be published or update the dependency in babel-core to regenerator <0.8.28.

[sebmck]

A breaking version of regenerator should not have been released in the same minor version. cc @benjamn

[fkling]

To be fair, adding a new method is hardly a breaking change though. It rather looks like babel should always depend on a fixed version of regenerator, so that you have more control over the update process (although, that's not ideal either... dunno, maybe babel is just in an unfortunate position because of its structure).

[UltCombo]

My build is failing with TypeError: _regeneratorRuntime.awrap is not a function.
I assume this issue is the source of the problem?

[mrm007]

@UltCombo yes, that is the effect.

[benjamn]

@fkling is right. This is not a breaking change from Regenerator's perspective, only from the perspective of a consumer using an out of date version of the runtime.

What can we do to make sure the runtime and the compiler stay on the same version in Babel?

[benjamn]

Depending on a fixed version of Regenerator seems like a reasonable strategy if you can't guarantee that the parts of it you're using independently remain consistent with each other.

[UltCombo]

Depending on a fixed version of Regenerator seems like a reasonable strategy if you can't guarantee that the parts of it you're using independently remain consistent with each other.

Yes, I believe it would fix the issue if Babel pins down the Regenerator version and consumers pin down their babel-runtime dependency version.

[sebv]

If one of the babel guy run make publish-runtime that should fix it. Might also consider babel-runtime having npm dependencies, not sure what was the logic with the current setup.

[sebmck]

@sebv The regenerator runtime has to be processed with the runtime transformer to ensure that Promise and Symbol are correctly aliased to core-js, that's why it's embedded.

[sebv]

@sebmck are you publishing new packages?

[sebmck]

@sebv Yes. I haven't published a new version in over 2 weeks and need to verify that none of the changes made in the interim don't break everything. Give me time.

[sebv]

Ok cool thx!
Just generated a new babel-runtime and hard-copied it into my node_modules, that will definitely fix it. (For some reasons babel-runtime breaks npm link, but it's another issue)

[sebmck]

Just published 5.5.0, hopefully it doesn't break the world.

[sebv]

Seem to fixed it, might be a small regression, getting this:

SyntaxError: /Users/baba/Work/appium-base-driver/node_modules/appium-gulp-plugins/node_modules/mocha/bin/_mocha: 'return' outside of function (392:2)

[sebmck]

How are you running mocha?

[sebv]

using isparta: https://github.com/douglasduteil/isparta
babel-node node_modules/.bin/isparta cover --report text --report html node_modules/.bin/_mocha -- --reporter dot

[sebmck]

That's due to changing behaviour in 5.0.0 that will compile files in node_modules provided that it's directly relative to the entry file. Isparta should not be recommending that behaviour as it's extremely hacky.

[mrm007]

@sebmck Thank you, that was quick!

[UltCombo]

@sebmck wouldn't it be better to depend on an exact version of Regenerator?

Right now, babel-core allows seamlessly upgrading regenerator when a new patch/minor version is published, but babel-runtime will not update automatically. If this isn't changed, this issue is fated to repeat itself.

[sebmck]

@UltCombo Not possible and defeats the purpose of the runtime:

The regenerator runtime has to be processed with the runtime transformer to ensure that Promise and Symbol are correctly aliased to core-js,

[UltCombo]

@sebmck I meant to remove the semver range from this line and use an exact version, e.g. "regenerator": "0.8.28". This would ensure that the compiler and runtime stay with the same regenerator version, and still allow it to be processed processed with the runtime transformer, right?

[sebmck]

I guess, it's just extremely annoying to have to manually bump the version whenever there's an update.

[UltCombo]

Part of my build process is updating all dependencies, the same dependencies which a consumer would install with a clean npm install. It is rather annoying when the build and npm installs of my packages break due to conflicting regenerator versions in the compiled code vs runtime.

[UltCombo]

If you'd really like to avoid using an exact version, it would perhaps be possible to set up a bot to watch the npm registry and build and publish the babel-runtime when a new regenerator version is published. The problem is that the babel-runtime version would no longer match babel-core's, and this doesn't warrant 100% uptime either.

[mrm007]

How about declaring regenerator as dependency in babel-runtime and running the transformer on postinstall?

[sebmck]

That would require an entire install of babel-core which would be crazy since the babel-runtime is supposed to be very small to install (it only relies on core-js which has 0 dependencies).

[benjamn]

I could split the Regenerator runtime out into its own NPM package if that
would help.
On Fri, Jun 5, 2015 at 9:40 PM Sebastian McKenzie notifications@github.com
wrote:

That would require an entire install of babel-core which would be crazy
since the babel-runtime is supposed to be very small to install (it only
relies on core-js which has 0 dependencies).

—
Reply to this email directly or view it on GitHub
#1685 (comment).

[UltCombo]

I guess I've been thinking about this more than I should, anyway, I've opened #1701 to sum up my thoughts. Can we relocate this discussion to there?