New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split @babel/runtime into 2 modules via @babel/runtime-corejs2 #8266

Merged
merged 6 commits into from Aug 3, 2018

Conversation

@loganfsmyth
Member

loganfsmyth commented Jul 5, 2018

Q                       A
Fixed Issues? Fixes #8155
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass? Yes
Documentation PR EDIT by @hzoo: babel/website#1714
Any Dependency Changes?
License MIT

In Babel 6, we had @babel/runtime which always uses core-js in its helpers, meaning that anyone who wants to use our helpers in a centralized modular way had to also use core-js, which isn't always ideal.

Early in the Babel 7 alpha, we added a useBuiltins: true option that would use separate copies of the helpers that would skip loading core-js, but this still requires users to have an indirect npm dependency on core-js.

This PR splits our setup into two separate runtimes:

  • 'plugins': [
      ['transform-runtime'],
    ]
    
    with npm install --save @babel/runtime that just includes our helpers, and relies on users to globally polyfill any APIs they need.
  • 'plugins': [
      ['transform-runtime', { corejs: 2 }],
    ]
    
    with npm install --save @babel/runtime-corejs2 that includes everything @babel/runtime does, but also includes a passthrough API for corejs@2.x and rewrites all of the helper modules to reference core-js.
@babel-bot

This comment has been minimized.

Show comment
Hide comment
@babel-bot

babel-bot Jul 5, 2018

Collaborator

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/8756/

Collaborator

babel-bot commented Jul 5, 2018

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/8756/

@babel babel deleted a comment from babel-bot Jul 5, 2018

for (const dep of helpers.getDependencies(helperName)) {
const id = (dependencies[dep] = t.identifier(t.toIdentifier(dep)));
tree.body.push(template.statement.ast`
var ${id} = require("${`./${dep}`}");

This comment has been minimized.

@nicolo-ribaudo

nicolo-ribaudo Jul 5, 2018

Member

Some helpers redefine the exported function. Does this work in that case?

@nicolo-ribaudo

nicolo-ribaudo Jul 5, 2018

Member

Some helpers redefine the exported function. Does this work in that case?

This comment has been minimized.

@loganfsmyth

loganfsmyth Jul 5, 2018

Member

Yeah, it's a bug, but it's existing and tracked in #8087

@loganfsmyth

loganfsmyth Jul 5, 2018

Member

Yeah, it's a bug, but it's existing and tracked in #8087

This comment has been minimized.

@nicolo-ribaudo

nicolo-ribaudo Jul 5, 2018

Member

Oh ok, I didn't realize you just moved around this code

@nicolo-ribaudo

nicolo-ribaudo Jul 5, 2018

Member

Oh ok, I didn't realize you just moved around this code

Show outdated Hide outdated packages/babel-plugin-transform-runtime/src/index.js
@zloirock

This comment has been minimized.

Show comment
Hide comment
@zloirock

zloirock Jul 5, 2018

Member
  • Please, use kebab-case for core-js where it's possible for consistency with package / repo name and simplify of searching.
  • I haven't any plans about long time support of core-js@2 after core-js@3 release and creating runtime package for babel@7 which use core-js@2 could cause problems in the future.
Member

zloirock commented Jul 5, 2018

  • Please, use kebab-case for core-js where it's possible for consistency with package / repo name and simplify of searching.
  • I haven't any plans about long time support of core-js@2 after core-js@3 release and creating runtime package for babel@7 which use core-js@2 could cause problems in the future.
@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Jul 5, 2018

Member

@zloirock

use kebab-case for core-js where it's possible

Do you have strong feelings about specific cases in this PR? The primary issue is that I think the extra dash makes things harder in some cases here, like babel-runtime-core-js-2 is definitely harder to read than -corejs2. Same if we rename the corejsVersion option to corejs, using the dash would be frustrating since users would have to quote the option name.

I haven't any plans about long time support of core-js@2 after core-js@3 release

I think that's fine. I thought about making it just babel-runtime-corejs, but my concern was that people may want control over it because they may have other packages built with Babel 6's babel-runtime, and if we don't provide a runtime that uses core-js@2 then they'll be forced to use two parallel versions of core-js at the same time, which would increase their bundle sizes a lot. I'd still like to get core-js@3 landed and recommend it over the 2.x version.

Member

loganfsmyth commented Jul 5, 2018

@zloirock

use kebab-case for core-js where it's possible

Do you have strong feelings about specific cases in this PR? The primary issue is that I think the extra dash makes things harder in some cases here, like babel-runtime-core-js-2 is definitely harder to read than -corejs2. Same if we rename the corejsVersion option to corejs, using the dash would be frustrating since users would have to quote the option name.

I haven't any plans about long time support of core-js@2 after core-js@3 release

I think that's fine. I thought about making it just babel-runtime-corejs, but my concern was that people may want control over it because they may have other packages built with Babel 6's babel-runtime, and if we don't provide a runtime that uses core-js@2 then they'll be forced to use two parallel versions of core-js at the same time, which would increase their bundle sizes a lot. I'd still like to get core-js@3 landed and recommend it over the 2.x version.

Show outdated Hide outdated .gitignore
@hzoo

hzoo approved these changes Jul 5, 2018

looks good, just will want to document these changes on the website docs for all these packages, and then add to the migration guide which I can help with as well.

@@ -0,0 +1,14 @@
var _Map = require("@babel/runtime-corejs2/core-js/map");

This comment has been minimized.

@hzoo

hzoo Jul 5, 2018

Member

This is just a nit and maybe not worth looking into, but do we want to just make the path require("@babel/runtime-corejs2/map")?

@hzoo

hzoo Jul 5, 2018

Member

This is just a nit and maybe not worth looking into, but do we want to just make the path require("@babel/runtime-corejs2/map")?

This comment has been minimized.

@loganfsmyth

loganfsmyth Jul 7, 2018

Member

Hmm, I don't love having core-js repeated twice, but I do think having the core-js stuff grouped into a folder is nice. Do you just want to make it shorter, or is the repetition the part you want to avoid? Thoughts on other names?

@loganfsmyth

loganfsmyth Jul 7, 2018

Member

Hmm, I don't love having core-js repeated twice, but I do think having the core-js stuff grouped into a folder is nice. Do you just want to make it shorter, or is the repetition the part you want to avoid? Thoughts on other names?

@hzoo hzoo referenced this pull request Jul 5, 2018

Merged

runtime docs #1714

@@ -0,0 +1,158 @@
"use strict";

This comment has been minimized.

@Andarist

Andarist Jul 5, 2018

Member

imho it's really confusing that this build script is inside of babel-plugin-transform-runtime package

I understand that this script creates those files in more than 1 package, but as such I would see it being in a top-level scripts and not here

@Andarist

Andarist Jul 5, 2018

Member

imho it's really confusing that this build script is inside of babel-plugin-transform-runtime package

I understand that this script creates those files in more than 1 package, but as such I would see it being in a top-level scripts and not here

This comment has been minimized.

@loganfsmyth

loganfsmyth Jul 7, 2018

Member

The transform and the build script share the same source of data, which was my motivation. If we split it out, the build script will still have to reach into the transform to get that data, and doing that felt equally awkward.

@loganfsmyth

loganfsmyth Jul 7, 2018

Member

The transform and the build script share the same source of data, which was my motivation. If we split it out, the build script will still have to reach into the transform to get that data, and doing that felt equally awkward.

This comment has been minimized.

@Andarist

Andarist Jul 7, 2018

Member

In that case - feel free to go with whatever u prefer, I would still prefer to have this top-level, but I'm not super attached to it now (because of the reasons u gave)

@Andarist

Andarist Jul 7, 2018

Member

In that case - feel free to go with whatever u prefer, I would still prefer to have this top-level, but I'm not super attached to it now (because of the reasons u gave)

This comment has been minimized.

@hzoo

hzoo Jul 9, 2018

Member

I guess we should explain somewhere about running this

@hzoo

hzoo Jul 9, 2018

Member

I guess we should explain somewhere about running this

@Andarist

This comment has been minimized.

Show comment
Hide comment
@Andarist

Andarist Jul 5, 2018

Member

Could u explain how /es6/* helpers are supposed to be used in comparison to .mjs ones? I also can't see .mjs being created with the script in this PR - when they are created?

Member

Andarist commented Jul 5, 2018

Could u explain how /es6/* helpers are supposed to be used in comparison to .mjs ones? I also can't see .mjs being created with the script in this PR - when they are created?

@hzoo hzoo added the Priority: High label Jul 7, 2018

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Jul 7, 2018

Member

@Andarist This is just moving the existing logic. We don't currently offer .mjs helpers. I considered adding them, but was concerned about it potentially being more painful for users. It's also not too bad to add .mjs versions later, I think.

Member

loganfsmyth commented Jul 7, 2018

@Andarist This is just moving the existing logic. We don't currently offer .mjs helpers. I considered adding them, but was concerned about it potentially being more painful for users. It's also not too bad to add .mjs versions later, I think.

@Andarist

This comment has been minimized.

Show comment
Hide comment
@Andarist

Andarist Jul 7, 2018

Member

This gave me the conclusion that .mjs is somehow provided - I guess this is some kind of smoke test checked into the repo?

We don't currently offer .mjs helpers. I considered adding them, but was concerned about it potentially being more painful for users

Why?

It's also not too bad to add .mjs versions later, I think.

Agreed.

Member

Andarist commented Jul 7, 2018

This gave me the conclusion that .mjs is somehow provided - I guess this is some kind of smoke test checked into the repo?

We don't currently offer .mjs helpers. I considered adding them, but was concerned about it potentially being more painful for users

Why?

It's also not too bad to add .mjs versions later, I think.

Agreed.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Jul 7, 2018

Member

This gave me the conclusion

Oh shoot, that's left over from when I was experimenting with support for it. It shouldn't have been committed.

Why?

Mostly that the semantics of .mjs files still aren't official anywhere, especially around how they are loaded, and which one is loaded when, for instance if you don't provide a file extension.

Member

loganfsmyth commented Jul 7, 2018

This gave me the conclusion

Oh shoot, that's left over from when I was experimenting with support for it. It shouldn't have been committed.

Why?

Mostly that the semantics of .mjs files still aren't official anywhere, especially around how they are loaded, and which one is loaded when, for instance if you don't provide a file extension.

@xtuc

xtuc approved these changes Jul 9, 2018

looks good!

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Jul 15, 2018

Member

Alright I have:

  • Renamed the es6 folder to esm
  • Renamed the corejsVersion option to corejs
  • Removed accidentally-included .mjs files
  • Deleted babel-runtime/core-js.js file (and not moved it to babel-runtime-corejs2 since it isn't used as far as I can see.

@hzoo You had comments about the core-js/ folder making core-js be repeated twice, is that still a concern you have?

@zloirock Any thoughts on my responses to your thoughts above?

Member

loganfsmyth commented Jul 15, 2018

Alright I have:

  • Renamed the es6 folder to esm
  • Renamed the corejsVersion option to corejs
  • Removed accidentally-included .mjs files
  • Deleted babel-runtime/core-js.js file (and not moved it to babel-runtime-corejs2 since it isn't used as far as I can see.

@hzoo You had comments about the core-js/ folder making core-js be repeated twice, is that still a concern you have?

@zloirock Any thoughts on my responses to your thoughts above?

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 15, 2018

Member

LGTM

core-js/ folder making core-js be repeated twice, is that still a concern you have?

I'm ok if we don't change it, I understand it's nice to have it sorted by folder. Not sure I have a better suggestion

Member

hzoo commented Jul 15, 2018

LGTM

core-js/ folder making core-js be repeated twice, is that still a concern you have?

I'm ok if we don't change it, I understand it's nice to have it sorted by folder. Not sure I have a better suggestion

@zloirock

This comment has been minimized.

Show comment
Hide comment
@zloirock

zloirock Jul 15, 2018

Member

@loganfsmyth sorry for delayed reply. My opinion about kebab-case for core-js enough strong by the reason of searching. I don't think that it could make reading more difficult. I could change my opinion if a serious part of maintainers against kebab-case here.

Member

zloirock commented Jul 15, 2018

@loganfsmyth sorry for delayed reply. My opinion about kebab-case for core-js enough strong by the reason of searching. I don't think that it could make reading more difficult. I could change my opinion if a serious part of maintainers against kebab-case here.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Jul 15, 2018

Member

@zloirock Are there specific instances that you see in this PR that you disagree with? It would make discussions easier to have specific cases to discuss.

Member

loganfsmyth commented Jul 15, 2018

@zloirock Are there specific instances that you see in this PR that you disagree with? It would make discussions easier to have specific cases to discuss.

@zloirock

This comment has been minimized.

Show comment
Hide comment
@zloirock

zloirock Jul 17, 2018

Member

@loganfsmyth

  • @babel/runtime-corejs2 package name
  • corejs option of @babel/plugin-transform-runtime
Member

zloirock commented Jul 17, 2018

@loganfsmyth

  • @babel/runtime-corejs2 package name
  • corejs option of @babel/plugin-transform-runtime
@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Jul 17, 2018

Member

I'm neutral to the package name, but I strongly oppose to the core-js option name. Our options (and the majority of the options used by JS packages) are all CamelCase; also, it would force users to use quotes instead of babel.config.js.

Member

nicolo-ribaudo commented Jul 17, 2018

I'm neutral to the package name, but I strongly oppose to the core-js option name. Our options (and the majority of the options used by JS packages) are all CamelCase; also, it would force users to use quotes instead of babel.config.js.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Jul 17, 2018

Member

@zloirock Perfect, my thoughts are:

  • @babel/runtime-corejs2:

    If - is the goal, the alternatives I see are

    • @babel/runtime-core-js2
    • @babel/runtime-core-js-2

    and my primary concern is that, to me at least, these seem uglier and harder to type for users. The first case makes it seem like js2 is a standalone item, and the second is harder to type/remember due to the extra -s.

  • corejs option
    My concern there is that it would require users to do quotes, e.g.

    plugins: [
      ['@babel/transform-runtime', { 'core-js': 2 }]
    ]
    

    which isn't something we've done before in Babel's options. So far I don't think any of them require quoting. We could also consider coreJS: 2. That at least avoids the need for quotes, and we could always add validation to look for corejs and tell people they forgot to captitalize it. I still don't love it, but at least there's more flexibility there.

Member

loganfsmyth commented Jul 17, 2018

@zloirock Perfect, my thoughts are:

  • @babel/runtime-corejs2:

    If - is the goal, the alternatives I see are

    • @babel/runtime-core-js2
    • @babel/runtime-core-js-2

    and my primary concern is that, to me at least, these seem uglier and harder to type for users. The first case makes it seem like js2 is a standalone item, and the second is harder to type/remember due to the extra -s.

  • corejs option
    My concern there is that it would require users to do quotes, e.g.

    plugins: [
      ['@babel/transform-runtime', { 'core-js': 2 }]
    ]
    

    which isn't something we've done before in Babel's options. So far I don't think any of them require quoting. We could also consider coreJS: 2. That at least avoids the need for quotes, and we could always add validation to look for corejs and tell people they forgot to captitalize it. I still don't love it, but at least there's more flexibility there.

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Aug 6, 2018

Contributor

I fully support this change and I'm glad it happened, but folks seem to be having trouble because

  1. they're not using the latest version of @babel/plugin-transform-runtime but accidentally upgraded to @babel/runtime@7.0.0-beta.56, so the helpers/builtin directory no longer exists, or
  2. they've upgraded to the latest @babel/plugin-transform-runtime but haven't upgraded @babel/runtime yet, so modules in the helpers directory still import core-js polyfills, or
  3. they've upgraded @babel/plugin-transform-runtime but haven't yet installed @babel/runtime-corejs2, if that's necessary.

Some of this is just how it goes with breaking changes, but I have an idea that might help with case 1: what if the latest @babel/runtime package included a symlink from @babel/runtime/helpers/builtin to the parent directory, @babel/runtime/helpers, so that you could import built-in helpers from either directory? That makes sense because all the helpers are now built-in (in the sense that they do not import core-js polyfills), and because the previous contents of @babel/runtime/helpers/builtin were exactly the same as the list of modules in @babel/runtime/helpers.

If we did this, then @babel/runtime would continue to work both for code generated by the latest @babel/plugin-transform-runtime and for previously generated code, and we could remove the symlink in the future, once we're confident most folks have updated @babel/plugin-transform-runtime.

Thoughts?

Contributor

benjamn commented Aug 6, 2018

I fully support this change and I'm glad it happened, but folks seem to be having trouble because

  1. they're not using the latest version of @babel/plugin-transform-runtime but accidentally upgraded to @babel/runtime@7.0.0-beta.56, so the helpers/builtin directory no longer exists, or
  2. they've upgraded to the latest @babel/plugin-transform-runtime but haven't upgraded @babel/runtime yet, so modules in the helpers directory still import core-js polyfills, or
  3. they've upgraded @babel/plugin-transform-runtime but haven't yet installed @babel/runtime-corejs2, if that's necessary.

Some of this is just how it goes with breaking changes, but I have an idea that might help with case 1: what if the latest @babel/runtime package included a symlink from @babel/runtime/helpers/builtin to the parent directory, @babel/runtime/helpers, so that you could import built-in helpers from either directory? That makes sense because all the helpers are now built-in (in the sense that they do not import core-js polyfills), and because the previous contents of @babel/runtime/helpers/builtin were exactly the same as the list of modules in @babel/runtime/helpers.

If we did this, then @babel/runtime would continue to work both for code generated by the latest @babel/plugin-transform-runtime and for previously generated code, and we could remove the symlink in the future, once we're confident most folks have updated @babel/plugin-transform-runtime.

Thoughts?

@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Aug 6, 2018

Member

We have been asking users not to use ^ in their @babel/* dependencies for ages, specifically to avoid problems like the one you are mentioning. I think that we can keep asking users to check the version of the installed packages, especially because we are close to the first rc so we are trying to avoid introducing things that will soon lead to breaking changes (e.g. removing the symlink).

Member

nicolo-ribaudo commented Aug 6, 2018

We have been asking users not to use ^ in their @babel/* dependencies for ages, specifically to avoid problems like the one you are mentioning. I think that we can keep asking users to check the version of the installed packages, especially because we are close to the first rc so we are trying to avoid introducing things that will soon lead to breaking changes (e.g. removing the symlink).

benjamn added a commit to meteor/meteor that referenced this pull request Aug 6, 2018

Symlink from @babel/runtime/helpers/builtin to @babel/runtime/helpers.
babel/babel#8266 (comment)

Should fix #10129, since the vue-component build plugin registered by
akryum:vue-component depends on the @babel/runtime package installed in
dev_bundle/lib/node_modules.
@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Aug 6, 2018

Contributor

Excited for the RC and the final release! These versioning puzzles will be much easier to manage once Babel 7 is officially released, so we can go back to using semantic versioning to flag breaking changes like the removal of the helpers/builtin directory. It's just hard to know right now how significant each increment of -beta.n number is.

That said, if you've been asking people to do something for a long time and they still haven't done it, perhaps it's time to consider other ways of helping them fall into the Pit of Success™?

Contributor

benjamn commented Aug 6, 2018

Excited for the RC and the final release! These versioning puzzles will be much easier to manage once Babel 7 is officially released, so we can go back to using semantic versioning to flag breaking changes like the removal of the helpers/builtin directory. It's just hard to know right now how significant each increment of -beta.n number is.

That said, if you've been asking people to do something for a long time and they still haven't done it, perhaps it's time to consider other ways of helping them fall into the Pit of Success™?

benjamn added a commit to meteor/meteor that referenced this pull request Aug 6, 2018

Symlink from @babel/runtime/helpers/builtin to @babel/runtime/helpers.
babel/babel#8266 (comment)

Should fix #10129, since the vue-component build plugin registered by
akryum:vue-component depends on the @babel/runtime package installed in
dev_bundle/lib/node_modules.

benjamn added a commit to meteor/meteor that referenced this pull request Aug 6, 2018

Symlink from @babel/runtime/helpers/builtin to @babel/runtime/helpers.
babel/babel#8266 (comment)

Should fix #10129, since the vue-component build plugin registered by
akryum:vue-component depends on the @babel/runtime package installed in
dev_bundle/lib/node_modules.
@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Aug 6, 2018

Member

That said, if you've been asking people to do something for a long time and they still haven't done it, perhaps it's time to consider other ways of helping them fall into the Pit of Success™?

Wanted to do this since the beginning but didn't know how and believe everyone else was ok with just telling people. Do know a good way of preventing it because other projects/people are going to whatever and it's hard to figure out how to know how to do in that case other than not releasing until the end. And even versioning it differently like beta.n to c.n doesn't fix the ^ issue. This is why I spent some time to submit npm/rfcs#14 as well. In the end it's our fault, but it's also still beta and that comes with using beta which we have said there are intentional breaking changes. Believe me, I can't wait to finally release it either (still get people everyday asking me to release/when and to be honest it's not helping me mentally)

I think we don't have anything left so this shouldn't be more of an issue at least for this release moving forward..

Member

hzoo commented Aug 6, 2018

That said, if you've been asking people to do something for a long time and they still haven't done it, perhaps it's time to consider other ways of helping them fall into the Pit of Success™?

Wanted to do this since the beginning but didn't know how and believe everyone else was ok with just telling people. Do know a good way of preventing it because other projects/people are going to whatever and it's hard to figure out how to know how to do in that case other than not releasing until the end. And even versioning it differently like beta.n to c.n doesn't fix the ^ issue. This is why I spent some time to submit npm/rfcs#14 as well. In the end it's our fault, but it's also still beta and that comes with using beta which we have said there are intentional breaking changes. Believe me, I can't wait to finally release it either (still get people everyday asking me to release/when and to be honest it's not helping me mentally)

I think we don't have anything left so this shouldn't be more of an issue at least for this release moving forward..

@benjamn benjamn referenced this pull request Aug 6, 2018

Merged

Release 1.7.0.4 #10134

4 of 4 tasks complete

@insin insin referenced this pull request Aug 7, 2018

Open

Babel 7 #403

7 of 8 tasks complete
@insin

This comment has been minimized.

Show comment
Hide comment
@insin

insin Aug 7, 2018

I don't think anybody really uses the current moduleName option now

nwb depended on this to have the transform-runtime plugin generate imports which pointed to the absolute path to babel-runtime in nwb's own dependencies, allowing it to serve and build stuff with all devDependencies managed in a global install - is there an alternative way to get Babel to resolve the runtime module when it's not going to be available in require() scope?

insin commented Aug 7, 2018

I don't think anybody really uses the current moduleName option now

nwb depended on this to have the transform-runtime plugin generate imports which pointed to the absolute path to babel-runtime in nwb's own dependencies, allowing it to serve and build stuff with all devDependencies managed in a global install - is there an alternative way to get Babel to resolve the runtime module when it's not going to be available in require() scope?

@loganfsmyth loganfsmyth deleted the loganfsmyth:runtime-refactor branch Aug 7, 2018

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Aug 7, 2018

Member

@insin The original intention of moduleName was to allow custom runtimes, which isn't something we're looking to support in 7.x, but the usecase of passing an absolute path for the runtime itself seems entirely reasonable.

I'd be happy to have an option of some kind (for transform-runtime) to have Babel inject absolute paths. How would you feel about a useAbsoluteRuntime option? My preference would probably be to allow both:

  • useAbsoluteRuntime: true
    • If the plugin is passed in the programmatic args, it resolves relative to Babel's cwd
    • If the plugin is passed via a config file, it resolve relative to that file
  • useAbsoluteRuntime: "/some/abs/dir"
    • Resolve the runtime relative to some specific directory, which for nwb could just be __dirname

Thoughts?

Member

loganfsmyth commented Aug 7, 2018

@insin The original intention of moduleName was to allow custom runtimes, which isn't something we're looking to support in 7.x, but the usecase of passing an absolute path for the runtime itself seems entirely reasonable.

I'd be happy to have an option of some kind (for transform-runtime) to have Babel inject absolute paths. How would you feel about a useAbsoluteRuntime option? My preference would probably be to allow both:

  • useAbsoluteRuntime: true
    • If the plugin is passed in the programmatic args, it resolves relative to Babel's cwd
    • If the plugin is passed via a config file, it resolve relative to that file
  • useAbsoluteRuntime: "/some/abs/dir"
    • Resolve the runtime relative to some specific directory, which for nwb could just be __dirname

Thoughts?

@insin

This comment has been minimized.

Show comment
Hide comment
@insin

insin Aug 7, 2018

@loganfsmyth Those both look good to me 👍

Would that also support passing the absolute path, as in path.dirname(require.resolve('@babel/runtime/package'))?

insin commented Aug 7, 2018

@loganfsmyth Those both look good to me 👍

Would that also support passing the absolute path, as in path.dirname(require.resolve('@babel/runtime/package'))?

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Aug 7, 2018

Hello awesome Babel devs, it'd be awesome to avoid in-range breaking changes, and it would be highly valued and appreciated (so it doesn't break all the stuffs and the things)!

Luckily, I share a single build config with my projects, so fixing them was easy. 😃

Is there a way that during an npm install we can get a very noticeable and outstanding message about the breaking change? Perhaps an install hook can detect the version from package.json, and putput the message if the in-range version is lower than the one that introduces the change.

That would be very useful. If that is already the case, then I missed it and it wasn't noticeable enough.

trusktr commented Aug 7, 2018

Hello awesome Babel devs, it'd be awesome to avoid in-range breaking changes, and it would be highly valued and appreciated (so it doesn't break all the stuffs and the things)!

Luckily, I share a single build config with my projects, so fixing them was easy. 😃

Is there a way that during an npm install we can get a very noticeable and outstanding message about the breaking change? Perhaps an install hook can detect the version from package.json, and putput the message if the in-range version is lower than the one that introduces the change.

That would be very useful. If that is already the case, then I missed it and it wasn't noticeable enough.

trusktr added a commit to trusktr/lowclass that referenced this pull request Aug 7, 2018

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Aug 8, 2018

Contributor

As disruptive as these changes might be, I think they're totally fair game for a beta release. Being more careful about breaking changes during beta just means it takes longer for Babel 7 to be officially released, which is the goal we're all aiming for. Once we drop the -beta.n suffix, we can go back to normal semantic versioning, which probably would have saved you from this particular pain.

Contributor

benjamn commented Aug 8, 2018

As disruptive as these changes might be, I think they're totally fair game for a beta release. Being more careful about breaking changes during beta just means it takes longer for Babel 7 to be officially released, which is the goal we're all aiming for. Once we drop the -beta.n suffix, we can go back to normal semantic versioning, which probably would have saved you from this particular pain.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Aug 8, 2018

Member

@trusktr

it'd be awesome to avoid in-range breaking changes

While I totally understand that it's frustrating, the entire reason for being in -beta is because that specifically exists to signal that something may have breaking changes.

For instance https://semver.org/ calls out

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

If it were only ever possible to make breaking changes in exact major version bumps, prerelease versions wouldn't exist in the first place.

Similarly, https://www.npmjs.com/package/semver#prerelease-tags

The purpose for this behavior is twofold. First, prerelease versions frequently are updated very quickly, and contain many breaking changes that are (by the author's design) not yet fit for public consumption. Therefore, by default, they are excluded from range matching semantics.

Second, a user who has opted into using a prerelease version has clearly indicated the intent to use that specific set of alpha/beta/rc versions. By including a prerelease tag in the range, the user is indicating that they are aware of the risk.

As @hzoo mentioned above, npm's behavior around prereleases isn't quite ideal right now, and we've filed npm/rfcs#14 to try to have that addressed in future versions.

Once we drop the -beta and release a proper 7.0.0 we'll absolutely be avoiding any known regressions in behavior.

Member

loganfsmyth commented Aug 8, 2018

@trusktr

it'd be awesome to avoid in-range breaking changes

While I totally understand that it's frustrating, the entire reason for being in -beta is because that specifically exists to signal that something may have breaking changes.

For instance https://semver.org/ calls out

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

If it were only ever possible to make breaking changes in exact major version bumps, prerelease versions wouldn't exist in the first place.

Similarly, https://www.npmjs.com/package/semver#prerelease-tags

The purpose for this behavior is twofold. First, prerelease versions frequently are updated very quickly, and contain many breaking changes that are (by the author's design) not yet fit for public consumption. Therefore, by default, they are excluded from range matching semantics.

Second, a user who has opted into using a prerelease version has clearly indicated the intent to use that specific set of alpha/beta/rc versions. By including a prerelease tag in the range, the user is indicating that they are aware of the risk.

As @hzoo mentioned above, npm's behavior around prereleases isn't quite ideal right now, and we've filed npm/rfcs#14 to try to have that addressed in future versions.

Once we drop the -beta and release a proper 7.0.0 we'll absolutely be avoiding any known regressions in behavior.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Aug 8, 2018

Member

@insin

Would that also support passing the absolute path, as in path.dirname(require.resolve('@babel/runtime/package'))?

It would not, and I don't know that it's something I'd want to allow, because it should be the runtime transform itself deciding the actual name of the runtime, at least in my opinion. In the context of nwb though, since require.resolve resolves a package relative to __dirname, you'd get exactly the behavior of your current implementation by doing

plugins: [
  ['@babel/plugin-transform-runtime', { absoluteRuntime: __dirname }],
]

to resolve the runtime relative to __dirname.

Member

loganfsmyth commented Aug 8, 2018

@insin

Would that also support passing the absolute path, as in path.dirname(require.resolve('@babel/runtime/package'))?

It would not, and I don't know that it's something I'd want to allow, because it should be the runtime transform itself deciding the actual name of the runtime, at least in my opinion. In the context of nwb though, since require.resolve resolves a package relative to __dirname, you'd get exactly the behavior of your current implementation by doing

plugins: [
  ['@babel/plugin-transform-runtime', { absoluteRuntime: __dirname }],
]

to resolve the runtime relative to __dirname.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Aug 8, 2018

Member

For the absolute-path discussion, I created #8435, so let's continue that over there.

Member

loganfsmyth commented Aug 8, 2018

For the absolute-path discussion, I created #8435, so let's continue that over there.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Aug 8, 2018

-beta is because that specifically exists to signal that something may have breaking changes.

You're right. This is an interesting case: v7 has been in Beta so long that people are using it like it's not Beta.

trusktr commented Aug 8, 2018

-beta is because that specifically exists to signal that something may have breaking changes.

You're right. This is an interesting case: v7 has been in Beta so long that people are using it like it's not Beta.

nicolo-ribaudo added a commit to nicolo-ribaudo/babel-upgrade that referenced this pull request Aug 10, 2018

nicolo-ribaudo added a commit to nicolo-ribaudo/babel-upgrade that referenced this pull request Aug 28, 2018

nicolo-ribaudo added a commit to nicolo-ribaudo/babel-upgrade that referenced this pull request Aug 28, 2018

@ecris87 ecris87 referenced this pull request Sep 11, 2018

Merged

[RFC] #199 Upgrade to babel v7 #200

3 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment