I've been using jshint with node but just recently had to switch over to using it with Rhino.
I used to be able to do:
jshint --config=jsHintConfig.json fileToLint.js
Now, I've tried replacing that call with:
rhino jshint-rhino.js --config=jsHintConfig.json fileToLint.js
But it doesn't seem to work. I only get the following printed to the console:
Usage: jshint.js file.js
Does jshint-rhino not accept a json configuration file?
Update:
http://anton.kovalyov.net/2011/03/01/jshint-edition-update/
- Says: "Added support for providing options to JSHint as command line arguments when used with our Rhino wrapper" but doesn't say how.
https://github.com/jshint/jshint/issues/27
- Something about specifying options on the cli, but also doesn't say how.
This worked:
rhino jshint-rhino.js file1.js file2.js opt1=true,opt2=true,opt3=false global1,global2,global3
No need to put a comma between file names and it is important to not have spaces before or after the commas for the options and globals.
Related
I am looking for a simple git-like cli argument parser like this:
$ app [global-options] command [command-options]
I tried commander, gitlike-cli, and few other cli parser libs---none of them seem to support segregation of global options from command-options.
commander seems to be supporting it. But when I delved deeper, I found issues. For example, I wanted a -v global option that would enable verbosity at global level. All I did was to set global.verbose = true; in index.js, and in the command specific index-subcmd.js, when I read global.verbose, it is not set!
Am I missing something obvious, or is my understanding correct that node ecosystem is lacking a lib with this functionality? Coming from Java background, I really miss airline.
I wrote a cli parsing library to support the usecase: wiz-cliparse.
I would also like to point out a library I wrote after being disappointed with the popular CLI tools. I created wily-cli to compete against those big name tools by providing more customization and CLI features, and attempting to be easier to use. Subhash's wiz-cliparse should definitely be able to help your use case, but if you need to create a more powerful CLI, I might recommend looking into wily-cli. For your use case, those "global options" would essentially be the the options of your initial command (from your example, that would be app). When creating an option, you would set the passThrough flag in the option configuration...
.option('example', 'Example option', { passThrough: true });
This will set the option to also be passed down to children/gandchildren/etc. commands
In Nov. 2014, 3 months ago, Facebook open-sourced a new command line tool, a static type checker called "Flow". Now I want to run it on a few of my older, existing javascript files. These contain references to the jQuery library.
My JS files were not written with static type-checking in mind.
however, after including /* #flow */ at the top of the file, when I run flow with this Command:
flow myfile.js
Result:
/var/www/myfilejs:70:12,17: identifier jQuery
Unknown global name
Found 1 error
As I understand it, the way to include jQuery into Flow's type checking process is to create an "interface file".
Has anyone done this yet for the jQuery library? (I use jQuery 1.9)
This is my interface file I like to call jQuery.js in a folder I call "flow_lib". This folder can be anywhere.
This is the code the jQuery.js contains for the interface declaration :
declare module "jQuery" {
declare function $(obj: any): any;
}
var $ = require('$').$;
In your .flowconfig, include the folder like this :
[ignore]
[include]
[libs]
<path-to-folder>/flow_lib
[options]
Note : This method does not check for actual jQuery specifications. It's just a quick fix to get rid of the flow warnings and errors related to $ in your code. If you want to be more specific, use something like : https://github.com/solnetdigital/flow-interfaces-jquery/blob/master/interfaces/jquery.js
If you want an actual jQuery flow interface definition, you can look at the one provided in https://github.com/marudor/flowInterfaces.
Install it with:
npm install --save-dev iflow-jquery
or
yarn add --dev iflow-jquery
And then add the following to your .flowconfig file:
[libs]
node_modules/iflow-jquery/index.js.flow
After that, flow will infer the types of the parameters you provide to jquery functions, and will warn you if you are passing the incorrect types.
I am working with Ext Js and Visual Studio. With _references.js I can get the intellisense working. I can add a definition for "Ext" in here for JsHint:
But it still thows 500 errors about ext-all-debug.js
I am wondering if using JsHint here adds any value to my project. Visual Studio seems to take care of true JavaScript syntax errors.
Some examples of the warnings:
JsHint (W116): Expected '===' and instead saw '=='.
or:
JsHint (W083): Don't make functions within a loop.
Should I disable JSHint completely or try to configure it better?
When a major framework does not respect the rules then why should I?
Update:
In web essentials you can create a file called something.weignore. It follows the same syntax than .jshintignore.
Source: http://vswebessentials.com/features/general
You definitely shouldn't be running the linter over ext-all-debug.js. Ignore that using a file called .jshintignore in the root of your project and put the path of ext-all-debug.js in there. An example of the content of .jshintignore could be:
content/js/extjs5.1/ext-debug-all.js
content/js/jquery.js
This would tell jshint to ignore jquery.js and extjs. You can also exclude whole directories. Take a look at the jshint ignore for the jQuery project:
https://github.com/jquery/jquery/blob/master/.jshintignore
external
src/intro.js
src/outro.js
test/data/jquery-1.9.1.js
test/data/badcall.js
test/data/badjson.js
test/data/json_obj.js
test/data/readywaitasset.js
test/data/readywaitloader.js
test/data/support/csp.js
test/data/support/getComputedSupport.js
Maybe Ext JS is working to address those errors internally, maybe they just don't care. But don't let another person's code practises negatively affect your own. If you feel you'll be writing better code by using jshint then use it! There are good reasons behind the warnings you are seeing.
I have set up Syntastic https://github.com/scrooloose/syntastic with vim and I would like to use it for node.js javascript linting.
I have installed jslint
$ jslint routes/index.js
routes/index.js
#1 Expected exactly one space between 'function' and '('.
module.exports = function(app) { // Line 5, Pos 26
....
And I have put this in my ~/.vimrc
let g:syntastic_jslint_checkers=['jslint']
let g:syntastic_check_on_open=1
let g:syntastic_enable_signs=1
But I get no output on :SyntasticCheck
Yet
Syntastic: active mode enabled
Syntastic info for filetype: javascript
Available checker(s): jslint
Currently enabled checker(s): jslint
I recommend JSHint as an alternative for JavaScript linting in Vim. Here is a great answer that explains how to install it.
If you want to use JSHint for creating web sites as well, I'd additionally use RequireJS. This way your JavaScript and your HTML code stay separated (JSHint can't deal with JavaScript inside HTML files).
I'm building a "terminal-thingy" in javascript. The idea is that each command is a separate .js file, in AMD format, and everything is loaded with requirejs.
I want the commands to be called like:
command -s "string u-l: extra" -g http://domain.com/random.txt -r -a --test fixed
and that would then translate into something like:
command({'-s': 'string u-l: extra', '-g': 'http://domain.com/random.txt', '-r': true, '-a': true, '--test': 'fixed'});
But this is where I get stuck, I've tried running different scenarios in my head, but I cant find any good answer, but I can come up with conflicts:
split() - what if there is some extra spaces, that breaks everything
regex - regex relies on getting similar string every time, what if I want to have something like "wget http://code.jquery.com/jquery-1.8.3.min.js"?
defining rules in the command itself - still need to figure out parsing
piping - what if I want to have piping, I have to figure out how to not break on wrong pipes, i.e: "command -s 'random | pipe' | command2 asd"
Any ideas/advices would be appreciated, I'm stuck with this.
Would things be easier if you separated :
parsing (with a special purpose lib like https://github.com/jfd/optparse-js ?)
translating the parsed input into a list of required modules (you would have to define a mapping between arguments and command modules, if I understand correctly)
requiring the said modules, and then passing the relevant arguments to each module ?