|
2 | 2 |
|
3 | 3 | # Documentation
|
4 | 4 |
|
5 |
| -JSHint is a program that flags suspicious usage in programs written in JavaScript. |
6 |
| -The core project consists of a library itself as well as a CLI program distributed |
7 |
| -as a Node module. |
| 5 | +JSHint helps you find dubious and invalid syntax in JavaScript files, enabling |
| 6 | +you to quickly identify potential problems. |
8 | 7 |
|
9 |
| -More docs: [List of all JSHint options](/docs/options/) · [Command-line |
10 |
| -Interface](/docs/cli/) · [API](/docs/api/) · [Writing your own |
11 |
| -reporter](/docs/reporters/) · [FAQ](/docs/faq/) |
| 8 | +The project consists of a core library and also a CLI module that runs on |
| 9 | +[Node.js](https://nodejs.org). |
| 10 | + |
| 11 | +More docs: [Directives](#directives) · [JSHint options](/docs/options/) · |
| 12 | +[Command-line Interface](/docs/cli/) · [API](/docs/api/) · |
| 13 | +[Writing your own reporter](/docs/reporters/) · [FAQ](/docs/faq/) |
12 | 14 |
|
13 | 15 | ### Basic usage
|
14 | 16 |
|
15 |
| -First, check out [the installation instructions](/install/) for details on |
16 |
| -how to install JSHint in your perferred environment. Both the command line |
17 |
| -executable and the JavaScript API offer unique ways to configure JSHint's |
18 |
| -behaviour. The most common usages are: |
| 17 | +After [installaling JSHint](/install/) there are three main ways to use it: |
| 18 | + |
| 19 | +* [via command-line tool](/docs/cli/) (via [Node.js](https://nodejs.org)) |
| 20 | +* [via JavaScript module](/docs/api/) |
| 21 | +* [via editor integration](/install/#urg) |
19 | 22 |
|
20 |
| -- [As a command-line tool](/docs/cli/) (via [Node.js](https://nodejs.org)) |
21 |
| -- [As a JavaScript module](/docs/api/) |
| 23 | +However, before putting it to use, you should set some options (see |
| 24 | +**Configuration** section below for how), in particular: |
22 | 25 |
|
23 |
| -Regardless of your preferred environment, you can control JSHint's behavior |
24 |
| -through specifying any number of [linting options](/docs/options/). In |
25 |
| -addition, JSHint will honor any directives declared within the input source |
26 |
| -code--see [the section on in-line directives](#inline-configuration) for more |
27 |
| -information. |
| 26 | +* [ECMA Script version](/docs/options/#esversion) |
| 27 | +* [Environment](/docs/options/#environments) (eg. Node.js, browser, jQuery, etc) |
28 | 28 |
|
29 | 29 | ### Configuration
|
30 | 30 |
|
31 |
| -JSHint comes with a default set of warnings but it was designed to be very |
32 |
| -configurable. There are three main ways to configure your copy of JSHint: |
33 |
| -you can either specify the configuration file manually via the `--config` flag, |
34 |
| -use a special file `.jshintrc` or put your config into your projects `package.json` |
35 |
| -file under the `jshintConfig` property. In case of `.jshintrc`, JSHint will start |
36 |
| -looking for this file in the same directory as the file that's being linted. |
37 |
| -If not found, it will move one level up the directory tree all the way up to |
38 |
| -the filesystem root. (Note that if the input comes from stdin, JSHint doesn't |
39 |
| -attempt to find a configuration file) |
40 |
| - |
41 |
| -This setup allows you to have different configuration files per project. Place |
42 |
| -your file into the project root directory and, as long as you run JSHint from |
43 |
| -anywhere within your project directory tree, the same configuration file will |
44 |
| -be used. |
45 |
| - |
46 |
| -Configuration file is a simple JSON file that specifies which JSHint options |
47 |
| -to turn on or off. For example, the following file will enable warnings about |
48 |
| -undefined and unused variables and tell JSHint about a global variable named |
49 |
| -`MY_GLOBAL`. |
| 31 | +By default, JSHint will report all potential issues with your code. This is useful |
| 32 | +for developers who are just starting with JavaScript, but can become irritating |
| 33 | +for more experienced developers. Luckily, JSHint can be customised to your specific |
| 34 | +requirements. |
| 35 | + |
| 36 | +There are three ways to define options, listed in order of precendence: |
| 37 | + |
| 38 | +1. **Inline** - via code comments |
| 39 | + * block level (eg. within a function) |
| 40 | + * script level |
| 41 | +2. **Settings file** |
| 42 | + * `package.json` - project-level settings |
| 43 | + * `.jshintrc` - project-level or global settings |
| 44 | +3. **Command line** - use the `--config` flag |
| 45 | + |
| 46 | +Note: Some options, such as the `exported` and `ignore` directives, can only be |
| 47 | +specified inline as they apply to a specific file or block of code. |
| 48 | + |
| 49 | +#### Inline options |
| 50 | + |
| 51 | +To specify options inline, simply add a comment to your script that starts with |
| 52 | +a valid directive (most commonly, `jshint`) followed by one or more options. |
| 53 | +Both line and block comments work: |
| 54 | + |
| 55 | + // jshint esversion: 6, node: true |
| 56 | + /* jshint esversion: 6, node: true */ |
| 57 | + |
| 58 | +If options are placed within a function, they will only apply to that function: |
| 59 | + |
| 60 | + function foo() { |
| 61 | + // jshint varstmt: true |
| 62 | + var bar = 'qux'; // displays warning about using vars |
| 63 | + } |
| 64 | + |
| 65 | + var meh = 'moo'; // no warning given |
| 66 | + |
| 67 | +#### Settings file |
| 68 | + |
| 69 | +You can use either a `.jshintrc` or a `package.json` file to specify project-wide |
| 70 | +options. |
| 71 | + |
| 72 | +**Example: `package.json`** |
| 73 | + |
| 74 | +Set project-wide settings by adding a `jshintConfig` section to your `package.json` |
| 75 | +file: |
50 | 76 |
|
51 | 77 | {
|
52 |
| - "undef": true, |
53 |
| - "unused": true, |
54 |
| - "predef": [ "MY_GLOBAL" ] |
| 78 | + "jshintConfig": { |
| 79 | + "esversion": 6, |
| 80 | + "node": true |
| 81 | + } |
55 | 82 | }
|
56 | 83 |
|
57 |
| -<a name="inline-configuration"></a> |
| 84 | +**Example: `.jshintrc`** |
| 85 | + |
| 86 | +JSHint will look in the same folder as the file being linted, and if not found |
| 87 | +there, it will try each parent folder in turn up to file system root. Useful if |
| 88 | +you want to define default settings for all projects. |
| 89 | + |
| 90 | + { |
| 91 | + "undef": true, |
| 92 | + "unused": true, |
| 93 | + "predef": [ "MY_GLOBAL" ] |
| 94 | + } |
58 | 95 |
|
59 |
| -### Inline configuration |
| 96 | +Note: If the input comes from `stdin`, JSHint doesn't attempt to find a |
| 97 | +configuration file (as it doesn't know where to start the search). |
60 | 98 |
|
61 |
| -In addition to using configuration files you can configure JSHint from within your |
62 |
| -files using special comments. These comments start with a label such as |
63 |
| -`jshint` or `globals` (complete list below) and are followed by a |
64 |
| -comma-separated list of values. For example, the following snippet will enable |
65 |
| -warnings about undefined and unused variables and tell JSHint about a global |
66 |
| -variable named `MY_GLOBAL`. |
| 99 | +#### Command line |
67 | 100 |
|
68 |
| - /* jshint undef: true, unused: true */ |
69 |
| - /* globals MY_GLOBAL */ |
| 101 | +For details, see `--config` flag section in [Command Line Interface](/docs/cli/). |
70 | 102 |
|
71 |
| -You can use both multi- and single-line comments to configure JSHint. These |
72 |
| -comments are function scoped meaning that if you put them inside a function they |
73 |
| -will affect only this function's code. |
| 103 | +<a name="directives"></a> |
74 | 104 |
|
75 | 105 | ### Directives
|
76 | 106 |
|
@@ -217,7 +247,7 @@ above and then re-enable the warning afterwards:
|
217 | 247 | }
|
218 | 248 | /*jshint +W089 */
|
219 | 249 |
|
220 |
| -[This page](/docs/options/) contains a list of all options supported by JSHint. |
| 250 | +See [Options](/docs/options/) for a list of all options supported by JSHint. |
221 | 251 |
|
222 | 252 | #### Switch statements
|
223 | 253 |
|
|
0 commit comments