Skip to content
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

Support separate requires in one-var #6175

Closed
andrewvaughan opened this issue May 14, 2016 · 22 comments · Fixed by #9441, mono-js/mono-notifications#5, mono-js/mono-push#5 or terrajs/lib-starter#5 · May be fixed by ali8889/emerald-wallet#4
Closed
Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules

Comments

@andrewvaughan
Copy link

andrewvaughan commented May 14, 2016

ESLint Version: 2.10.1

Problem:

A common request (e.g, #3091, #1232) is for the one-var rule to properly function in tandem with no-mixed-requires. I agree with this opinion, as the two methods are part of the core set of rules provided with ESLint and should properly support each other. I also believe there is a way to support this without introducing a dependency between the two rules.

Recommended Solution:

I believe this should not be a plugin, as both commands are part of the core library and cause conflict with each other. A better solution would be to add an optional parameter separate-requires to one-var that allows for require keywords to be separated into a single block, while assignments are in another block (similar to the intent of the two-var plugin).

For example:

"one-var": ["error", {
    "separate-requires": true,  // (New) Enforces requires to be separate from declarations
    "var": "never",
    "let": "never",
    "const": "never"
}]

This will allow ESLint to properly support it's built-in plugins without changing the default functionality of the one-var rule. With the above configuration:

This code would result in an error:

const gulp = require('gulp'),
      myModule = require('./some/module'),
      myVar1 = 1,
      myVar2 = 2;

This code would be valid:

const gulp = require('gulp'),
      myModule = require('./some/module');

const myVar = 1,
      myVar = 2;
@eslintbot eslintbot added the triage An ESLint team member will look at this issue soon label May 14, 2016
@alberto alberto added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion and removed triage An ESLint team member will look at this issue soon labels May 14, 2016
@nzakas
Copy link
Member

nzakas commented May 15, 2016

I'm not in favor of adding a CommonJS-specific option to a general rule, so I'm 👎 On this suggestion.

@nzakas
Copy link
Member

nzakas commented May 15, 2016

Looks like there's already a lengthy discussion of this here: #4680

So closing as a duplicate.

@mysticatea
Copy link
Member

I reopened this since this matter was separated from #4680.

@mysticatea mysticatea reopened this May 26, 2016
@nzakas
Copy link
Member

nzakas commented Aug 3, 2016

@mysticatea is this part of JSCS work?

@mysticatea
Copy link
Member

Yes, requireMultipleVarDecl seems to have an exception for require().

@kaicataldo
Copy link
Member

kaicataldo commented Nov 4, 2016

Having a little trouble tracing all the issues about this - where does this stand, @mysticatea? Is the original proposal still what we want to implement? If so, I'll champion this.

Edit: I think the option name should be camel case since it's an object key: separateRequires

@kaicataldo
Copy link
Member

@mysticatea Friendly ping

@mysticatea
Copy link
Member

I'm sorry for too late!

I think, yes.
JSCS has the option to ignore variable declarations which have require().

(Though, it seems ignoreRequires-like behavior rather than separate.)

@kaicataldo
Copy link
Member

kaicataldo commented Nov 29, 2016

(Though, it seems ignoreRequires-like behavior rather than separate.)

Right. Honestly, not sure how to proceed with this. I think your suggestion makes more sense, but it is different than what the JSCS option does. Seems like what seperateRequires enforces would be the common use case for it though.

@kaicataldo
Copy link
Member

@eslint/eslint-team Thoughts on this? Had a request for this in the Gitter chat today and would like to support this for those who are converting from JSCS.

The big remaining question is whether we track the JSCS ignore behavior or implement the separate require behavior proposed here. I personally like the latter, as I think it's more in line with the spirit of the rule and because it seems like that's the intended use case for the ignore option in JSCS.

@not-an-aardvark
Copy link
Member

I agree, having an option to separate require behavior sounds better than just having an option to ignore require.

@vitorbal
Copy link
Member

vitorbal commented Dec 8, 2016

👍 on this require behavior instead of just plain ignoring.

@nzakas
Copy link
Member

nzakas commented Dec 29, 2016

Can we get some JSCS folks input here?

@mikesherov
Copy link
Contributor

I'm for the JSCS behavior, considering it's more lenient, makes switching from JSCS easier, and we can always add the stricter version later.

That said, I'm fine either way.

@platinumazure platinumazure added the needs bikeshedding Minor details about this change need to be discussed label Jan 4, 2017
@kaicataldo
Copy link
Member

kaicataldo commented Jan 8, 2017

@eslint/eslint-team Sounds like we have 4 (including myself) in favor of the separate require option being proposed here and 1 to port over the JSCS behavior. Any other input? Would be nice to come to some consensus on this so we can get the ball rolling on actually implementing this.

@mikesherov
Copy link
Contributor

Don't let my opinion hold this back from moving forward.

@alberto alberto added accepted There is consensus among the team that this change meets the criteria for inclusion help wanted The team would welcome a contribution from the community for this issue and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion needs bikeshedding Minor details about this change need to be discussed labels Feb 17, 2017
@mikeletscher
Copy link

I will take a look into getting a PR up for this sometime this week/weekend.

@kaicataldo
Copy link
Member

@mikeletscher Fantastic! Please feel free to visit us in the ESLint Gitter if you get stuck or want to chat!

@onurtemizkan
Copy link
Contributor

@mikeletscher are you still working on this? I'm planning to make a PR this weekend if it's ok for you.

@mikeletscher
Copy link

@onurtemizkan Was like 2/3 of the way done, but don't let me stop you!

@onurtemizkan
Copy link
Contributor

onurtemizkan commented Jul 8, 2017

@mikeletscher No! Please go for it ☺️

@mikeletscher
Copy link

Hey guys, I dropped the ball on this--didn't end up having the time to finish it. @onurtemizkan I don't want to block you if you wanted to get this fixed, sorry for following up so late!

aladdin-add added a commit to aladdin-add/eslint that referenced this issue Oct 14, 2017
aladdin-add added a commit to aladdin-add/eslint that referenced this issue Oct 14, 2017
@alberto alberto removed the help wanted The team would welcome a contribution from the community for this issue label Nov 11, 2017
aladdin-add added a commit to aladdin-add/eslint that referenced this issue Nov 13, 2017
ilyavolodin pushed a commit that referenced this issue Dec 23, 2017
* Update: support separate requires in one-var. (fixes #6175)

* wip.

* fix edge case.

* Docs: add JSCS link
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Jun 22, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Jun 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.