Proposal for 3.0.0

[nzakas]

We have a few breaking changes that are getting backed up, and I think it would be nice to publish them and put out 3.0.0. We won't get much in the way of new functionality, but I think it will solve some problems for people. So, I'd like to propose the following for a 3.0.0 release in the next few weeks:

• Drop support for Node.js < 4 (LTS version) (Drop support for Node < 4 #4483)
• Update eslint:recommended (with whatever is appropriate) (Update eslint:recommended for 3.0.0 #6403)
• Set a default value for complexity (Default value for complexity (20) is not used when extending eslint:recommended #6021)
• Output error if no config file is found (Proposal: throw error if no config file is found #5987)
• Use XDG basedirs for personal config file (ESLint should respect XDG basedir spec when finding user-level .eslintrc #6008)
• Suppress ignored file warnings in executeOnText() (Option to suppress ignored file warnings #6302)
• Simplify eslint process exit code (Can we simplify our process.exit logic in bin/eslint.js? #6368)

A lot of these are fairly simple changes that could have positive impacts on end users, so maybe we can swarm and get these done?

Thoughts?

[alberto]

@nzakas #6008 isn't accepted

[nzakas]

@alberto I know, I'm proposing that we accept it.

[nzakas]

Oops, I thought it was closer than it is. Looks like there are still open questions on #6008, so removing from this proposal.

[nzakas]

@eslint/eslint-team please let me know what you think.

[ilyavolodin]

LGTM. It's a pretty small release, but I think that's fine. For dropping Node < 4, should we also convert the code to use some of the ES6 features at the same time, as well as modify our .eslintrc file for this repository? Or should we leave it as is and change it as we go?

[platinumazure]

My vote is change as we go, since those are chores that could be done anytime.

[vitorbal]

I also think change as we go is fine. Do we already know which es6 rules we
would like to turn on?
On Fri, Jun 10, 2016 at 10:04 PM Kevin Partington notifications@github.com
wrote:

My vote is change as we go, since those are chores that could be done
anytime.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6356 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAmNdkVdlr0Jwhuj43kyvKM4us2IBt1Pks5qKcNXgaJpZM4IyVY1
.

[alberto]

Added #6368 to the list.

[alberto]

LGTM.

Also 👍 to convert as we go

[mikesherov]

If we're going to start using es6, we should consider using https://github.com/mohebifar/lebab if we're going to upconvert.

Mike Sherov

On Jun 10, 2016, at 6:46 PM, alberto notifications@github.com wrote:

LGTM.

Also :+1 to convert as we go

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[mysticatea]

I also give 👍 to convert the code to use some of the ES6 features, and I'd like to use eslint-plugin-node 😇

• node/no-deprecated-api - Disallow deprecated API.
• node/no-missing-require - Disallow require()s for files that don't exist.
• node/no-unpublished-require - Disallow require()s for files that are not published.
• node/no-unsupported-features - Disallow unsupported ECMAScript features on the specified version.

Especially, node/no-unsupported-features would help us.

Also, I have some concerns about plugins loading.

• With 2.0.0-x Error: Cannot find module 'eslint-config-eslint'  #5160 (comment)
• Unmatched rule names of scoped plugins. #6362

If we solve those, it may be with some breaking changes.

[michaelficarra]

#6298 is a breaking change that hasn't reached consensus yet, but which I would like to be considered. The problem, though, is that it may take a decent amount of work, and may not be ready in the next few weeks.

[platinumazure]

@michaelficarra I greatly appreciate you offering my proposal, but I don't see it making 3.x and I'm okay with that. Also, I don't think it has to be a breaking change: rules which could use repository settings could continue to allow rule-level config as a backward compatibility layer. Thus I see no reason to add the proposal to 3.x.

[michaelficarra]

@platinumazure That's right, though I was hoping we could deprecate the old configuration in a major release.

[mysticatea]

If we deprecate old configurations, I hope to get glob-based configuration 😃

[ilyavolodin]

@michaelficarra If you support repository based configuration, could you post your thoughts on it in #6298 Right now, I'm not sure I understand what problem we are trying to solve with it.

[michaelficarra]

@ilyavolodin I will post there soon. I just haven't had the time to write up a convincing argument recently.

[nzakas]

Let's table the converting to ES6 discussion for now (if someone wants to open up a separate issue to discuss, please do, but that will come after 3.0.0 and so isn't relevant to planning).

And please, let's not add any more issues to my original description unless we all agree first. Otherwise, the reactions on that description and the comments are a bit misleading.

Part of the rationale for doing 3.0.0 in this lightweight way is to avoid the breaking feature explosion we've tended to have with previous major release (where everyone wants to get in "just one more" breaking change). That's also meant the nightmare of doing alpha and beta releases, which I definitely would like to avoid going forward.

I'd say at this point the only thing we should do is remove issues from the list and not add them. With what we have, I think we can shoot for 3.0.0 next Friday. Sound reasonable?

[alberto]

Sorry. I took the liberty to include that issue since it will become dead code as part of the node support update (you could consider it part of that), but I get your point. ❤️

[mysticatea]

I'm sorry. Sounds good to me.

[vitorbal]

I opened a separate issue to continue the converting to ES6 discussion: #6407

[nathanhammond]

@nzakas et al.: Ember and Ember CLI have committed to supporting the Node LTS lifetimes for the HEAD of our master branch(es). This means that we will will drop support for 0.10 on 2016-10-01 and 0.12 on 2016-12-31 per the Node.js Long-term Support Working Group's schedule.

We recognize that we don't have the privilege of setting that default for the entire Node ecosystem and have reserved the option to change that in the future if we find ourselves maintaining our own forks or legacy versions of the entire world.

This comment should be considered informational. 😄 The only consequence is that we won't move the Ember ecosystem to 3.X until January of next year.

/cc @stefanpenner @Turbo87 @rwjblue

[alberto]

Closing, since this is already done.

@nathanhammond you can use eslint@3 to lint your codebase using node>=4 even if you still support older node versions yourself.

[nathanhammond]

Hey @alberto, I appreciate the quick note.

There is a minor distinction that has to be made which makes all the difference: we're not aiming to lint our code (Ember CLI), we're aiming to lint the code of people who build applications using Ember CLI.

As we're delivering a bundled development tool we need to make sure that our upstreams (ESLint) support our target versions. Our support promise at current is such that you can build on top of our tooling and use any of the presently-supported versions of Node.

This means that we will continue to use ESLint@2 until the end of the year inside of the Ember community. This isn't a complaint, it should be considered informational (especially since the lag time here is limited), but do keep this in mind for when you elect to drop 4.X support at some point in the future.

/cc @ErisDS

[alberto]

Ah, gotcha. Thanks for your feedback, we'll take that into account.

[ErisDS]

Ghost has also committed to following the Node.js LTS roadmap. We have official support for LTS versions only, and drop support for old versions on the dates laid out in that plan.

We'd like to encourage as much of the Node.js ecosystem as possible to commit to following this plan, dropping support for older Node.js versions on the dates laid out. If we all drop support on the same day, this sends a clear message to the wider community that LTS means what it says 😉 . By validating & throwing weight behind Node.js LTS, we can help to position Node.js a reliable, dependable tool for SMBs & enterprise alike, and contribute to improving the reputation of the ecosystem.

This is just my 2c though 😁