This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
forked from eslint/eslint
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request eslint#42 from evangoer/add_docs_dir
Convert wiki pages to a /docs directory of Markdown
- Loading branch information
Showing
20 changed files
with
1,655 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
# 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 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). | ||
|
||
## Philosophy | ||
|
||
Every rule: | ||
|
||
* Is standalone | ||
* Can be able to be turned off or on (nothing can be deemed "too important to turn off") | ||
* Can be set to be a warning or error individually | ||
* Is turned on by providing a non-zero number and off by providing zero | ||
|
||
Additionally: | ||
|
||
* The only "error" that ships with ESLint is a parser error | ||
* Not all rules bundled with ESLint are enabled by default | ||
* Bundled rules that are enabled are set as warnings (not errors) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,17 @@ | ||
# Architecture | ||
|
||
At a high level, there are a few key parts to ESLint: | ||
|
||
* `bin/eslint.js` - this is the file that actually gets executed with the command line utility. It's a dumb wrapper that does nothing more than bootstrap ESLint, passing the command line arguments to `cli`. This is intentionally small so as not to require heavy testing. | ||
* `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 | ||
|
||
TODO | ||
|
||
## 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. | ||
|
||
Once the AST is available, `estraverse` is used to traverse the AST from top to bottom. At each node, the `eslint` object emits an event that has the same name as the node type (i.e., "Identifier", "WithStatement", etc.). On the way back up the subtree, an event is emitted with the AST type name and suffixed with ":after", such as "Identifier:after" - this allows rules to take action both on the way down and on the way up in the traversal. Each event is emitted with the appropriate AST node available. |
Oops, something went wrong.