Support overwriting JSHINT options in command line #105

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@adrianheine

This implements #27. Note that the predef syntax is jshint FILE.js --predef require module.

Support overwriting JSHINT options in command line (implements #27)
Note that the predef syntax is `jshint FILE.js --predef require module`.
@brentlintner

This comment has been minimized.

Show comment Hide comment
@brentlintner

brentlintner Apr 24, 2012

Contributor

Nice!!

I still intend to test this out myself. In the meantime I had only one thought regarding how options are merged in. I am indifferent myself, but I wonder if (given the (current) consistent non-merging behaviour when using a .jshintrc file) it is more succinct (or generally useful) to handle the specification of JSHint options via the CLI in the same way the custom --config option is handled (i.e. do not search for any .jshintrc files). It may be a bit more complex.. but I figured I might as well bring it up. :-)

Thoughts?

Contributor

brentlintner commented Apr 24, 2012

Nice!!

I still intend to test this out myself. In the meantime I had only one thought regarding how options are merged in. I am indifferent myself, but I wonder if (given the (current) consistent non-merging behaviour when using a .jshintrc file) it is more succinct (or generally useful) to handle the specification of JSHint options via the CLI in the same way the custom --config option is handled (i.e. do not search for any .jshintrc files). It may be a bit more complex.. but I figured I might as well bring it up. :-)

Thoughts?

@adrianheine

This comment has been minimized.

Show comment Hide comment
@adrianheine

adrianheine Apr 25, 2012

Mh, at least my use-case really is about merging in additional options. I could imagine merging only with a explicit --config parameter, though.

Mh, at least my use-case really is about merging in additional options. I could imagine merging only with a explicit --config parameter, though.

@brentlintner

This comment has been minimized.

Show comment Hide comment
@brentlintner

brentlintner May 8, 2012

Contributor

Cool, whichever then. :-)

Also, I do apologize for the merge conflicts now in master (compared with your branch). There was a pull request that fixed a bug and also swapped out argsparser for the cli package, and I pulled that in first.

The cool thing is, I think the cli.options object can now be used to loop through, vs hardcoding the options check (i.e. here). If you would not mind refactoring, rebasing and re-pushing this commit for the new changes, that would be much appreciated. I can also attempt to do this myself if you are not able to.

Thanks again!

Contributor

brentlintner commented May 8, 2012

Cool, whichever then. :-)

Also, I do apologize for the merge conflicts now in master (compared with your branch). There was a pull request that fixed a bug and also swapped out argsparser for the cli package, and I pulled that in first.

The cool thing is, I think the cli.options object can now be used to loop through, vs hardcoding the options check (i.e. here). If you would not mind refactoring, rebasing and re-pushing this commit for the new changes, that would be much appreciated. I can also attempt to do this myself if you are not able to.

Thanks again!

@adrianheine

This comment has been minimized.

Show comment Hide comment
@adrianheine

adrianheine Jul 16, 2012

Sorry for being silent for so long. Thing is, the cli package does not allow unrecognized arguments as long as any arguments are specified in the call to cli.parse, so we basically have three options:

  • Specify all JSHINT options as arguments
  • Catch all non-node-jshint options before call to cli.parse, parse them ourselves (or maybe better add dummy entries to the cli.parse argument)
  • Call cli.parse without parameter, and hence, disable cli argument validation

I tend to propose the second.

Sorry for being silent for so long. Thing is, the cli package does not allow unrecognized arguments as long as any arguments are specified in the call to cli.parse, so we basically have three options:

  • Specify all JSHINT options as arguments
  • Catch all non-node-jshint options before call to cli.parse, parse them ourselves (or maybe better add dummy entries to the cli.parse argument)
  • Call cli.parse without parameter, and hence, disable cli argument validation

I tend to propose the second.

@brentlintner

This comment has been minimized.

Show comment Hide comment
@brentlintner

brentlintner Aug 2, 2012

Contributor

No worries (t'is open source), and sorry for the delay myself! I agree on the 2nd one. Although, ideally, we would not have to manually maintain the array of options, somehow. There has to be a good way to do that though..

Contributor

brentlintner commented Aug 2, 2012

No worries (t'is open source), and sorry for the delay myself! I agree on the 2nd one. Although, ideally, we would not have to manually maintain the array of options, somehow. There has to be a good way to do that though..

@Kaleesastha

This comment has been minimized.

Show comment Hide comment
@Kaleesastha

Kaleesastha Mar 11, 2014

How to exclude multiple directory using jshint command from commandLine.

jshint --exclude=

How to exclude multiple directory using jshint command from commandLine.

jshint --exclude=

@valueof

This comment has been minimized.

Show comment Hide comment
@valueof

valueof Mar 24, 2014

Member

This repo is not used anymore—use jshint/jshint for bugs and JSHint mailing list for questions.

Member

valueof commented Mar 24, 2014

This repo is not used anymore—use jshint/jshint for bugs and JSHint mailing list for questions.

@valueof valueof closed this Mar 24, 2014

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