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

[7.0] Drop support for Node.js v0.10 and v0.12 (T7392) #4315

Closed
babel-bot opened this Issue May 29, 2016 · 16 comments

Comments

Projects
None yet
9 participants
@babel-bot
Collaborator

babel-bot commented May 29, 2016

Issue originally made by @mathiasbynens

Description

https://github.com/babel/babel/blob/master/doc/design/compiler-environment-support.md

Node.js v0.10 and v0.12 are both in maintenance mode as per https://github.com/nodejs/LTS#lts-schedule. IMHO it doesn’t make sense to continue to support them.

Supporting only Node.js v4+ would enable Babel and its dependencies (such as regexpu, the project I work on) to publish code that uses supported ES6 features without transpiling at prepublish.

Developers still using such old versions in their build environment can upgrade to a more recent Node.js version or use the last Babel version that supports their Node.js. (This is also how the jsdom project deals with old Node.js versions.) In other words, no one’s workflow would break because of this.

Similar discussion for the ESLint project: eslint/eslint#4483

@babel-bot

This comment has been minimized.

Show comment
Hide comment
@babel-bot

babel-bot May 29, 2016

Collaborator

Comment originally made by @loganfsmyth

I think the biggest question that needs to be answered for me to be happy with an change here is, how do we feel about users on non-Node platforms. We've never particularly clearly defined what platforms we 100% aim to support. We've mostly said no to older IE, but Babel up until now has functioned fine on browsers, and since it functions on ES5 platforms in general, it is used other places too. The maintainer of babel-standalone for instance, @daniel, maintains it for use in https://github.com/reactjs/React.NET so that people on non-Node platforms can make use of React. I've also had discussions on Slack and seen questions on SO from people using Babel via Nashorn.

I understand the desire to run native ES6, but beyond "native ES6 is cool", I have yet to see a sufficiently good argument for leaving ES5 behind.

Collaborator

babel-bot commented May 29, 2016

Comment originally made by @loganfsmyth

I think the biggest question that needs to be answered for me to be happy with an change here is, how do we feel about users on non-Node platforms. We've never particularly clearly defined what platforms we 100% aim to support. We've mostly said no to older IE, but Babel up until now has functioned fine on browsers, and since it functions on ES5 platforms in general, it is used other places too. The maintainer of babel-standalone for instance, @daniel, maintains it for use in https://github.com/reactjs/React.NET so that people on non-Node platforms can make use of React. I've also had discussions on Slack and seen questions on SO from people using Babel via Nashorn.

I understand the desire to run native ES6, but beyond "native ES6 is cool", I have yet to see a sufficiently good argument for leaving ES5 behind.

@babel-bot

This comment has been minimized.

Show comment
Hide comment
@babel-bot

babel-bot May 30, 2016

Collaborator

Comment originally made by @Daniel15

For babel-standalone I'm already using Webpack + Babel to compile Babel itself and I only publish the compiled version to npm and Bower, so it's probably not actually much of an issue in that case. I can just add extra build steps if needed. Pretty much everything that's using Babel outside of Node.js (such as ReactJS.NET, as well as people calling Babel directly via Ruby, Java, Python, whatever) are using babel-standalone now.

Collaborator

babel-bot commented May 30, 2016

Comment originally made by @Daniel15

For babel-standalone I'm already using Webpack + Babel to compile Babel itself and I only publish the compiled version to npm and Bower, so it's probably not actually much of an issue in that case. I can just add extra build steps if needed. Pretty much everything that's using Babel outside of Node.js (such as ReactJS.NET, as well as people calling Babel directly via Ruby, Java, Python, whatever) are using babel-standalone now.

@babel-bot

This comment has been minimized.

Show comment
Hide comment
@babel-bot

babel-bot May 30, 2016

Collaborator

Comment originally made by @mathiasbynens

I have yet to see a sufficiently good argument for leaving ES5 behind.

Is performance a sufficiently good argument? Native Map and Set performance beats transpiled code/polyfills. That is my specific use case, in fact — I’m working on an update to regexpu where some of its dependencies are already exporting Map objects and others are published as non-transpiled ES6 that only runs in Node.js v4+. I’d like to start using Map and Set in regexpu itself as well. It would really suck to have to patch/downgrade/transpile all those dependencies to Node.js v0.10/v0.12 support just because Babel continues to support such old Node.js versions.

Collaborator

babel-bot commented May 30, 2016

Comment originally made by @mathiasbynens

I have yet to see a sufficiently good argument for leaving ES5 behind.

Is performance a sufficiently good argument? Native Map and Set performance beats transpiled code/polyfills. That is my specific use case, in fact — I’m working on an update to regexpu where some of its dependencies are already exporting Map objects and others are published as non-transpiled ES6 that only runs in Node.js v4+. I’d like to start using Map and Set in regexpu itself as well. It would really suck to have to patch/downgrade/transpile all those dependencies to Node.js v0.10/v0.12 support just because Babel continues to support such old Node.js versions.

@babel-bot

This comment has been minimized.

Show comment
Hide comment
@babel-bot

babel-bot Jun 22, 2016

Collaborator

Comment originally made by @mathiasbynens

ESLint just did this: eslint/eslint@58542e4

Collaborator

babel-bot commented Jun 22, 2016

Comment originally made by @mathiasbynens

ESLint just did this: eslint/eslint@58542e4

@hzoo hzoo added the i: discussion label Sep 8, 2016

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Nov 2, 2016

Member

With the EOL of Node 0.10 it may be a good time to review things. I suspect the first step would be to simply drop testing in travis-ci for Node v5 and v0.10.46 in circle-ci. This may have to wait for a major version bump.

At the very least a roadmap and plan would be great. It's 0.10 now, but 0.12 by the end of Dec., then 4 in maintenance mode by Apr., and so on. The number of EOL'd will just keep stacking up and a plan to address this would rock.

Member

jdalton commented Nov 2, 2016

With the EOL of Node 0.10 it may be a good time to review things. I suspect the first step would be to simply drop testing in travis-ci for Node v5 and v0.10.46 in circle-ci. This may have to wait for a major version bump.

At the very least a roadmap and plan would be great. It's 0.10 now, but 0.12 by the end of Dec., then 4 in maintenance mode by Apr., and so on. The number of EOL'd will just keep stacking up and a plan to address this would rock.

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Nov 9, 2016

Contributor

npm just dropped support for Node.js 0.10 and Node.js 0.12: npm/npm@c82ecfd Why shouldn’t babel?

Contributor

mathiasbynens commented Nov 9, 2016

npm just dropped support for Node.js 0.10 and Node.js 0.12: npm/npm@c82ecfd Why shouldn’t babel?

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Dec 13, 2016

Contributor

What is blocking this?

Contributor

mathiasbynens commented Dec 13, 2016

What is blocking this?

@Kovensky

This comment has been minimized.

Show comment
Hide comment
@Kovensky

Kovensky Dec 13, 2016

Member

This is semver-major (i.e. we need babel 7)

Member

Kovensky commented Dec 13, 2016

This is semver-major (i.e. we need babel 7)

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Dec 13, 2016

Contributor

…and rightly so! I guess what I am asking is, what’s the big deal with cutting a Babel 7 release? Fear of large version numbers? :)

Contributor

mathiasbynens commented Dec 13, 2016

…and rightly so! I guess what I am asking is, what’s the big deal with cutting a Babel 7 release? Fear of large version numbers? :)

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Dec 13, 2016

Member

Large versions are fine, just wondering what we should put in Babel 7 and then the migration path depending on what goes in there. Just takes a while to upgrade for the ecosystem and it would be great to set up greenkeeper (or babel specific + codemods) for everyone

Member

hzoo commented Dec 13, 2016

Large versions are fine, just wondering what we should put in Babel 7 and then the migration path depending on what goes in there. Just takes a while to upgrade for the ecosystem and it would be great to set up greenkeeper (or babel specific + codemods) for everyone

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Dec 13, 2016

Member

But yeah because of that I would like to make the minimal amount of changes possibly for 7 so users don't have to do anything if they have already dropped node 4 themselves.

Member

hzoo commented Dec 13, 2016

But yeah because of that I would like to make the minimal amount of changes possibly for 7 so users don't have to do anything if they have already dropped node 4 themselves.

@siddharthkp

This comment has been minimized.

Show comment
Hide comment
@siddharthkp

siddharthkp Dec 28, 2016

Contributor

PR for dropping 0.12 and 0.10 💀

@xtuc cheers!

Contributor

siddharthkp commented Dec 28, 2016

PR for dropping 0.12 and 0.10 💀

@xtuc cheers!

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Jan 3, 2017

Member

👌 We can drop 🐢🚀 (in the next major release)

Member

xtuc commented Jan 3, 2017

👌 We can drop 🐢🚀 (in the next major release)

mathiasbynens added a commit to mathiasbynens/babylon that referenced this issue Jan 10, 2017

Remove `String.fromCodePoint` shim
This is not necessary anymore if we drop support for Node.js v0.10 and v0.12.

Ref. babel/babel#4315.

danez added a commit to babel/babylon that referenced this issue Jan 10, 2017

Remove `String.fromCodePoint` shim (#279)
This is not necessary anymore if we drop support for Node.js v0.10 and v0.12.

Ref. babel/babel#4315.
@balupton

This comment has been minimized.

Show comment
Hide comment
@balupton

balupton Jan 11, 2017

For those wanting to use babel in projects which travis builds still have to support node versions that are unsupported by babel, we have it so our .travis.yml file installs and runs babel only on LTS node versions, and if the current node version running on travis is not an LTS, then it will grab the LTS version to setup the project before running it on the intended node.js version:

https://github.com/bevry/base/blob/4d1f33ed699cef842c37bb8d277ca72e0d8e8418/.travis.yml#L25-L58

Posting this for reference for those in the future.

balupton commented Jan 11, 2017

For those wanting to use babel in projects which travis builds still have to support node versions that are unsupported by babel, we have it so our .travis.yml file installs and runs babel only on LTS node versions, and if the current node version running on travis is not an LTS, then it will grab the LTS version to setup the project before running it on the intended node.js version:

https://github.com/bevry/base/blob/4d1f33ed699cef842c37bb8d277ca72e0d8e8418/.travis.yml#L25-L58

Posting this for reference for those in the future.

@Daniel15

This comment has been minimized.

Show comment
Hide comment
@Daniel15

Daniel15 Jan 11, 2017

Member

node versions that are unsupported by babel

You can also use babel-standalone. It's built to use in non-Node.js environments (such as browsers) but will also work in older Node.js versions.

Member

Daniel15 commented Jan 11, 2017

node versions that are unsupported by babel

You can also use babel-standalone. It's built to use in non-Node.js environments (such as browsers) but will also work in older Node.js versions.

@hzoo hzoo added this to the Babel 7 milestone Jan 14, 2017

@hzoo hzoo added the Has PR label Jan 14, 2017

@hzoo hzoo changed the title from Drop support for Node.js v0.10 and v0.12 (T7392) to [7.0] Drop support for Node.js v0.10 and v0.12 (T7392) Jan 14, 2017

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jan 20, 2017

Member

Closed via #5025, #5041 on branch 7.0

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

Member

hzoo commented Jan 20, 2017

Closed via #5025, #5041 on branch 7.0

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

@lock lock bot added the outdated label May 5, 2018

@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.