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

pass config with flag/args #692

Closed
tj opened this Issue Mar 20, 2014 · 20 comments

Comments

Projects
None yet
5 participants
@tj
Copy link

tj commented Mar 20, 2014

personally I don't want to put comments in a file, or have a global config, Ideally we would just be able to do:

test: lint

lint:
  eslint *.js

.PHONY: test

and specify --node or whatever directly with the executable. Looks like a bunch of non-error defaults are enabled as well :s those should definitely be removed IMO

@nzakas nzakas added the enhancement label Mar 20, 2014

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Mar 20, 2014

Just to clarify: you're asking to be able to configure rules and environments by passing flags on the command line, correct?

If so, do you have a format in mind? We currently have 110 rules, so we probably don't want to create an individual flag for every rule.

Regarding defaults: I don't see removing those. We've tried to keep them to things that are either most problematic or most common, because there are far too many rules to force every developer to go through and manually specify everything up front. I wouldn't be opposed to having a flag that resets everything to being off, though, for those who want it.

@tj

This comment has been minimized.

Copy link
Author

tj commented Mar 20, 2014

Yup, even if it was still json that would be ok with me, but some sugar like --env node --env browser --globals foo,bar,baz --rule quotes "[2, 'double']" would be nice.

Things like curlies / quotes really don't make good defaults, they're not errors, but a reset would instantly make it better than the other tools

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Mar 20, 2014

Cool, I think the task list for this is (in increasing order of complexity):

  • Create a flag that resets every rule to be off
  • Create a flag that enables environments
  • Create a flag that specifies globals
  • Create a flag that specifies rule configuration
@tj

This comment has been minimized.

Copy link
Author

tj commented Mar 20, 2014

Sweet thanks for considering the changes, I'll try and help today if I get some time

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Mar 20, 2014

FWIW, I think the flag for wiping the slate clean can just avoid loading conf/eslint.json.

@tj

This comment has been minimized.

Copy link
Author

tj commented Mar 20, 2014

It would be nice to still enable some, just errors though, maybe eslint core can provide a few boilerplate configurations?

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Mar 20, 2014

Oh yeah, what I mean is that we load conf/eslint.json first and then
merge any changes into that. If just don't load that file, and instead
merge into an empty config, you essentially get to start from scratch and
just add what you want.

Also, you've said "errors" a couple times, but I'm not clear on what those
are. Are you talking syntax errors only?

@tj

This comment has been minimized.

Copy link
Author

tj commented Mar 21, 2014

Yeah pretty much just syntax errors and dead code, most of the "Possible Error" rules are reasonable as defaults, the rest definitely not

@jonathanKingston

This comment has been minimized.

Copy link
Contributor

jonathanKingston commented Mar 21, 2014

Is it worth having a command line flag/s to turn sections of the rules off to simplify specification?

So the sections would be those set out in the rules page

eslint --node --possible-errors --stylistic-errors off

@tj

This comment has been minimized.

Copy link
Author

tj commented Mar 21, 2014

that would be cool too, but the granularity we were talking about earlier would definitely be helpful as well

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Mar 21, 2014

The categorization is for documentation purposes only right now, there was very little though put into them and they're still changing as rules get added, changed, and removed. I wouldn't want to formalize the grouping into code at this point.

@jonathanKingston

This comment has been minimized.

Copy link
Contributor

jonathanKingston commented Mar 21, 2014

@nzakas I was feeling you were going to say that, was worth the suggestion anyway.

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Mar 21, 2014

Totally, never hold back with suggestions. :)

btmills added a commit to btmills/eslint that referenced this issue Mar 26, 2014

Add reset cli flag (refs eslint#692)
Adds a --reset (-r) flag to the cli options that resets all
default rules to be off.

btmills added a commit to btmills/eslint that referenced this issue Mar 26, 2014

Add reset cli flag (refs eslint#692)
Adds a --reset (-r) flag to the cli options that resets all
default rules to be off.

btmills added a commit to btmills/eslint that referenced this issue Mar 26, 2014

Add reset cli flag (refs eslint#692)
Adds a --reset flag to the cli options that resets all
default rules to be off.

btmills added a commit to btmills/eslint that referenced this issue Mar 31, 2014

btmills added a commit to btmills/eslint that referenced this issue Mar 31, 2014

nzakas added a commit that referenced this issue Mar 31, 2014

Merge pull request #745 from btmills/env-flag
Add --env cli flag (ref #692)

btmills added a commit to btmills/eslint that referenced this issue Apr 3, 2014

Add globals cli flag (ref eslint#692)
Adds a --globals cli flag to define global variables. Takes a comma-
separated list of variable names to define. By default, all varibles
are read-only, but appending `:true` to the name will mark it as
writable.

Example:

    eslint --globals require,exports:true file.js

btmills added a commit to btmills/eslint that referenced this issue Apr 3, 2014

Add globals cli flag (ref eslint#692)
Adds a --globals cli flag to define global variables. Takes a comma-
separated list of variable names to define. By default, all variables
are read-only, but appending `:true` to the name will mark it as
writable.

Example:

    eslint --globals require,exports:true file.js

btmills added a commit to btmills/eslint that referenced this issue Apr 8, 2014

Add global cli flag (ref eslint#692)
Adds a --global cli flag to define global variables. To define
multiple variables, either separate them using commas, or use the
flag multiple times. By default, all variables are read-only, but
appending `:true` to the name will mark it as writable.

Example:

    eslint --global require,exports:true file.js
    eslint --global require --global exports:true file.js

btmills added a commit to btmills/eslint that referenced this issue Apr 8, 2014

Add global cli flag (ref eslint#692)
Adds a --global cli flag to define global variables. To define
multiple variables, either separate them using commas, or use the
flag multiple times. By default, all variables are read-only, but
appending `:true` to the name will mark it as writable.

Example:

    eslint --global require,exports:true file.js
    eslint --global require --global exports:true file.js

btmills added a commit to btmills/eslint that referenced this issue Apr 8, 2014

Add globals cli flag (ref eslint#692)
Adds a --globals cli flag to define global variables. To define
multiple variables, either separate them using commas, or use the
flag multiple times. By default, all variables are read-only, but
appending `:true` to the name will mark it as writable.

Example:

    eslint --globals require,exports:true file.js
    eslint --globals require --globals exports:true file.js

btmills added a commit to btmills/eslint that referenced this issue Apr 8, 2014

Add globals cli flag (ref eslint#692)
Adds a --globals cli flag to define global variables. To define
multiple variables, either separate them using commas, or use the
flag multiple times. By default, all variables are read-only, but
appending `:true` to the name will mark it as writable.

Example:

    eslint --globals require,exports:true file.js
    eslint --globals require --globals exports:true file.js

nzakas added a commit that referenced this issue Apr 9, 2014

Merge pull request #751 from btmills/globals-flag
Add global cli flag (ref #692)
@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Apr 9, 2014

3/4 of the way there thanks to @btmills and @gkz

@gkz

This comment has been minimized.

Copy link
Contributor

gkz commented Apr 11, 2014

With Optionator, it is possible to add a flag called rules with the type Object, then:

--rules 'brace-style: [2, 1tbs], radix: 2'

results in:

{
  rules: {
    'brace-style': [ 2, '1tbs' ],
    radix: 2
  }
}

pretty easy!

@btmills

This comment has been minimized.

Copy link
Member

btmills commented Apr 11, 2014

Sweet! By extension, will [Object] work with a singular --rule flag to match --env and --global?

@gkz

This comment has been minimized.

Copy link
Contributor

gkz commented Apr 11, 2014

Actually I was just thinking about that.
The option that I added merges arrays, but what is required here is to merge objects ([Object] means an array of Objects). You don't want an array of objects specifying rules, you want a single object specifying all the rules.
I can add this functionality to the next version of Optionator.

gkz added a commit to gkz/optionator that referenced this issue Apr 23, 2014

add merge-repeated-objects option
if you repeat a flag, which contains an object value,
(eg. of type [Object]), it will merge the objects rather than
overwrite the whole thing

stemming from eslint/eslint#692
@gkz

This comment has been minimized.

Copy link
Contributor

gkz commented May 9, 2014

As of optionator 0.4.0, published a week ago, you can use the mergeRepeatedObjects option and that will allow you to add the rule flag as I mentioned a while ago. I just don't know exactly what logic you want with that flag - where/how the rules specified on the command line should be merged.

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented May 13, 2014

We basically need to treat these the same as do the -c option (which reads config from a file)

gkz added a commit to gkz/eslint that referenced this issue May 16, 2014

@nzakas nzakas added this to the v0.6.0 milestone May 16, 2014

@nzakas nzakas closed this in d4d364e May 17, 2014

nzakas added a commit that referenced this issue May 17, 2014

Merge pull request #872 from gkz/rule-flag
add rule flag, closes #692
@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented May 17, 2014

@visionmedia all of these are in 0.6.1 now. The --rule flag was just added: http://eslint.org/docs/command-line-interface/

@eslint eslint bot locked and limited conversation to collaborators Feb 7, 2018

@eslint eslint bot added the archived due to age label Feb 7, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.