docs: Clean up structure

Closes eslint#117.
evgeniyworkbel · Jul 23, 2013 · 457901f · 457901f
1 parent e08c673
commit 457901f
Show file tree

Hide file tree

Showing 24 changed files with 33 additions and 34 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -1,21 +1,21 @@
 # Home
 
-## [About](About.md)
+## [About](about/README.md)
 
 Learn more about ESLint and why it came about and the general philosophy behind it.
 
-## [Architecture](Architecture.md)
+## [Architecture](architecture/README.md)
 
 Explains how the code is organized and why it is organized in that way.
 
-## [Rules](Rules.md)
+## [Rules](rules/README.md)
 
 ESLint comes with some default rules to get you started. This is the complete list.
 
-## [Command Line Interface](Command-line-interface.md)
+## [Command Line Interface](command-line-interface/README.md)
 
 ESLint is written to be used primarily for the command line. Learn about its usage here.
 
-## [Developer Guide](Developer-Guide.md)
+## [Developer Guide](developer-guide/README.md)
 
 The developer guide contains information for ESLint developers. If you want to contribute to the project, or even just tinker on your own, this guide explains how to get the source and work with it.
diff --git a/docs/About.md → docs/about/README.md b/docs/About.md → docs/about/README.md
@@ -1,10 +1,10 @@
 # About
 
-ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. The goal of ESLint is to provide a pluggable linting utility for JavaScript. While [JSHint](http://jshint.com) and [JSLint](http://jslint.com) dominate JavaScript linting, neither one provides an API for plugging in your own rules. This means that if you need a new rule, you need to write it and get it accepted into the released product. That's lousy if you need to quickly add something to your build system or even if you need company-specific rules.
+ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. The goal of ESLint is to provide a pluggable linting utility for JavaScript. While [JSHint](http://jshint.com/) and [JSLint](http://jslint.com/) dominate JavaScript linting, neither one provides an API for plugging in your own rules. This means that if you need a new rule, you need to write it and get it accepted into the released product. That's lousy if you need to quickly add something to your build system or even if you need company-specific rules.
 
 ESLint is designed to have all rules completely pluggable. The default rules are written just like any plugin rules would be. They can all follow the same pattern, both for the rules themselves as well as tests. While ESLint will ship with some built-in rules for compatibility with JSHint and JSLint, you'll be able to dynamically load rules at any point in time.
 
-ESLint is written using Node.js to provide a fast runtime environment and easy installation via [npm](http://npmjs.org).
+ESLint is written using Node.js to provide a fast runtime environment and easy installation via [npm](http://npmjs.org/).
 
 ## Philosophy
 

diff --git a/docs/Command-line-interface.md → docs/command-line-interface/README.md b/docs/Command-line-interface.md → docs/command-line-interface/README.md
@@ -28,11 +28,11 @@ Options:
   -f, --format  Use a specific output format.               [default: "compact"]
 ```
 
-### -h, --help
+### `-h`, `--help`
 
 This option outputs the help menu, displaying all of the available options. All other flags are ignored when this is present.
 
-### -c, --config
+### `-c`, `--config`
 
 This option allows you to specify an alternate configuration file for ESLint (see below for more on configuration files). By default, it uses `conf/eslint.json`.
 
@@ -42,7 +42,7 @@ Example:
 
 This example uses the configuration file at `~/my-eslint.json` instead of the default.
 
-### -f, --format
+### `-f`, `--format`
 
 This options specifies the output format for the console. At the moment, there is only `compact`, but more will be added soon.
 
@@ -56,7 +56,7 @@ When specified, the given format is output to the console. If you'd like to save
 
 This saves the output into the `results.txt` file.
 
-### --rulesdir
+### `--rulesdir`
 
 This option allows you to specify a second directory from which to load rules files. This allows you to dynamically loading new rules at run time. This is useful when you have custom rules that aren't suitable for being bundled with ESLint.
 
@@ -78,4 +78,3 @@ You can turn specific rules on or off by creating your own configuration file. T
   * `nodejs` - set to true to indicate that the code being inspected is intended for use with NodeJS. ESLint will automatically add the appropriate references.
 
 (More options to be added soon.)
-
diff --git a/docs/Developer-Guide.md → docs/developer-guide/README.md b/docs/Developer-Guide.md → docs/developer-guide/README.md
@@ -14,22 +14,22 @@ In order to work with ESLint as a developer, it's recommended that:
 
 If that sounds like you, then continue reading to get started.
 
-## Section 1: Get the [Source Code](Source-Code.md)
+## Section 1: Get the [Source Code](source-code.md)
 
 Before you can get started, you'll need to get a copy of the ESLint source code. This section explains how to do that and a little about the source code structure.
 
-## Section 2: Setup a [Development-Environment](Development-Environment.md)
+## Section 2: Setup a [Development Environment](development-environment.md)
 
 Developing for ESLint is a bit different than running it on the command line. This section shows you how to setup a development environment and get you ready to write code.
 
-## Section 3: Run the [Unit Tests](Unit-Tests.md)
+## Section 3: Run the [Unit Tests](unit-tests.md)
 
 There are a lot of unit tests included with ESLint to make sure that we're keeping on top of code quality. This section explains how to run the unit tests.
 
-## Section 4: [Working with Rules](Working-with-Rules.md)
+## Section 4: [Working with Rules](working-with-rules.md)
 
 You're finally ready to start working with rules. You may want to fix an existing rule or create a new one. This section explains how to do all of that.
 
-## Section 5: [Contributing](Contributing.md)
+## Section 5: [Contributing](contributing.md)
 
 Once you've made changes that you want to share with the community, the next step is to submit those changes back via a pull request.
diff --git a/docs/Architecture.md → docs/developer-guide/architecture.md b/docs/Architecture.md → docs/developer-guide/architecture.md
@@ -6,11 +6,11 @@ At a high level, there are a few key parts to ESLint:
 * `lib/cli.js` - this is the heart of the ESLint CLI. It takes an array of arguments and then uses `eslint` to execute the commands. By keeping this as a separate utility, it allows others to effectively call ESLint from within another Node.js program as if it were done on the command line. The main call is `cli.execute()`. This is also the part that does all the file reading, directory traversing, input, and output.
 * `lib/eslint.js` - this is the core `eslint` object that does code verifying based on configuration options. This file does not file I/O and does not interact with the `console` at all. For other Node.js programs that have JavaScript text to verify, they would be able to use this interface directly.
 
-## The cli Object
+## The `cli` object
 
 TODO
 
-## The eslint Object
+## The `eslint` object
 
 The main method of the `eslint` object is `verify()` and accepts two arguments: the source text to verify and a configuration object (the baked configuration of the given configuration file plus command line options). The method first parses the given text with Esprima and retrieves the AST. The AST is produced with both line/column and range locations which are useful for reporting location of issues and retrieving the source text related to an AST node, respectively.
 

diff --git a/docs/Code-Conventions.md → docs/developer-guide/code-conventions.md b/docs/Code-Conventions.md → docs/developer-guide/code-conventions.md
diff --git a/docs/Contributing.md → docs/developer-guide/contributing.md b/docs/Contributing.md → docs/developer-guide/contributing.md
@@ -21,18 +21,18 @@ We want to accept your contribution. Following these guidelines helps to create
     * 0.6.x
     * 0.8.x
     * 0.10.x
-* Follow the [Code Conventions](Code-Conventions.md).
+* Follow the [Code Conventions](code-conventions.md).
 
 ## New Rules
 
 Once you've written a rule, you can decide whether the rule is generic enough to be included in ESLint or if it's specific to your own use case. If you decide to submit your rule via a pull request, there are some things to keep in mind:
 
 1. Rules must be accompanied by unit tests.
-1. In your pull request include:
+2. In your pull request include:
     1. The use case for the rule - what is it trying to prevent or flag?
-    1. Why you believe this rule is generic enough to be included in the main distribution
-    1. Whether the rule should be on or off by default.
-    1. Documentation for the rule (see [no-console](no-console.md) as an example). Put this documentation directly into the pull request.
+    2. Why you believe this rule is generic enough to be included in the main distribution
+    3. Whether the rule should be on or off by default.
+    4. Documentation for the rule (see [no-console](../rules/no-console.md) as an example). Put this documentation directly into the pull request.
 
 Keep in mind that not all rules will be accepted for the main distribution. You may also request that your rule by on by default but we may accept it as off by default.
 

diff --git a/docs/Development-Environment.md → ...eveloper-guide/development-environment.md b/docs/Development-Environment.md → ...eveloper-guide/development-environment.md
@@ -4,9 +4,9 @@ ESLint has a very lightweight development environment that makes updating code f
 
 ## Install Node.js
 
-Go to http://nodejs.org to download and install the latest stable version for your operating system.
+Go to http://nodejs.org/ to download and install the latest stable version for your operating system.
 
-Most of the installers come with [npm](http://npmjs.org) already installed, but if for some reason it doesn't work on your system, you can install it manually using the instructions on the website.
+Most of the installers come with [npm](http://npmjs.org/) already installed, but if for some reason it doesn't work on your system, you can install it manually using the instructions on the website.
 
 ## Development Mode
 
@@ -33,6 +33,6 @@ Be sure to run `npm test` whenever you make changes to ensure that you've not br
 Whenever you make changes to the ESLint source files, you'll need to run `npm test` to rerun the tests. The workflow is:
 
 1. Make changes
-1. Run `npm test` to run tests on the command line
+2. Run `npm test` to run tests on the command line
 
-You'll have to do this each time you make a change.  The tests are run automatically whenever a pull request is received, so make sure to verify your changes work before submitting them.
+You'll have to do this each time you make a change. The tests are run automatically whenever a pull request is received, so make sure to verify your changes work before submitting them.
diff --git a/docs/Source-Code.md → docs/developer-guide/source-code.md b/docs/Source-Code.md → docs/developer-guide/source-code.md
@@ -6,7 +6,7 @@ If you simply want to create a local copy of the source to play with, you can cl
 
     git clone git://github.com/nzakas/eslint.git
 
-If you're planning on contributing to ESLint, then it's a good idea to fork the repository. You can find instructions for forking a repository at http://help.github.com/fork-a-repo/. After forking the ESLintrepository, you'll want to create a local copy of your fork.
+If you're planning on contributing to ESLint, then it's a good idea to fork the repository. You can find instructions for forking a repository at http://help.github.com/fork-a-repo/. After forking the ESLint repository, you'll want to create a local copy of your fork.
 
 ## Start Developing
 

diff --git a/docs/Unit-Tests.md → docs/developer-guide/unit-tests.md b/docs/Unit-Tests.md → docs/developer-guide/unit-tests.md
diff --git a/docs/Working-with-Rules.md → docs/developer-guide/working-with-rules.md b/docs/Working-with-Rules.md → docs/developer-guide/working-with-rules.md
diff --git a/docs/Rules.md → docs/rules/README.md b/docs/Rules.md → docs/rules/README.md
@@ -8,9 +8,9 @@ The following rules point out areas where you might have made mistakes.
 
 * [no-console](no-console.md) - disallow use of `console`
 * [no-dangle](no-dangle.md) - disallow trailing commas in object literals
-* [no-debugger](No-debugger.md) - disallow use of `debugger`
-* [no-empty](No-empty.md) - disallow empty statements
-* [no-unreachable](No-unreachable.md) - disallow unreachable statements after a return, throw, continue, or break statement
+* [no-debugger](no-debugger.md) - disallow use of `debugger`
+* [no-empty](no-empty.md) - disallow empty statements
+* [no-unreachable](no-unreachable.md) - disallow unreachable statements after a return, throw, continue, or break statement
 * [use-isnan](use-isnan.md) - disallow comparisons with the value `NaN`
 
 ## Best Practices
@@ -35,7 +35,7 @@ These rules are purely matters of style and are quite subjective.
 
 * [camelcase] - require camel case names
 * [new-cap](new-cap.md) - require a capital letter for constructors
-* [quote-props](Quote-props.md) - require quotes around object literal property names
+* [quote-props](quote-props.md) - require quotes around object literal property names
 * [semi] - require use of semicolons instead of relying on ASI
 
 ## Alternate Rules
@@ -44,7 +44,7 @@ These rules are purely matters of style and are quite subjective.
 
 ## Legacy
 
-The following rules are included for compatibility with [JSHint](http://jshint.com) and [JSLint](http://jslint.com). While the names of the rules may not match up with the JSHint/JSLint counterpart, the functionality is the same.
+The following rules are included for compatibility with [JSHint](http://jshint.com/) and [JSLint](http://jslint.com/). While the names of the rules may not match up with the JSHint/JSLint counterpart, the functionality is the same.
 
 * [no-bitwise] - disallow use of bitwise operators (off by default)
 * [guard-for-in] - make sure `for-in` loops have an `if` statement (off by default)
diff --git a/docs/brace-style.md → docs/rules/brace-style.md b/docs/brace-style.md → docs/rules/brace-style.md
diff --git a/docs/new-cap.md → docs/rules/new-cap.md b/docs/new-cap.md → docs/rules/new-cap.md
diff --git a/docs/no-arg.md → docs/rules/no-arg.md b/docs/no-arg.md → docs/rules/no-arg.md
diff --git a/docs/no-console.md → docs/rules/no-console.md b/docs/no-console.md → docs/rules/no-console.md
diff --git a/docs/no-dangle.md → docs/rules/no-dangle.md b/docs/no-dangle.md → docs/rules/no-dangle.md
diff --git a/docs/No-debugger.md → docs/rules/no-debugger.md b/docs/No-debugger.md → docs/rules/no-debugger.md
diff --git a/docs/No-empty.md → docs/rules/no-empty.md b/docs/No-empty.md → docs/rules/no-empty.md
diff --git a/docs/no-new-func.md → docs/rules/no-new-func.md b/docs/no-new-func.md → docs/rules/no-new-func.md
diff --git a/docs/No-unreachable.md → docs/rules/no-unreachable.md b/docs/No-unreachable.md → docs/rules/no-unreachable.md
diff --git a/docs/Quote-props.md → docs/rules/quote-props.md b/docs/Quote-props.md → docs/rules/quote-props.md
diff --git a/docs/smarter-eqeqeq.md → docs/rules/smarter-eqeqeq.md b/docs/smarter-eqeqeq.md → docs/rules/smarter-eqeqeq.md
diff --git a/docs/use-isnan.md → docs/rules/use-isnan.md b/docs/use-isnan.md → docs/rules/use-isnan.md