eslint/docs/about/index.md

   1 # About
   2
   3 ESLint is an open source JavaScript linting utility originally created by Nicholas C. Zakas in June 2013. Code [linting][] is a type of static analysis that is frequently used to find problematic patterns or code that doesn't adhere to certain style guidelines. There are code linters for most programming languages, and compilers sometimes incorporate linting into the compilation process.
   4
   5 JavaScript, being a dynamic and loosely-typed language, is especially prone to developer error. Without the benefit of a compilation process, JavaScript code is typically executed in order to find syntax or other errors. Linting tools like ESLint allow developers to discover problems with their JavaScript code without executing it.
   6
   7 The primary reason ESLint was created was to allow developers to create their own linting 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 to make it useful from the start, you'll be able to dynamically load rules at any point in time.
   8
   9 ESLint is written using Node.js to provide a fast runtime environment and easy installation via [npm][].
  10
  11 [linting]: https://en.wikipedia.org/wiki/Lint_(software)
  12 [npm]: https://npmjs.org/
  13
  14 ## Philosophy
  15
  16 Everything is pluggable:
  17
  18 * Rule API is used both by bundled and custom rules
  19 * Formatter API is used both by bundled and custom formatters
  20 * Additional rules and formatters can be specified at runtime
  21 * Rules and formatters don't have to be bundled to be used
  22
  23 Every rule:
  24
  25 * Is standalone
  26 * Can be turned off or on (nothing can be deemed "too important to turn off")
  27 * Can be set to a warning or error individually
  28
  29 Additionally:
  30
  31 * Rules are "agenda free" - ESLint does not promote any particular coding style
  32 * Any bundled rules are generalizable
  33
  34 The project:
  35
  36 * Values documentation and clear communication
  37 * Is as transparent as possible
  38 * Believes in the importance of testing