Showing preview only (474K chars total). Download the full file or copy to clipboard to get everything.
Repository: JedWatson/happiness
Branch: master
Commit: 8d99bc3eb3ea
Files: 33
Total size: 413.9 KB
Directory structure:
gitextract_6yufa38k/
├── .gitignore
├── .npmignore
├── .travis.yml
├── AUTHORS.md
├── CHANGELOG.md
├── CONTRIBUTING.md
├── LICENSE
├── README.md
├── RULES.md
├── bin/
│ ├── cmd.js
│ └── update-authors.sh
├── docs/
│ ├── README-en.md
│ ├── README-esla.md
│ ├── README-iteu.md
│ ├── README-kokr.md
│ ├── README-ptbr.md
│ ├── README-zhcn.md
│ ├── README-zhtw.md
│ ├── RULES-en.md
│ ├── RULES-esla.md
│ ├── RULES-iteu.md
│ ├── RULES-kokr.md
│ ├── RULES-ptbr.md
│ ├── RULES-zhcn.md
│ ├── RULES-zhtw.md
│ └── webstorm.md
├── eslintrc.json
├── index.js
├── options.js
├── package.json
└── test/
├── api.js
├── clone.js
└── cmd.js
================================================
FILE CONTENTS
================================================
================================================
FILE: .gitignore
================================================
node_modules/
tmp/
================================================
FILE: .npmignore
================================================
test/
docs/logos/
tmp/
bin/update-authors.sh
.travis.yml
badge.png
badge.svg
CONTRIBUTING.md
sticker.png
sticker.svg
================================================
FILE: .travis.yml
================================================
language: node_js
node_js:
- '4'
- '6'
- 'node'
================================================
FILE: AUTHORS.md
================================================
# Authors
#### Ordered by first contribution.
- Feross Aboukhadijeh (feross@feross.org)
- Jonny Buchanan (jonathan.buchanan@gmail.com)
- Dan Flettre (flettre@gmail.com)
- Brandon Horst (brandonhorst@gmail.com)
- Yoshua Wuyts (yoshuawuyts@gmail.com)
- Alexander Gugel (alexander.gugel@gmail.com)
- Nate Goldman (nnmgoldman@gmail.com)
- Max Ogden (max@maxogden.com)
- Ricardo Barros (ricardofbarros@hotmail.com)
- Yoshua Wuyts (i@yoshuawuyts.com)
- Shahar Or (mightyiampresence@gmail.com)
- Brent Burgoyne (bburgoyne@instructure.com)
- Santiago Gil (gil.educaciontdf@gmail.com)
- Vasiliy Loginevskiy (yeti-or@yandex-team.ru)
- Joe Lencioni (joe.lencioni@brigade.com)
- Leo Melin (leo.melin@eee.do)
- G. Kay Lee (balancetraveller+github@gmail.com)
- Lorenzo Villani (lorenzo@villani.me)
- Ahmad Nassri (ahmad@ahmadnassri.com)
- Mathias Buus (mathiasbuus@gmail.com)
- Alex Potsides (alex@achingbrain.net)
- Dan Lee (dlee@yammer-inc.com)
- ishamf (ishamf@users.noreply.github.com)
- Eric Zeng (leizeng@thoughtworks.com)
- Cesar Andreu (cesarandreu@gmail.com)
- Daniel Cousens (dcousens@users.noreply.github.com)
- Enikő Nagy (eenagy@users.noreply.github.com)
- Matthieu Prat (matthieuprat@gmail.com)
- Dany Shaanan (danyshaanan@gmail.com)
- Thomas Reggi (socialtr@gmail.com)
- Stephen Kubovic (skubovic@gmail.com)
- David Keijser (keijser@gmail.com)
- Nick Colley (nickcolley7@gmail.com)
- Florian Ebeling (mail@florianebeling.com)
- Rico Sta. Cruz (rstacruz@users.noreply.github.com)
- reggi (thomas@reggi.com)
- Machisté N. Quintana (mnquintana@users.noreply.github.com)
- Jiri Spac (capajj@gmail.com)
- Sonny Piers (sonny@fastmail.net)
- fscherwi (fscherwi@users.noreply.github.com)
- Gustav Nikolaj Olsen (gno@one.com)
- skorlir (skorlir@gmail.com)
- JP Richardson (jprichardson@gmail.com)
- chenxsan (chenxsan@users.noreply.github.com)
- Tara Z. Manicsic (tara@modulus.io)
- Jakub Elżbieciak (jelz@post.pl)
- Dale Jefferson (dale@dalejefferson.com)
- Paul Kernfeld (paulkernfeld@gmail.com)
- Wes Todd (wes@wesleytodd.com)
- rajcoss (nagrajan@ciena.com)
- Jed Watson (jed.watson@me.com)
- Joe Whitfield-Seed (joeseed86@gmail.com)
- botbotbot (tkroputa@gmail.com)
- Žiga Vidic (zigomir@gmail.com)
- Wade Simmons (wsimmons@gmail.com)
- Tushar Mathur (tusharmath@gmail.com)
- Joshua Jabbour (code@joshuajabbour.com)
- Zeke Sikelianos (zeke@sikelianos.com)
- darren higgins (darrhiggs@users.noreply.github.com)
- Joris Blaak (joris@label305.com)
#### Generated by bin/update-authors.sh.
================================================
FILE: CHANGELOG.md
================================================
# Change Log
All notable changes to this project will be documented in this file.
This project adheres to [Semantic Versioning](http://semver.org/).
## 10.0.2 - 2017-04-14
### Changed rules
- Relax rule: Disallow import of modules using absolute paths ([import/no-absolute-path](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-absolute-path.md)) [#861](https://github.com/standard/standard/issues/861)
- This rule was responsible for up to 25% of the running time of `standard`, so we are disabling it until its performance improves.
## 10.0.1 - 2017-04-06
- Internal changes (incremented dependency versions)
## 10.0.0 - 2017-04-04
**`standard` just turned 10.0.0!** 🎉
As with every new major release, there are lots of new rules in 10.0.0 designed to
help catch bugs and make programmer intent more explicit.
`standard` is more popular than ever – **330,000 downloads per month!** It's even
more popular – **670,000 downloads per month** – if you include the
[shareable ESLint config](https://www.npmjs.com/package/eslint-config-standard)
that we also publish.
The most important change in 10.0.0 is that **using deprecated Node.js APIs is now
considered an error**. It's finally time to update those dusty old APIs!
Deprecated APIs are problematic because they may print warning messages in the
console in recent versions of Node.js. This often confuses users and leads to
unnecessary support tickets for project maintainers.
Some deprecated APIs are even insecure (or at least prone to incorrect usage) which
can have serious security implications. For that reason, `standard` now considers
usage of `Buffer(num)` to be an error, since this function returns uninitialized
program memory which could contain confidential information like passwords or keys.
Instead of `Buffer(num)`, consider using `Buffer.alloc(num)` or `Buffer.from(obj)`
which make the programmer's intent clearer. These functions exist in all currently
supported versions of Node.js, including Node.js 4.x. For more background,
[see this Node.js issue](https://github.com/nodejs/node/issues/4660).
We also improved some rules to support common patterns in code bases that use
React, JSX, and Flow.
When you upgrade, consider running `standard --fix` to automatically fix some of
the issues caught by this new version.
### New features
- Update ESLint from 3.15.x to 3.19.x.
- Node.js API: Add `standard.lintTextSync` method
### New rules
*(Estimated % of affected standard users, based on test suite in parens)*
- Disallow using deprecated Node.js APIs ([node/no-deprecated-api](https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-deprecated-api.md)) [#693](https://github.com/standard/standard/issues/693) (13%)
- Ensures that code always runs without warnings on the latest versions of Node.js
- Ensures that safe Buffer methods (`Buffer.from()`, `Buffer.alloc()`) are used instead of `Buffer()`
- Enforce callbacks always called with Node.js-style error first ([standard/no-callback-literal](https://github.com/xjamundx/eslint-plugin-standard#rules-explanations)) [#623](https://github.com/standard/standard/issues/623) (3%)
- Functions named `callback` or `cb` must be invoked with `null`, `undefined`, or an `Error` as the first argument
- Disallows using a string instead of an `Error` object
- Disallows confusing callbacks that do not follow the standard Node.js pattern
- Disallow any imports that come after non-import statements ([import/first](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/first.md)) [#806](https://github.com/standard/standard/issues/806) (1%)
- Disallow unnecessary return await ([no-return-await](http://eslint.org/docs/rules/no-return-await)) [#695](https://github.com/standard/standard/issues/695) (0%)
- Disallow comma-dangle in functions ([comma-dangle](http://eslint.org/docs/rules/comma-dangle)) [#787](https://github.com/standard/standard/issues/787) (0%)
- Disallow repeated exports of names or defaults ([import/export](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/export.md)) [#806](https://github.com/standard/standard/issues/806) (0%)
- Disallow import of modules using absolute paths ([import/no-absolute-path](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-absolute-path.md)) [#806](https://github.com/standard/standard/issues/806) (0%)
- Disallow Webpack loader syntax in imports ([import/no-webpack-loader-syntax](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-webpack-loader-syntax.md)) [#806](https://github.com/standard/standard/issues/806) (0%)
- Disallow comparing against -0 ([no-compare-neg-zero](http://eslint.org/docs/rules/no-compare-neg-zero)) [#812](https://github.com/standard/standard/issues/812) (0%)
### Changed rules
- Relax rule: allow using `...rest` to omit properties from an object ([no-unused-vars](http://eslint.org/docs/rules/no-unused-vars)) [#800](https://github.com/standard/standard/issues/800)
- This is a common and useful pattern in React/JSX apps!
- Relax rule: allow Flow `import type` statements ([import/no-duplicates](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-duplicates.md)) [#599](https://github.com/standard/standard/issues/599)
- These are no longer considered to be "duplicate imports"
- Relax rule: Treat `process.exit()` the same as `throw` in code path analysis ([node/process-exit-as-throw](https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/process-exit-as-throw.md)) [#699](https://github.com/standard/standard/issues/699)
- Makes certain other rules work better and give fewer false positives
- Relax rule: allow Unnecessary Labels ([no-extra-label](http://eslint.org/docs/rules/no-extra-label))
- Redundant, since "no-labels" is already enabled, which is more restrictive
## 9.0.2 - 2017-03-17
### Changed rules
- Relax rule: Allow tagged template string expressions ([no-unused-expressions](http://eslint.org/docs/rules/no-unused-expressions)) [#822](https://github.com/standard/standard/issues/822)
## 9.0.1 - 2017-03-07
### Changed rules
- Relax rule: Allow mixing basic operators without parens ([no-mixed-operators](http://eslint.org/docs/rules/no-mixed-operators)) [#816](https://github.com/standard/standard/issues/816)
- Specifically, these operators: `+`, `-`, `*`, `/`, `%`, and `**`
## 9.0.0 - 2017-02-28
It's time for a new major version of `standard`! As usual, this release contains a
bunch of awesomeness to help you keep your code in tip-top shape!
We've added several new rules designed to **catch potential programmer errors**
(i.e. bugs), as well as rules to make programmer intent **more explicit** in
certain circumstances.
This release continues our trend of tightening up rules so that, wherever possible,
there's one "right" way to do things. This design goal is intended to reduce the
time that teams and maintainers spend giving code review feedback in pull requests.
When you upgrade, consider running `standard --fix` to automatically fix some of the
errors caught by the new rules in this version.
*Note: If you use the Chai test framework, you will need to make some changes to
your tests to improve their robustness. [Read about the changes you need to make](https://github.com/standard/standard/issues/690#issuecomment-278533482).*
### New features
- Update ESLint from 3.10.x to 3.15.x
- 3 additional rules are now fixable with `standard --fix`
### New rules
*(Estimated % of affected standard users, based on test suite in parens)*
- Disallow mixing different operators without parens ([no-mixed-operators](http://eslint.org/docs/rules/no-mixed-operators)) [#566](https://github.com/standard/standard/issues/566) (5%)
- Enforce 1 newline at end of file (previously 1 or 2 were ok) ([no-multiple-empty-lines](http://eslint.org/docs/rules/no-multiple-empty-lines)) [#733](https://github.com/standard/standard/issues/733) (3%)
- Disallow Unused Expressions ([no-unused-expressions](http://eslint.org/docs/rules/no-unused-expressions)) [#690](https://github.com/standard/standard/issues/690) (3%)
- Note: this affects users of the Chai test framework. [Read about the changes you need to make](https://github.com/standard/standard/issues/690#issuecomment-278533482).
- Disallow redundant return statements ([no-useless-return](http://eslint.org/docs/rules/no-useless-return)) [#694](https://github.com/standard/standard/issues/694) (1%)
- Disallow Incorrect Early Use ([no-use-before-define](http://eslint.org/docs/rules/no-use-before-define)) [#636](https://github.com/standard/standard/issues/636) (0%)
- Enforce that Promise rejections are passed an Error object as a reason ([prefer-promise-reject-errors](http://eslint.org/docs/rules/prefer-promise-reject-errors)) [#777](https://github.com/standard/standard/issues/777) (0%)
- Enforce comparing `typeof` expressions against string literals ([valid-typeof](http://eslint.org/docs/rules/valid-typeof)) [#629](https://github.com/standard/standard/issues/629) (0%)
- Enforce spacing around * in generator functions ([generator-star-spacing](http://eslint.org/docs/rules/generator-star-spacing)) [#724](https://github.com/standard/standard/issues/724) (0%)
- Disallow Unnecessary Labels ([no-extra-label](http://eslint.org/docs/rules/no-extra-label)) [#736](https://github.com/standard/standard/issues/736) (0%)
- Disallow spacing between template tags and their literals ([template-tag-spacing](http://eslint.org/docs/rules/template-tag-spacing)) [#755](https://github.com/standard/standard/issues/775) (0%)
- Disallow padding within switch statements and classes ([padded-blocks](http://eslint.org/docs/rules/padded-blocks)) [#610](https://github.com/standard/standard/issues/610) (0%)
- Enforce that Symbols are passed a description ([symbol-description](http://eslint.org/docs/rules/symbol-description)) [#630](https://github.com/standard/standard/issues/630) (0%)
### Changed rules
- Relax rule: allow TypeScript Triple-Slash Directives ([spaced-comment](http://eslint.org/docs/rules/spaced-comment)) [#660](https://github.com/standard/standard/issues/660)
- Relax rule: allow Flow Comments ([spaced-comment](http://eslint.org/docs/rules/spaced-comment)) [#661](https://github.com/standard/standard/issues/661)
## 8.6.0 - 2016-11-22
- Update ESLint from 3.8.x to 3.10.x
- 3 additional rules are now fixable with `standard --fix`
## 8.5.0 - 2016-10-25
- Update ESLint from 3.7.x to 3.8.x
- 2 additional rules are now fixable with `standard --fix`
## 8.4.0 - 2016-10-10
- Update ESLint from 3.6.x to 3.7.x
- 5 additional rules are now fixable with `standard --fix`
- Use more conservative semver ranges [#654](https://github.com/standard/standard/issues/654)
## 8.3.0 - 2016-09-29
The last release (`8.2.0`) added ES7 support. This release (`8.3.0`) adds ES8
support ...just 3 days later!
This release should eliminate the need to specify `babel-eslint` as a custom
parser, since `standard` can now parse ES8 (i.e. ES2017) syntax out of the box.
That means `async` and `await` will just work.
- Support ES8 (i.e. ES2017) syntax.
## 8.2.0 - 2016-09-26
For many users, this release should eliminate the need to specify `babel-eslint` as
a custom parser, since `standard` can now parse ES7 (i.e. ES2016) syntax out of the
box.
- Support ES7 (i.e. ES2016) syntax.
- Update ESLint from 3.5.x to 3.6.x
- 4 additional rules are now fixable with `standard --fix`
## 8.1.0 - 2016-09-17
- Update ESLint from 3.3.x to 3.5.x
- Around 10 additional rules are now fixable with `standard --fix`
## 8.0.0 - 2016-08-23
This release contains a bunch of goodies, including new rules that catch potential
programmer errors (i.e. bugs) and enforce additional code consistency.
However, the best feature is surely the new `--fix` command line flag to
automatically fix problems. If you ever used
[`standard-format`](https://www.npmjs.com/package/standard-format)
and ran into issues with the lack of ES2015+ support, you'll be happy about
`--fix`.
`standard --fix` is built into `standard` v8.0.0 for maximum convenience, it
supports ES2015, and it's lightweight (no additional dependencies since it's part
of ESLint which powers `standard`). Lots of problems are already fixable, and more
are getting added with each ESLint release.
`standard` also outputs a message ("Run `standard --fix` to automatically fix
some problems.") when it detects problems that can be fixed automatically so you
can save time!
With `standard` v8.0.0, we are also dropping support for Node.js versions prior to
v4. Node.js 0.10 and 0.12 are in maintenance mode and will be unsupported at the
end of 2016. Node.js 4 is the current LTS version. If you are using an older
version of Node.js, we recommend upgrading to at least Node.js 4 as soon as
possible. If you are unable to upgrade to Node.js 4 or higher, then we recommend
continuing to use `standard` v7.x until you are ready to upgrade Node.js.
**Important:** We will not be updating the `standard` v7.x versions going forward.
All bug fixes and enhancements will land in `standard` v8.x.
Full changelog below. Cheers!
### New features
- Upgrade to ESLint v3 (http://eslint.org/docs/user-guide/migrating-to-3.0.0) [#565](https://github.com/standard/standard/pull/565)
- **BREAKING:** Drop support for node < 4 (this was a decision made by the ESLint team)
- Expose ESLint's `--fix` command line flag [#540](https://github.com/standard/standard/issues/540) [standard-engine/#107](https://github.com/Flet/standard-engine/issues/107)
- Lightweight, no additional dependencies, fixes dozens of rules automatically
### New rules
*(Estimated % of affected standard users, based on test suite in parens)*
- Enforce placing object properties on separate lines ([object-property-newline](http://eslint.org/docs/rules/object-property-newline)) [#524](https://github.com/standard/standard/issues/524) (2%)
- Require block comments to be balanced ([spaced-comment "balanced"](http://eslint.org/docs/rules/spaced-comment)) [#572](https://github.com/standard/standard/issues/572) (2%)
- Disallow constant expressions in conditions ([no-constant-condition](http://eslint.org/docs/rules/no-constant-condition)) [#563](https://github.com/standard/standard/issues/563) (1%)
- Disallow renaming import, export, and destructured assignments to the same name ([no-useless-rename](http://eslint.org/docs/rules/no-useless-rename)) [#537](https://github.com/standard/standard/issues/537) (0%)
- Disallow spacing between rest and spread operators and their expressions ([rest-spread-spacing](http://eslint.org/docs/rules/rest-spread-spacing)) [#567](https://github.com/standard/standard/issues/567) (0%)
- Disallow the Unicode Byte Order Mark (BOM) ([unicode-bom](http://eslint.org/docs/rules/unicode-bom)) [#538](https://github.com/standard/standard/issues/538) (0%)
- Disallow assignment to native objects/global variables ([no-global-assign](http://eslint.org/docs/rules/no-global-assign)) [#596](https://github.com/standard/standard/issues/596) (0%)
- Disallow negating the left operand of relational operators ([no-unsafe-negation](http://eslint.org/docs/rules/no-unsafe-negation)) [#595](https://github.com/standard/standard/issues/595) (0%)
- Disallow template literal placeholder syntax in regular strings ([no-template-curly-in-string](http://eslint.org/docs/rules/no-template-curly-in-string)) [#594](https://github.com/standard/standard/issues/594) (0%)
- Disallow tabs in file ([no-tabs](http://eslint.org/docs/rules/no-tabs)) [#593](https://github.com/standard/standard/issues/593) (0%)
### Changed rules
- Relax rule: Allow template literal strings (backtick strings) to avoid escaping
[#421](https://github.com/standard/standard/issues/421)
- Relax rule: Do not enforce spacing around * in generator functions (https://github.com/standard/standard/issues/564#issuecomment-234699126)
- This is a temporary workaround for `babel` users who use async generator functions.
## 7.1.2 - 2016-06-03
- Fix install errors for some users by updating eslint peer dependency
## 7.1.1 - 2016-05-26
- Add back full node 0.10, 0.12 support
## 7.1.0 - 2016-05-16
- Upgrade eslint to version ~2.10.2
## 7.0.1 - 2016-05-04
- Relax "no-duplicate-imports" rule to not include `export` so the following is allowed:
```js
import { foo } from 'bar'
export * from 'bar'
```
## 7.0.0 - 2016-05-02
### Changes
- Upgrade eslint to version ~2.9.0
- Remove "rules" configuration option [#367](https://github.com/standard/standard/issues/367) from `package.json` (Reasoning is [here](https://github.com/standard/standard/issues/399#issuecomment-180961891))
### New rules
*Estimated % of affected standard users, based on test suite*
- Require camelCase ([camelcase](http://eslint.org/docs/rules/camelcase)) [4%]
- Disallow unnecessary escape usage ([no-useless-escape](http://eslint.org/docs/rules/no-useless-escape)) [4% -- but, including many bugs]
- Disallow duplicate imports ([no-duplicate-imports](http://eslint.org/docs/rules/no-duplicate-imports)) [0%]
- Disallow unmodified conditions of loops ([no-unmodified-loop-condition](http://eslint.org/docs/2.0.0/rules/no-unmodified-loop-condition)) [0%]
- Disallow whitespace before properties ([no-whitespace-before-property](http://eslint.org/docs/2.0.0/rules/no-whitespace-before-property)) [0%]
- Disallow control flow statements in `finally` blocks ([no-unsafe-finally](http://eslint.org/docs/rules/no-unsafe-finally)) [0%]
- Disallow unnecessary computed property keys on objects ([no-useless-computed-key](http://eslint.org/docs/rules/no-useless-computed-key)) [0%]
- Validate spacing before closing bracket in JSX ([react/jsx-space-before-closing](https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-space-before-closing.md)) [0%]
### Removed rules
- Require parens in arrow function arguments ([arrow-parens](http://eslint.org/docs/rules/arrow-parens))
## 6.0.8 - 2016-03-07
- Pin eslint to version ~2.2.0
- Update eslint-plugin-react to version 4.0.0
## 6.0.7 - 2016-02-18
- Revert: Use install location of standard as eslint `cwd` (fixes [#429](https://github.com/standard/standard/issues/429))
## 6.0.6 - 2016-02-18
- Use eslint 2.1.0
- Fix: Use install location of standard as eslint `cwd` (fixes [snazzy/#8](https://github.com/standard/snazzy/issues/8))
## 6.0.5 - 2016-02-12
- Use eslint 2.0.0 stable
## 6.0.4 - 2016-02-07
- Relax rule: Validate closing bracket location in JSX ([jsx-closing-bracket-location](https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-closing-bracket-location.md))
## 6.0.3 - 2016-02-06
- Fix "Error: Cannot find module 'eslint-config-standard-jsx'" with npm 2 (node 0.10, 0.12, 4)
## 6.0.2 - 2016-02-06
- Internal change: Remove .eslintrc file, and use inline config
## 6.0.1 - 2016-02-05
- Internal change: Move .eslintrc file to root folder
## 6.0.0 - 2016-02-05
The goal of this release is to make `standard` faster to install, and simpler to use.
### Remove `standard-format` ([#340](https://github.com/standard/standard/issues/340)) ([#397](https://github.com/standard/standard/issues/397))
- Eliminates 250 packages, and cuts install time in half!
- For npm 2, install time goes from 20 secs —> 10 secs.
- For npm 3, install time goes from 24 secs —> 12 secs.
- To continue using `standard-format`, just install it separately: `npm install -g standard-format`
### React-specific linting rules are removed ([#351](https://github.com/standard/standard/issues/351)) ([#367](https://github.com/standard/standard/issues/367)) ([eslint-config-standard-react/#13](https://github.com/standard/eslint-config-standard-react/pull/13))
- JSX is still supported, and it continues to be checked for style.
- There were only a few React-specific rules, but they made it extremely difficult for users of alternatives like `virtual-dom` or `deku`, and unecessarily tied `standard` to a single library.
- JSX rules come from `eslint-config-standard-jsx`. The `eslint-config-standard-react` dependency was removed.
### New Rules
*The percentage (%) of users that rule changes will effect, based on real-world testing of the top ~400 npm packages is denoted in brackets.*
- Disallow `__dirname`/`__filename` string concatenation ([#403](https://github.com/standard/standard/issues/403)) ([no-path-concat](http://eslint.org/docs/2.0.0/rules/no-path-concat)) [5%]
- Require parens in arrow function arguments
([#309](https://github.com/standard/standard/issues/309)) ([arrow-parens](http://eslint.org/docs/2.0.0/rules/arrow-parens.html)) [5%]
- Ensure that `new Promise()` is instantiated with the parameter names
`resolve`, `reject` ([#282](https://github.com/standard/standard/issues/282)) ([promise/param-names](https://github.com/xjamundx/eslint-plugin-promise#param-names)) [1%]
- Enforce Usage of Spacing in Template Strings ([template-curly-spacing](http://eslint.org/docs/2.0.0/rules/template-curly-spacing)) [1%]
- Template strings are only allowed when necessary, i.e. template string features are being used (eslint got stricter: https://github.com/eslint/eslint/issues/5147) [1%]
- Better dead code detection after conditional statements (eslint got stricter) [1%]
- Enforce spaces around `*` in `yield * something` ([#335](https://github.com/standard/standard/issues/335)) ([yield-star-spacing](http://eslint.org/docs/2.0.0/rules/yield-star-spacing)) [0%]
- Disallow labels on loops/switch statements too (made rule stricter) ([no-labels](http://eslint.org/docs/2.0.0/rules/no-labels.html)) [0%]
- Disallow unnecessary constructor ([no-useless-constructor](http://eslint.org/docs/2.0.0/rules/no-useless-constructor)) [0%]
- Disallow empty destructuring patterns ([no-empty-pattern](http://eslint.org/docs/2.0.0/rules/no-empty-pattern)) [0%]
- Disallow Symbol Constructor ([no-new-symbol](http://eslint.org/docs/2.0.0/rules/no-new-symbol)) [0%]
- Disallow Self Assignment ([no-self-assign](http://eslint.org/docs/2.0.0/rules/no-self-assign)) [0%]
### Removed Rules
- `parseInt()` radix rule because ES5 fixes this issue ([#384](https://github.com/standard/standard/issues/384))
([radix](http://eslint.org/docs/2.0.0/rules/radix.html)) [0%]
### Expose eslint configuration via command line options and `package.json`
For power users, it might be easier to use one of these new hooks instead of forking
`standard`, though that's still encouraged, too!
- Set eslint "plugins" ([#386](https://github.com/standard/standard/issues/386))
- Set eslint "rules" ([#367](https://github.com/standard/standard/issues/367))
- Set eslint "env" ([#371](https://github.com/standard/standard/issues/371))
To set custom ESLint plugins, rules, or envs, use the command line `--plugin`, `--rules`, and `--env` flags.
In `package.json`, use the "standard" property:
```json
{
"standard": {
"plugins": [ "my-plugin" ]
}
}
```
### Upgrade to ESLint v2
- There may be slight behavior changes to existing rules. When possible, we've noted these in the "New Rules" and "Removed Rules" section.
### Improve test suite
- Rule changes can be tested against every package on npm. For sanity, this is limited to packages with at least 4 dependents. Around ~400 packages.
### Known Issues
- Using prerelease eslint version (2.0.0-rc.0). There may be breaking changes before the stable release.
- `no-return-assign` behavior changed with arrow functions (https://github.com/eslint/eslint/issues/5150)
### Relevant diffs
- standard ([v5.4.1...v6.0.0](https://github.com/standard/standard/compare/v5.4.1...v6.0.0))
- eslint-config-standard ([v4.4.0...v5.0.0](https://github.com/standard/eslint-config-standard/compare/v4.4.0...v5.0.0))
- eslint-config-standard-jsx ([v1.0.0](https://github.com/standard/eslint-config-standard-jsx/commit/47d5e248e2e078eb87619493999e3e74d4b7e70e))
- standard-engine ([v2.2.4...v3.2.1](https://github.com/Flet/standard-engine/compare/v2.2.4...v3.2.1))
## 5.4.1 - 2015-11-16
[view diff](https://github.com/standard/standard/compare/v5.4.0...v5.4.1)
### Fixed
* Fix for `standard-engine` change. Fix error tagline.
## 5.4.0 - 2015-11-16
[view diff](https://github.com/standard/standard/compare/v5.3.1...v5.4.0)
### Added
* eslint-config-standard-react@1.2.0 ([history](eslint-config-standard-react))
* Disallow duplicate JSX properties
## 5.3.1 - 2015-09-18
[view diff](https://github.com/standard/standard/compare/v5.3.0...v5.3.1)
### Changed
* eslint-plugin-react@3.4.2 ([history](eslint-plugin-react))
## 5.3.0 - 2015-09-16
[view diff](https://github.com/standard/standard/compare/v5.2.2...v5.3.0)
### Changed
* eslint-config-standard@4.4.0 ([history][eslint-config-standard])
* **New rule:** must have space after semicolon in for-loop ([commit](https://github.com/standard/eslint-config-standard/commit/6e5025eef8900f686e19b4a31836743d98323119))
* **New rule:** No default assignment with ternary operator ([commit](https://github.com/standard/eslint-config-standard/commit/0903c19ca6a8bc0c8625c41ca844ee69968bf948))
* **New rule:** Require spaces before keywords ([commit](https://github.com/standard/eslint-config-standard/commit/656ba93cda9cd4ab38e032649aafb795993d5176))
* eslint-config-standard-react@1.1.0 ([history][eslint-config-standard-react])
* eslint-plugin-react@3.4.0 ([history][eslint-plugin-react])
* eslint-plugin-standard@1.3.1 ([history][eslint-plugin-standard])
## 5.2.2
[view diff](https://github.com/standard/standard/compare/v5.2.1...v5.2.2)
### Fixed
* We have a changelog now, and you're reading it!
* Minor README update
* Removed direct dependency on `eslint` (its now moved to [standard-engine](https://github.com/flet/standard-engine))
## 5.2.1 - 2015-09-03
[view diff](https://github.com/standard/standard/compare/v5.2.0...v5.2.1)
### Changed
* eslint-config-standard@4.3.1 ([history][eslint-config-standard])
* **Revert rule**: Disallow unncessary concatenation of strings
### Fixed
* eslint-config-standard@4.3.1 ([history][eslint-config-standard])
* fix regression with ternary operator handling
## 5.2.0 - 2015-09-03
[view diff](https://github.com/standard/standard/compare/v5.1.1...v5.2.0)
### Added
* eslint-config-standard@4.3.0 ([history][eslint-config-standard])
* **New rule:** Disallow unncessary concatenation of strings
* **New rule:** Disallow duplicate name in class members
* **New rule:** enforce spaces inside of single line blocks
* **Re-add rule:** padded-blocks ([Closes #170](https://github.com/standard/standard/issues/170))
### Changed
* Bump `eslint` from 1.1.0 to 1.3.1 ([CHANGELOG][eslint])
* eslint-plugin-standard@1.3.0 ([history][eslint-plugin-standard])
* A small change to make the plugin compatible with browserify which does not affect behavior.
### Fixed
* eslint-plugin-react@3.3.1 ([CHANGELOG][eslint-plugin-react])
* Fix object rest/spread handling.
* Added white background to badge.svg to make it work with dark backgrounds ([Closes #234](https://github.com/standard/standard/issues/234))
* Minor updates to README.md
## 5.1.1 - 2015-08-28
[view diff](https://github.com/standard/standard/compare/v5.1.0...v5.1.1)
### Fixed
* Update to RULES.md to remove a missing hyperlink
* Add atom linter information to README.md
* Fixed duplicated word in the tagline message on the CLI
* Removed failing repository from tests (yoshuawuyts/initialize)
## 5.1.0 - 2015-08-14
[view diff](https://github.com/standard/standard/compare/v5.0.2...v5.1.0)
## Fixed
* eslint-config-standard@4.1.0 ([history][eslint-config-standard])
* Added rest/spread feature to `eslintrc.json` to fix [#226](https://github.com/standard/standard/issues/226) and [eslint-plugin-standard#3](https://github.com/xjamundx/eslint-plugin-standard/issues/3)
* eslint-plugin-react@3.2.2 ([CHANGELOG][eslint-plugin-react])
* Fix crash when propTypes don't have any parent
* Fix jsx-no-literals reporting errors outside JSX
### Changed
* Bump eslint from 1.0.0 to 1.2.0 ([CHANGELOG][eslint])
* Added more test repositories and disabled some that were failing
* Update bikeshedding link on README.md
## 5.0.2 - 2015-08-06
[view diff](https://github.com/standard/standard/compare/v5.0.1...v5.0.2)
### Changed
* eslint-config-standard-react@1.0.4 ([history][eslint-config-standard-react])
- **Disable Rule:** react/wrap-multilines
* Minor README updates
## 5.0.1 - 2015-08-05
[view diff](https://github.com/standard/standard/compare/v5.0.0...v5.0.1)
## 5.0.0 - 2015-08-03
[view diff](https://github.com/standard/standard/compare/v4.5.4...v5.0.0)
## 4.5.4 - 2015-07-13
[view diff](https://github.com/standard/standard/compare/v4.5.3...v4.5.4)
## 4.5.3 - 2015-07-10
[view diff](https://github.com/standard/standard/compare/v4.5.2...v4.5.3)
## 4.5.2 - 2015-07-02
[view diff](https://github.com/standard/standard/compare/v4.5.1...v4.5.2)
## 4.5.1 - 2015-06-30
[view diff](https://github.com/standard/standard/compare/v4.5.0...v4.5.1)
## 4.5.0 - 2015-06-30
[view diff](https://github.com/standard/standard/compare/v4.4.1...v4.5.0)
## 4.4.1 - 2015-06-29
[view diff](https://github.com/standard/standard/compare/v4.4.0...v4.4.1)
## 4.4.0 - 2015-06-27
[view diff](https://github.com/standard/standard/compare/v4.3.3...v4.4.0)
## 4.3.3 - 2015-06-26
[view diff](https://github.com/standard/standard/compare/v4.3.2...v4.3.3)
## 4.3.2 - 2015-06-23
[view diff](https://github.com/standard/standard/compare/v4.3.1...v4.3.2)
## 4.3.1 - 2015-06-18
[view diff](https://github.com/standard/standard/compare/v4.3.0...v4.3.1)
## 4.3.0 - 2015-06-16
[view diff](https://github.com/standard/standard/compare/v4.2.1...v4.3.0)
## 4.2.1 - 2015-06-12
[view diff](https://github.com/standard/standard/compare/v4.2.0...v4.2.1)
## 4.2.0 - 2015-06-11
[view diff](https://github.com/standard/standard/compare/v4.1.1...v4.2.0)
## 4.1.1 - 2015-06-11
[view diff](https://github.com/standard/standard/compare/v4.1.0...v4.1.1)
## 4.1.0 - 2015-06-10
[view diff](https://github.com/standard/standard/compare/v4.0.1...v4.1.0)
## 4.0.1 - 2015-06-01
[view diff](https://github.com/standard/standard/compare/v4.0.0...v4.0.1)
## 4.0.0 - 2015-05-30
[view diff](https://github.com/standard/standard/compare/v3.9.0...v4.0.0)
[eslint-config-standard-react]: https://github.com/standard/eslint-config-standard-react/commits/master
[eslint-config-standard]: https://github.com/standard/eslint-config-standard/commits/master
[eslint-plugin-react]: https://github.com/yannickcr/eslint-plugin-react/blob/master/CHANGELOG.md
[eslint-plugin-standard]: https://github.com/xjamundx/eslint-plugin-standard/commits/master
[eslint]: https://github.com/eslint/eslint/blob/master/CHANGELOG.md
================================================
FILE: CONTRIBUTING.md
================================================
# Contributing Guidelines
Contributions welcome!
**Before spending lots of time on something, ask for feedback on your idea first!**
Please search issues and pull requests before adding something new to avoid duplicating
efforts and conversations.
This project welcomes non-code contributions, too! The following types of contributions
are welcome:
- **Ideas**: participate in an issue thread or start your own to have your voice heard.
- **Writing**: contribute your expertise in an area by helping expand the included docs.
- **Copy editing**: fix typos, clarify language, and improve the quality of the docs.
- **Formatting**: help keep docs easy to read with consistent formatting.
## Code Style
[![happiness][happiness-image]][happiness-url]
This repository uses [`happiness`][happiness-url] to maintain code style and consistency,
and to avoid style arguments. `npm test` runs `happiness` automatically, so you don't have
to!
[happiness-image]: https://cdn.rawgit.com/JedWatson/happiness/master/badge.svg
[happiness-url]: https://github.com/JedWatson/happiness
## Project Governance
Individuals making significant and valuable contributions are given commit-access to the
project to contribute as they see fit. This project is more like an open wiki than a
happiness guarded open source project.
### Rules
There are a few basic ground-rules for contributors:
1. **No `--force` pushes** or modifying the Git history in any way.
2. **Non-master branches** should be used for ongoing work.
3. **Significant modifications** like API changes should be subject to a **pull request**
to solicit feedback from other contributors.
4. **Pull requests** are *encouraged* for all contributions to solicit feedback, but left to
the discretion of the contributor.
### Releases
Declaring formal releases remains the prerogative of the project maintainer.
### Changes to this arrangement
This is an experiment and feedback is welcome! This document may also be subject to pull-
requests or changes by contributors where you believe you have something valuable to add
or change.
## Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
- (a) The contribution was created in whole or in part by me and I have the right to
submit it under the open source license indicated in the file; or
- (b) The contribution is based upon previous work that, to the best of my knowledge, is
covered under an appropriate open source license and I have the right under that license
to submit that work with modifications, whether created in whole or in part by me, under
the same open source license (unless I am permitted to submit under a different
license), as indicated in the file; or
- (c) The contribution was provided directly to me by some other person who certified
(a), (b) or (c) and I have not modified it.
- (d) I understand and agree that this project and the contribution are public and that a
record of the contribution (including all personal information I submit with it,
including my sign-off) is maintained indefinitely and may be redistributed consistent
with this project or the open source license(s) involved.
================================================
FILE: LICENSE
================================================
The MIT License (MIT)
Copyright (c) Jed Watson
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
================================================
FILE: README.md
================================================
<h4 align="center">One Style You Might Like</h4>
[![travis][travis-image]][travis-url]
[![npm][npm-image]][npm-url]
[![downloads][downloads-image]][downloads-url]
[travis-image]: https://travis-ci.org/JedWatson/happiness.svg?branch=master
[travis-url]: https://travis-ci.org/JedWatson/happiness
[npm-image]: https://img.shields.io/npm/v/happiness.svg?style=flat
[npm-url]: https://npmjs.org/package/happiness
[downloads-image]: https://img.shields.io/npm/dm/happiness.svg?style=flat
[downloads-url]: https://npmjs.org/package/happiness
[Standard](https://github.com/feross/standard) customised to make [us](#maintainers) happy.
This is a fork of Standard with two changes:
- **Tabs** for indentions
- **Semicolons** always
It is called happiness, because we hope that it brings you joy, love and ends strife among your fellow developers.
**Reminder**: Happiness is not for everyone. Some people will choose to be sad, normal and some might even say "standard".
That is alright. A happy person is comfortable with being them and fine to let others be who they want to be. *"You do you"*
If the information you are looking for is not in this readme, you should take a look at the [Standard readme](https://github.com/feross/standard), it might have what you are looking for.
## Install
```bash
$ npm install happiness
```
## Usage
The easiest way to use JavaScript Happiness Style to check your code is to install it
globally as a Node command line program. To do so, simply run the following command in
your terminal (flag `-g` installs `happiness` globally on your system, omit it if you want
to install in the current working directory):
```bash
$ npm install happiness -g
```
After you've done that you should be able to use the `happiness` program. The simplest use
case would be checking the style of all JavaScript files in the current working directory:
```bash
$ happiness
Error: Use JavaScript happiness Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
You can optionally pass in a directory (or directories) using the glob pattern. Be sure to quote paths containing glob patterns so that they are expanded by standard instead of your shell:
```bash
$ happiness "src/util/**/*.js" "test/**/*.js"
```
Many people like to add happiness to their testing setup. To do this, save the packge as a dev dependency and add happiness to your package.json's test script:
```bash
$ npm install --save-dev happiness
```
```json
{
"scripts": {
"test": "happiness && mocha # <- or whatever test runner you use"
}
}
```
**Note:** by default `happiness` will look for all files matching the patterns: `**/*.js`, `**/*.jsx`.
## Badge
Use this in one of your projects? Include one of these badges in your readme to
let people know that your code is using the standard style.
[](https://github.com/JedWatson/happiness)
```markdown
[](https://github.com/JedWatson/happiness)
```
[](https://github.com/JedWatson/happiness)
```markdown
[](https://github.com/JedWatson/happiness)
```
### Text editor plugins
**Coming Soon**
## Maintainers
- [Jed Watson](https://www.github.com/JedWatson)
- [Daniel Cousens](https://www.github.com/dcousens)
- [Wes Todd](https://www.github.com/wesleytodd)
### I want to contribute to `happiness`. What packages should I know about?
- **[happiness](https://github.com/JedWatson/happiness)** - this repo
- **[standard-engine](https://github.com/flet/standard-engine)** - cli engine for arbitrary eslint rules
- **[eslint-config-happiness](https://github.com/wesleytodd/eslint-config-happiness)** - eslint rules for happiness
- **[eslint-plugin-standard](https://github.com/xjamundx/eslint-plugin-standard)** - custom eslint rules for standard (not part of eslint core)
- **[eslint](https://github.com/eslint/eslint)** - the linter that powers happiness
- **[happiness-format]()** - **Coming Soon** automatic code formatter
- **[snazzy](https://github.com/feross/snazzy)** - pretty terminal output for happiness
## License
MIT. Copyright (c) [Feross Aboukhadijeh](http://feross.org).
================================================
FILE: RULES.md
================================================
## JavaScript Happiness Style
[](https://github.com/JedWatson/happiness)
This is a TL;DR of the [happiness](https://github.com/JedWatson/happiness) JavaScript
rules.
The best way to learn about `happiness` is to just install it and give it a try on
your code.
## Rules
* **Use tabs** for indentation.
```js
function hello (name) {
console.log('hi', name)
}
```
* **Use single quotes for strings** except to avoid escaping.
```js
console.log('hello there')
$("<div class='box'>")
```
* **No unused variables.**
```js
function myFunction () {
var result = something() // ✗ avoid
}
```
* **Add a space after keywords.**
```js
if (condition) { ... } // ✓ ok
if(condition) { ... } // ✗ avoid
```
* **Add a space before a function declaration's parentheses.**
```js
function name (arg) { ... } // ✓ ok
function name(arg) { ... } // ✗ avoid
run(function () { ... }) // ✓ ok
run(function() { ... }) // ✗ avoid
```
* **Always use** `===` instead of `==`.<br>
Exception: `obj == null` is allowed to check for `null || undefined`.
```js
if (name === 'John') // ✓ ok
if (name == 'John') // ✗ avoid
```
```js
if (name !== 'John') // ✓ ok
if (name != 'John') // ✗ avoid
```
* **Infix operators** must be spaced.
```js
// ✓ ok
var x = 2
var message = 'hello, ' + name + '!'
```
```js
// ✗ avoid
var x=2
var message = 'hello, '+name+'!'
```
* **Commas should have a space** after them.
```js
// ✓ ok
var list = [1, 2, 3, 4]
function greet (name, options) { ... }
```
```js
// ✗ avoid
var list = [1,2,3,4]
function greet (name,options) { ... }
```
* **Keep else statements** on the same line as their curly braces.
```js
// ✓ ok
if (condition) {
// ...
} else {
// ...
}
```
```js
// ✗ avoid
if (condition) {
// ...
}
else {
// ...
}
```
* **For multi-line if statements,** use curly braces.
```js
// ✓ ok
if (options.quiet !== true) console.log('done')
```
```js
// ✓ ok
if (options.quiet !== true) {
console.log('done')
}
```
```js
// ✗ avoid
if (options.quiet !== true)
console.log('done')
```
* **Always handle the** `err` function parameter.
```js
// ✓ ok
run(function (err) {
if (err) throw err
window.alert('done')
})
```
```js
// ✗ avoid
run(function (err) {
window.alert('done')
})
```
* **Always prefix browser globals** with `window.`.<br>
Exceptions are: `document`, `console` and `navigator`.
```js
window.alert('hi') // ✓ ok
```
* **Multiple blank lines not allowed.**
```js
// ✓ ok
var value = 'hello world'
console.log(value)
```
```js
// ✗ avoid
var value = 'hello world'
console.log(value)
```
* **For the ternary operator** in a multi-line setting, place `?` and `:` on their own lines.
```js
// ✓ ok
var location = env.development ? 'localhost' : 'www.api.com'
// ✓ ok
var location = env.development
? 'localhost'
: 'www.api.com'
// ✗ avoid
var location = env.development ?
'localhost' :
'www.api.com'
```
* **For var declarations,** write each declaration in its own statement.
```js
// ✓ ok
var silent = true
var verbose = true
// ✗ avoid
var silent = true, verbose = true
// ✗ avoid
var silent = true,
verbose = true
```
* **Wrap conditional assignments** with additional parentheses. This makes it clear that the expression is intentionally an assignment (`=`) rather than a typo for equality (`===`).
```js
// ✓ ok
while ((m = text.match(expr))) {
// ...
}
// ✗ avoid
while (m = text.match(expr)) {
// ...
}
```
*
## Semicolons
* Always use semicolons.
```js
window.alert('hi'); // ✓ ok
window.alert('hi') // ✗ avoid
```
================================================
FILE: bin/cmd.js
================================================
#!/usr/bin/env node
if (process.version.match(/v(\d+)\./)[1] < 4) {
console.error('happiness: Node v4 or greater is required. `happiness` did not run.');
} else {
var opts = require('../options');
require('standard-engine').cli(opts);
}
================================================
FILE: bin/update-authors.sh
================================================
#!/bin/sh
# Update AUTHORS.md based on git history.
git log --reverse --format='%aN (%aE)' | perl -we '
BEGIN {
%seen = (), @authors = ();
}
while (<>) {
s/fletd01\@yahoo.com/flettre\@gmail.com/;
next if $seen{$_};
next if /(support\@greenkeeper.io)/;
next if /(nate\@ngoldman.me)/;
next if /(ahmad\@codeinchaos.com)/;
next if /(wayou )/;
$seen{$_} = push @authors, "- ", $_;
}
END {
print "# Authors\n\n";
print "#### Ordered by first contribution.\n\n";
print @authors, "\n";
print "#### Generated by bin/update-authors.sh.\n";
}
' > AUTHORS.md
================================================
FILE: docs/README-en.md
================================================
<h1 align="center">
<a href="https://standardjs.com"><img src="https://cdn.rawgit.com/standard/standard/master/sticker.svg" alt="Standard - JavaScript Style Guide" width="200"></a>
<br>
JavaScript Standard Style
<br>
<br>
</h1>
<p align="center">
<a href="https://travis-ci.org/feross/standard"><img src="https://img.shields.io/travis/standard/standard/master.svg" alt="travis"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/v/standard.svg" alt="npm version"></a>
<a href="https://www.npmjs.com/package/eslint-config-standard"><img src="https://img.shields.io/npm/dm/eslint-config-standard.svg" alt="npm downloads"></a>
<a href="https://standardjs.com"><img src="https://img.shields.io/badge/code_style-standard-brightgreen.svg" alt="Standard - JavaScript Style Guide"></a>
</p>
<h4 align="center">One JavaScript Style to Rule Them All</h4>
<p align="center">
<a href="README-en.md">English</a> •
<a href="README-esla.md">Español (Latinoamérica)</a> •
<a href="README-iteu.md">Italiano (Italian)</a> •
<a href="README-kokr.md">한국어 (Korean)</a> •
<a href="README-ptbr.md">Português (Brasil)</a> •
<a href="README-zhcn.md">简体中文 (Simplified Chinese)</a> •
<a href="README-zhtw.md">繁體中文 (Taiwanese Mandarin)</a>
</p>
<br>
## JavaScript style guide, with linter & automatic code fixer
This module saves you (and others!) time in three ways:
- **No configuration.** The easiest way to enforce consistent style in your
project. Just drop it in.
- **Automatically format code.** Just run `standard --fix` and say goodbye to
messy or inconsistent code.
- **Catch style issues & programmer errors early.** Save precious code review
time by eliminating back-and-forth between reviewer & contributor.
No decisions to make. No `.eslintrc`, `.jshintrc`, or `.jscsrc` files to manage. It just
works.
Install with:
```
npm install standard --save-dev
```
## The Rules
- **2 spaces** – for indentation
- **Single quotes for strings** – except to avoid escaping
- **No unused variables** – this one catches *tons* of bugs!
- **No semicolons** – [It's][1] [fine.][2] [Really!][3]
- **Never start a line with `(`, `[`, or `` ` ``**
- This is the **only** gotcha with omitting semicolons – *automatically checked for you!*
- [More details][4]
- **Space after keywords** `if (condition) { ... }`
- **Space after function name** `function name (arg) { ... }`
- Always use `===` instead of `==` – but `obj == null` is allowed to check `null || undefined`.
- Always handle the node.js `err` function parameter
- Always prefix browser globals with `window` – except `document` and `navigator` are okay
- Prevents accidental use of poorly-named browser globals like `open`, `length`,
`event`, and `name`.
- **And [more goodness][5]** – *give `standard` a try today!*
[1]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
[2]: http://inimino.org/~inimino/blog/javascript_semicolons
[3]: https://www.youtube.com/watch?v=gsfbh17Ax9I
[4]: RULES.md#semicolons
[5]: RULES.md#javascript-standard-style
To get a better idea, take a look at
[a sample file](https://github.com/expressjs/body-parser/blob/master/index.js) written
in JavaScript Standard Style. Or, check out one of the
[thousands of projects](https://raw.githubusercontent.com/standard/standard-packages/master/all.json)
that use `standard`!
## Table of Contents
- Quick start
- [Install](#install)
- [Usage](#usage)
- [What you might do if you're clever](#what-you-might-do-if-youre-clever)
- FAQ
- [Why should I use JavaScript Standard Style?](#why-should-i-use-javascript-standard-style)
- [Who uses JavaScript Standard Style?](#who-uses-javascript-standard-style)
- [Are there text editor plugins?](#are-there-text-editor-plugins)
- [Is there a readme badge?](#is-there-a-readme-badge)
- [I disagree with rule X, can you change it?](#i-disagree-with-rule-x-can-you-change-it)
- [But this isn't a real web standard!](#but-this-isnt-a-real-web-standard)
- [Is there an automatic formatter?](#is-there-an-automatic-formatter)
- [How do I ignore files?](#how-do-i-ignore-files)
- [How do I hide a certain warning?](#how-do-i-hide-a-certain-warning)
- [I use a library that pollutes the global namespace. How do I prevent "variable is not defined" errors?](#i-use-a-library-that-pollutes-the-global-namespace-how-do-i-prevent-variable-is-not-defined-errors)
- [How do I use experimental JavaScript (ES Next) features?](#how-do-i-use-experimental-javascript-es-next-features)
- [Can I use a JavaScript language variant, like Flow or TypeScript?](#can-i-use-a-javascript-language-variant-like-flow-or-typescript)
- [What about Mocha, Jasmine, QUnit, etc?](#what-about-mocha-jasmine-qunit-etc)
- [What about Web Workers?](#what-about-web-workers)
- [Can I check code inside of Markdown or HTML files?](#can-i-check-code-inside-of-markdown-or-html-files)
- [Is there a Git `pre-commit` hook?](#is-there-a-git-pre-commit-hook)
- [How do I make the output all colorful and *pretty*?](#how-do-i-make-the-output-all-colorful-and-pretty)
- [Is there a Node.js API?](#is-there-a-nodejs-api)
- [How do I contribute to `standard`?](#how-do-i-contribute-to-standard)
- [License](#license)
## Install
The easiest way to use JavaScript Standard Style is to install it globally as a
Node command line program. Run the following command in Terminal:
```bash
$ npm install standard --global
```
Or, you can install `standard` locally, for use in a single project:
```bash
$ npm install standard --save-dev
```
*Note: To run the preceding commands, [Node.js](http://nodejs.org) and [npm](https://npmjs.com) must be installed.*
## Usage
After you've installed `standard`, you should be able to use the `standard` program. The
simplest use case would be checking the style of all JavaScript files in the
current working directory:
```bash
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
You can optionally pass in a directory (or directories) using the glob pattern. Be
sure to quote paths containing glob patterns so that they are expanded by
`standard` instead of your shell:
```bash
$ standard "src/util/**/*.js" "test/**/*.js"
```
**Note:** by default `standard` will look for all files matching the patterns:
`**/*.js`, `**/*.jsx`.
## What you might do if you're clever
1. Add it to `package.json`
```json
{
"name": "my-cool-package",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}
```
2. Style is checked automatically when you run `npm test`
```bash
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
3. Never give style feedback on a pull request again!
## Why should I use JavaScript Standard Style?
The beauty of JavaScript Standard Style is that it's simple. No one wants to
maintain multiple hundred-line style configuration files for every module/project
they work on. Enough of this madness!
This module saves you (and others!) time in three ways:
- **No configuration.** The easiest way to enforce consistent style in your
project. Just drop it in.
- **Automatically format code.** Just run `standard --fix` and say goodbye to
messy or inconsistent code.
- **Catch style issues & programmer errors early.** Save precious code review
time by eliminating back-and-forth between reviewer & contributor.
Adopting `standard` style means ranking the importance of code clarity and
community conventions higher than personal style. This might not make sense for
100% of projects and development cultures, however open source can be a hostile
place for newbies. Setting up clear, automated contributor expectations makes a
project healthier.
## Who uses JavaScript Standard Style?
Lots of folks!
[<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/npm.png>](https://www.npmjs.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/github.png>](https://github.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/opbeat.png>](https://opbeat.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/nearform.png>](http://www.nearform.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/brave.png>](https://www.brave.com) |
|---|---|---|---|---|
| [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/zeit.png>](https://zeit.co) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/zendesk.png>](https://www.zendesk.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/mongodb.jpg>](https://www.mongodb.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/typeform.jpg>](https://www.typeform.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/gov-uk.png>](https://gds.blog.gov.uk) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/express.png>](http://expressjs.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/webtorrent.png>](https://webtorrent.io) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/ipfs.png>](https://ipfs.io) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/dat.png>](https://datproject.org) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/bitcoinjs.png>](https://bitcoinjs.org) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/atom.png>](https://atom.io) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/electron.png>](http://electron.atom.io) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/voltra.png>](https://voltra.co) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/treasuredata.png>](https://www.treasuredata.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/clevertech.png>](https://clevertech.biz) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/studynotes.jpg>](https://www.apstudynotes.org) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/optiopay.png>](https://www.optiopay.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/jaguar-landrover.png>](https://www.jlrtechincubator.com/jlrti/) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/bustle.jpg>](https://www.bustle.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/zentrick.png>](https://www.zentrick.com) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/nodesource.png>](https://nodesource.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/greenkeeper.png>](https://greenkeeper.io) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/karma.png>](https://karma-runner.github.io) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/taser.png>](https://www.taser.com) | [<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/neo4j.png>](https://www.neo4j.com) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/standard/standard/master/docs/logos/rentograph.png>](https://rentograph.com) |
|---|---|---|---|---|
In addition to companies, many community members use `standard` on packages that
are [too numerous](https://raw.githubusercontent.com/standard/standard-packages/master/all.json)
to list here.
`standard` is also the top-starred linter in GitHub's
[Clean Code Linter](https://github.com/showcases/clean-code-linters) showcase.
## Are there text editor plugins?
First, install `standard`. Then, install the appropriate plugin for your editor:
### Sublime Text
Using **[Package Control][sublime-1]**, install **[SublimeLinter][sublime-2]** and
**[SublimeLinter-contrib-standard][sublime-3]**.
For automatic formatting on save, install **[StandardFormat][sublime-4]**.
[sublime-1]: https://packagecontrol.io/
[sublime-2]: http://www.sublimelinter.com/en/latest/
[sublime-3]: https://packagecontrol.io/packages/SublimeLinter-contrib-standard
[sublime-4]: https://packagecontrol.io/packages/StandardFormat
### Atom
Install **[linter-js-standard][atom-1]**.
Alternatively, you can install **[linter-js-standard-engine][atom-4]**. Instead of
bundling a version of `standard` it will automatically use the version installed
in your current project. It will also work out of the box with other linters based
on **[standard-engine][atom-5]**.
For automatic formatting, install **[standard-formatter][atom-2]**. For snippets,
install **[standardjs-snippets][atom-3]**.
[atom-1]: https://atom.io/packages/linter-js-standard
[atom-2]: https://atom.io/packages/standard-formatter
[atom-3]: https://atom.io/packages/standardjs-snippets
[atom-4]: https://atom.io/packages/linter-js-standard-engine
[atom-5]: https://github.com/Flet/standard-engine
### Visual Studio Code
Install **[vscode-standardjs][vscode-1]**. (Includes support for automatic formatting.)
For JS snippets, install: **[vscode-standardjs-snippets][vscode-2]**. For React snippets, install **[vscode-react-standard][vscode-3]**.
[vscode-1]: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs
[vscode-2]: https://marketplace.visualstudio.com/items?itemName=capaj.vscode-standardjs-snippets
[vscode-3]: https://marketplace.visualstudio.com/items/TimonVS.ReactSnippetsStandard
### Vim
Install **[ale][vim-1]**.
For automatic formatting on save, add these lines to `.vimrc`:
```vim
autocmd bufwritepost *.js silent !standard --fix %
set autoread
```
Alternative plugins to consider include [neomake][vim-2] and [syntastic][vim-3], both of which have built-in support for `standard` (though configuration may be necessary).
[vim-1]: https://github.com/w0rp/ale
[vim-2]: https://github.com/neomake/neomake
[vim-3]: https://github.com/vim-syntastic/syntastic
### Emacs
Install **[Flycheck][emacs-1]** and check out the **[manual][emacs-2]** to learn
how to enable it in your projects.
[emacs-1]: http://www.flycheck.org
[emacs-2]: http://www.flycheck.org/en/latest/user/installation.html
### Brackets
Search the extension registry for **["Standard Code Style"][brackets-1]** and click "Install".
[brackets-1]: https://github.com/ishamf/brackets-standard/
### WebStorm (PhpStorm, IntelliJ, RubyMine, JetBrains, etc.)
WebStorm [recently announced native support](https://blog.jetbrains.com/webstorm/2017/01/webstorm-2017-1-eap-171-2272/)
for `standard` directly in the IDE.
If you still prefer to configure `standard` manually, [follow this guide][webstorm-1]. This applies to all JetBrains products, including PhpStorm, IntelliJ, RubyMine, etc.
[webstorm-1]: webstorm.md
## Is there a readme badge?
Yes! If you use `standard` in your project, you can include one of these badges in
your readme to let people know that your code is using the standard style.
[](https://github.com/standard/standard)
```md
[](https://github.com/standard/standard)
```
[](https://standardjs.com)
```md
[](https://standardjs.com)
```
## I disagree with rule X, can you change it?
No. The whole point of `standard` is to save you time by avoiding
[bikeshedding][bikeshedding] about code style. There are lots of debates online about
tabs vs. spaces, etc. that will never be resolved. These debates just distract from
getting stuff done. At the end of the day you have to 'just pick something', and
that's the whole philosophy of `standard` -- its a bunch of sensible 'just pick
something' opinions. Hopefully, users see the value in that over defending their
own opinions.
If you really want to configure hundreds of ESLint rules individually, you can
always use `eslint` directly with
[eslint-config-standard](https://github.com/standard/eslint-config-standard) to
layer your changes on top.
Pro tip: Just use `standard` and move on. There are actual real problems that you
could spend your time solving! :P
[bikeshedding]: https://www.freebsd.org/doc/en/books/faq/misc.html#bikeshed-painting
## But this isn't a real web standard!
Of course it's not! The style laid out here is not affiliated with any official web
standards groups, which is why this repo is called `standard/standard` and not
`ECMA/standard`.
The word "standard" has more meanings than just "web standard" :-) For example:
- This module helps hold our code to a high *standard of quality*.
- This module ensures that new contributors follow some basic *style standards*.
## Is there an automatic formatter?
Yes! You can use `standard --fix` to fix most issues automatically.
`standard --fix` is built into `standard` for maximum convenience. Most problems
are fixable, but some errors (like forgetting to handle errors) must be fixed
manually.
To save you time, `standard` outputs the message "`Run standard --fix to
automatically fix some problems`" when it detects problems that can be fixed
automatically.
## How do I ignore files?
Certain paths (`node_modules/`, `coverage/`, `vendor/`, `*.min.js`, `bundle.js`,
and files/folders that begin with `.` like `.git/`) are automatically ignored.
Paths in a project's root `.gitignore` file are also automatically ignored.
Sometimes you need to ignore additional folders or specific minified files. To do
that, add a `standard.ignore` property to `package.json`:
```json
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
```
## How do I hide a certain warning?
In rare cases, you'll need to break a rule and hide the warning generated by
`standard`.
JavaScript Standard Style uses [ESLint](http://eslint.org/) under-the-hood and
you can hide warnings as you normally would if you used ESLint directly.
To get verbose output (so you can find the particular rule name to ignore), run:
```bash
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)
```
Disable **all rules** on a specific line:
```js
file = 'I know what I am doing' // eslint-disable-line
```
Or, disable **only** the `"no-use-before-define"` rule:
```js
file = 'I know what I am doing' // eslint-disable-line no-use-before-define
```
Or, disable the `"no-use-before-define"` rule for **multiple lines**:
```js
/* eslint-disable no-use-before-define */
console.log('offending code goes here...')
console.log('offending code goes here...')
console.log('offending code goes here...')
/* eslint-enable no-use-before-define */
```
## I use a library that pollutes the global namespace. How do I prevent "variable is not defined" errors?
Some packages (e.g. `mocha`) put their functions (e.g. `describe`, `it`) on the
global object (poor form!). Since these functions are not defined or `require`'d
anywhere in your code, `standard` will warn that you're using a variable that is
not defined (usually, this rule is really useful for catching typos!). But we want
to disable it for these global variables.
To let `standard` (as well as humans reading your code) know that certain variables
are global in your code, add this to the top of your file:
```js
/* global myVar1, myVar2 */
```
If you have hundreds of files, it may be desirable to avoid adding comments to
every file. In this case, run:
```bash
$ standard --global myVar1 --global myVar2
```
Or, add this to `package.json`:
```json
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
```
*Note: `global` and `globals` are equivalent.*
## How do I use experimental JavaScript (ES Next) features?
`standard` supports the latest ECMAScript features, ES8 (ES2017), including
language feature proposals that are in "Stage 4" of the proposal process.
To support experimental language features, `standard` supports specifying a
custom JavaScript parser. Before using a custom parser, consider whether the added
complexity is worth it.
To use a custom parser, first install it from npm:
```bash
npm install babel-eslint --save-dev
```
Then run:
```bash
$ standard --parser babel-eslint
```
Or, add this to `package.json`:
```json
{
"standard": {
"parser": "babel-eslint"
}
}
```
If `standard` is installed globally (i.e. `npm install standard --global`), then
be sure to install `babel-eslint` globally as well, with
`npm install babel-eslint --global`.
## Can I use a JavaScript language variant, like Flow or TypeScript?
`standard` supports the latest ECMAScript features. However, Flow and TypeScript add new
syntax to the language, so they are not supported out-of-the-box.
To support JavaScript language variants, `standard` supports specifying a custom JavaScript
parser as well as an ESLint plugin to handle the changed syntax. Before using a JavaScript
language variant, consider whether the added complexity is worth it.
### Flow
To use Flow, you need to run `standard` with `babel-eslint` as the parser and
`eslint-plugin-flowtype` as a plugin.
```bash
npm install babel-eslint eslint-plugin-flowtype --save-dev
```
Then run:
```bash
$ standard --parser babel-eslint --plugin flowtype
```
Or, add this to `package.json`:
```json
{
"standard": {
"parser": "babel-eslint",
"plugins": [ "flowtype" ]
}
}
```
*Note: `plugin` and `plugins` are equivalent.*
If `standard` is installed globally (i.e. `npm install standard --global`), then
be sure to install `babel-eslint` and `eslint-plugin-flowtype` globally as well, with
`npm install babel-eslint eslint-plugin-flowtype --global`.
### TypeScript
To use TypeScript, you need to run `standard` with `typescript-eslint-parser` as the parser,
`eslint-plugin-typescript` as a plugin, and tell standard to lint `*.ts` files (since it
doesn't by default).
```bash
npm install typescript-eslint-parser eslint-plugin-typescript --save-dev
```
Then run:
```bash
$ standard --parser typescript-eslint-parser --plugin typescript *.ts
```
Or, add this to `package.json`:
```json
{
"standard": {
"parser": "typescript-eslint-parser",
"plugins": [ "typescript" ]
}
}
```
With that in `package.json`, you can run:
```bash
standard *.ts
```
If `standard` is installed globally (i.e. `npm install standard --global`), then
be sure to install `typescript-eslint-parser` and `eslint-plugin-typescript` globally as well,
with `npm install typescript-eslint-parser eslint-plugin-typescript --global`.
## What about Mocha, Jasmine, QUnit, etc?
To support mocha in test files, add this to the top of the test files:
```js
/* eslint-env mocha */
```
Or, run:
```bash
$ standard --env mocha
```
Where `mocha` can be one of `jasmine`, `qunit`, `phantomjs`, and so on. To see a
full list, check ESLint's
[specifying environments](http://eslint.org/docs/user-guide/configuring.html#specifying-environments)
documentation. For a list of what globals are available for these environments,
check the
[globals](https://github.com/sindresorhus/globals/blob/master/globals.json) npm
module.
*Note: `env` and `envs` are equivalent.*
## What about Web Workers?
Add this to the top of worker files:
```js
/* eslint-env serviceworker */
```
This lets `standard` (as well as humans reading the code) know that `self` is a
global in web worker code.
## Can I check code inside of Markdown or HTML files?
To check code inside Markdown files, use [`standard-markdown`](https://www.npmjs.com/package/standard-markdown).
Alternatively, there are ESLint plugins that can check code inside Markdown, HTML,
and many other types of language files:
To check code inside Markdown files, use an ESLint plugin:
```bash
$ npm install eslint-plugin-markdown
```
Then, to check JS that appears inside code blocks, run:
```bash
$ standard --plugin markdown '**/*.md'
```
To check code inside HTML files, use an ESLint plugin:
```bash
$ npm install eslint-plugin-html
```
Then, to check JS that appears inside `<script>` tags, run:
```bash
$ standard --plugin html '**/*.html'
```
## Is there a Git `pre-commit` hook?
Funny you should ask!
```sh
#!/bin/sh
# Ensure all javascript files staged for commit pass standard code style
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi
```
## How do I make the output all colorful and *pretty*?
The built-in output is simple and straightforward, but if you like shiny things,
install [snazzy](https://www.npmjs.com/package/snazzy):
```bash
$ npm install snazzy
```
And run:
```bash
$ standard --verbose | snazzy
```
There's also [standard-tap](https://www.npmjs.com/package/standard-tap),
[standard-json](https://www.npmjs.com/package/standard-json),
[standard-reporter](https://www.npmjs.com/package/standard-reporter), and
[standard-summary](https://www.npmjs.com/package/standard-summary).
## Is there a Node.js API?
Yes!
### `standard.lintText(text, [opts], callback)`
Lint the provided source `text`. An `opts` object may be provided:
```js
{
cwd: '', // current working directory (default: process.cwd())
filename: '', // path of the file containing the text being linted (optional, though some eslint plugins require it)
fix: false, // automatically fix problems
globals: [], // custom global variables to declare
plugins: [], // custom eslint plugins
envs: [], // custom eslint environment
parser: '' // custom js parser (e.g. babel-eslint)
}
```
Additional options may be loaded from a `package.json` if it's found for the
current working directory.
The `callback` will be called with an `Error` and `results` object.
The `results` object will contain the following properties:
```js
var results = {
results: [
{
filePath: '',
messages: [
{ ruleId: '', message: '', line: 0, column: 0 }
],
errorCount: 0,
warningCount: 0,
output: '' // fixed source code (only present with {fix: true} option)
}
],
errorCount: 0,
warningCount: 0
}
```
### `results = standard.lintTextSync(text, [opts])`
Synchronous version of `standard.lintText()`. If an error occurs, an exception is
thrown. Otherwise, a `results` object is returned.
### `standard.lintFiles(files, [opts], callback)`
Lint the provided `files` globs. An `opts` object may be provided:
```js
var opts = {
ignore: [], // file globs to ignore (has sane defaults)
cwd: '', // current working directory (default: process.cwd())
fix: false, // automatically fix problems
globals: [], // global variables to declare
plugins: [], // eslint plugins
envs: [], // eslint environment
parser: '' // js parser (e.g. babel-eslint)
}
```
The `callback` will be called with an `Error` and `results` object (same as above).
## How do I contribute to `standard`?
Contributions are welcome! Check out the [issues](https://github.com/standard/standard/issues) or the [PRs](https://github.com/standard/standard/pulls), and make your own if you want something that you don't see there.
Want to chat? Join contributors on IRC in the `#standard` channel on freenode.
Here are some important packages in the `standard` ecosystem:
- **[standard](https://github.com/standard/standard)** - this repo
- **[standard-engine](https://github.com/flet/standard-engine)** - cli engine for arbitrary eslint rules
- **[eslint-config-standard](https://github.com/standard/eslint-config-standard)** - eslint rules for standard
- **[eslint-config-standard-jsx](https://github.com/standard/eslint-config-standard-jsx)** - eslint rules for standard (JSX)
- **[eslint-plugin-standard](https://github.com/xjamundx/eslint-plugin-standard)** - custom eslint rules for standard (not part of eslint core)
- **[eslint](https://github.com/eslint/eslint)** - the linter that powers standard
- **[snazzy](https://github.com/standard/snazzy)** - pretty terminal output for standard
- **[standard-www](https://github.com/standard/standard-www)** - code for https://standardjs.com
- **[semistandard](https://github.com/Flet/semistandard)** - standard, with semicolons (if you must)
There are also many **[editor plugins](#are-there-text-editor-plugins)**, a list of
**[npm packages that use `standard`](https://github.com/standard/standard-packages)**,
and an awesome list of
**[packages in the `standard` ecosystem](https://github.com/standard/awesome-standard)**.
## License
[MIT](LICENSE). Copyright (c) [Feross Aboukhadijeh](http://feross.org).
================================================
FILE: docs/README-esla.md
================================================
<h1 align="center">
<a href="https://standardjs.com"><img src="https://cdn.rawgit.com/feross/standard/master/sticker.svg" alt="Standard - JavaScript Style Guide" width="200"></a>
<br>
JavaScript Standard Style
<br>
<br>
</h1>
<p align="center">
<a href="https://travis-ci.org/feross/standard"><img src="https://img.shields.io/travis/feross/standard/master.svg" alt="Travis"></a>
<a href="https://standardjs.com"><img src="https://img.shields.io/badge/code_style-standard-brightgreen.svg" alt="Standard - JavaScript Style Guide"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/dm/standard.svg" alt="npm downloads"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/v/standard.svg" alt="npm version"></a>
</p>
<h4 align="center">Una guía de estilos JavaScript para gobernarlos a todos</h4>
<p align="center">
<a href="README-en.md">English</a> •
<a href="README-esla.md">Español (Latinoamérica)</a> •
<a href="README-iteu.md">Italiano (Italian)</a> •
<a href="README-kokr.md">한국어 (Korean)</a> •
<a href="README-ptbr.md">Português (Brasil)</a> •
<a href="README-zhcn.md">简体中文 (Simplified Chinese)</a> •
<a href="README-zhtw.md">繁體中文 (Taiwanese Mandarin)</a>
</p>
<br>
## Guía de estilos JavaScript, con linter y corrección automática de código
Este modulo te ahorra tiempo a ti (y otros) tres maneras:
- **Sin configuración.** La manera mas fácil de usar estilos consistentes
en tu proyecto.
- **Automaticamente formatea el código.** Ejecuta `standard --fix` y dile adios a las
inconsistencias en tu código.
- **De manera temprana captura problemas de estilos y errores de programador.** Te ahorras el tiempo
de hacer revisiones de código eliminando inconsistencias entre el dueño del
repositorio y los contribuidores.
Instalar con:
```
npm install standard --save-dev
```
### Las reglas
- **2 espacios** como sangría.
- **Usar comillas simples en cadenas de texto** con la excepción de escapado de texto
- **No dejar variables sin usar** – esta captura *toneladas* de bugs!
- **Sin punto y coma** – [Está][1] [bien.][2] [¡En serio!][3]
- **Nunca empezar una línea con `(`, `[`, o `` ` ``**
- Este es el **único** problema al evitar punto y coma – *automáticamente verificado para ti!*
- [Más detalles][4]
- **Espacio después de las palabras claves** `if (condition) { ... }`
- **Espacio después del nombre de función** `function name (arg) { ... }`
- Usar siempre `===` en vez de `==` – pero `obj == null` está permitido para verificar `null || undefined`.
- Gestionar siempre el parámetro de función `err` de node.js
- Usar siempre el prefijo `window` en los globales del navegador – A excepción de `document` y `navigator` esto está bien
- Previene el uso accidental de mal-llamados globales del navegador como `open`, `length`,
`event`, y `name`.
- **Y [mucho más][5]** – *prueba `standard` hoy mismo!*
[1]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
[2]: http://inimino.org/~inimino/blog/javascript_semicolons
[3]: https://www.youtube.com/watch?v=gsfbh17Ax9I
[4]: RULES.md#semicolons
[5]: RULES.md#javascript-standard-style
Para una mejor idea, mira este
[archivo de ejemplo](https://github.com/expressjs/body-parser/blob/master/index.js) escrito
en JavaScript Standard Style. O, mira alguno de los
[miles de proyectos](https://raw.githubusercontent.com/feross/standard-packages/master/all.json)
que usan `standard`!
## Tabla de Contenido
- Inicio Rápido
- [Instalación](#instalación)
- [Uso](#uso)
- [Lo que podrías hacer si eres inteligente](#lo-que-podrías-hacer-si-eres-inteligente)
- FAQ
- [¿Por qué debería usar JavaScript Standard Style?](#por-qué-deberia-usar-javascript-standard-style)
- [¿Quién usa JavaScript Standard Style?](#quién-usa-javascript-standard-style)
- [¿Hay plugins para editores de textos?](#hay-plugins-para-editores-de-textos)
- [¿Hay alguna medalla para al readme?](#hay-alguna-medalla-para-al-readme)
- [No estoy de acuerdo con la regla X, ¿la puedo cambiar?](#no-estoy-de-acuerdo-con-la-regla-x-la-puedo-cambiar)
- [¡Pero esto no un estandar web real!](#pero-esto-no-un-estandar-web-real)
- [¿Hay algún formateador automático?](#hay-algún-formateador-automático)
- [¿Cómo hago para ignorar archivos?](#cómo-hago-para-ignorar-archivos)
- [¿Cómo oculto cierta alerta?](#cómo-oculto-cierta-alerta)
- [Yo uso una librería que contamina el espacio de nombres global. ¿Cómo puedo evitar los errores "variable is not defined"?](#yo-uso-una-librería-que-contamina-el-espacio-de-nombres-global-cómo-puedo-evitar-los-errores--variable-is-not-defined)
- [¿Puedo usar un parser JavaScript que soporte ES última-generación?](#puedo-usar-un-parser-javascript-que-soporte-es-última-generación)
- [¿Puedo usar una variación de lenguaje JavaScript, como Flow?](#puedo-usar-una-variación-de-lenguaje-javascript-como-flow)
- [¿Qué pasa con Mocha, Jasmine, QUnit y etc?](#qué-pasa-con-mocha-jasmine-qunit-y-etc)
- [¿Qué pasa con Web Workers?](#qué-pasa-con-web-workers)
- [¿Puedo verificar código dentro de archivos Markdown o HTML?](#puedo-verificar-codigo-dentro-de-archivos-markdown-o-html)
- [¿Hay algún gancho git `pre-commit`?](#hay-algún-gancho-git-pre-commit)
- [¿Cómo hago la salida (output) toda colorida y *bonita*?](#cómo-hago-la-salida-output-toda-colorida-y-bonita)
- [Node.js API](#nodejs-api)
- [¿Cómo puedo contribuir a `standard`?](#cómo-puedo-contribuir-a-standard)
- [Licencia](#licencia)
## Instalación
La manera más fácil de usar JavaScript Standard Style es instalarlo globalmente como un programa de línea de comandos de Node. Ejecuta el siguiente comando en la terminal:
```bash
$ npm install standard --global
```
O, puedes instalar `standard` localmente, para usar en un solo proyecto:
```bash
$ npm install standard --save-dev
```
*Nota: para ejecutar los comandos anteriores [Node.js](http://nodejs.org) y [npm](https://npmjs.com) deben estar instalados.*
## Uso
Una vez tenga instalado `standard`, ya deberías poder usar `standard`. Un simple caso de uso podría ser comprobar estilos de todos los archivos JavaScript en el directorio actual:
```bash
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
Opcionalmente puedes pasar un directorio (o directorios) usando el patrón glob.
Asegúrese de usar comillas en las rutas que contengan el patrón glob
para que sean expandidos por `standard` y no por el shell:
```bash
$ standard "src/util/**/*.js" "test/**/*.js"
```
**Nota:** Por defecto `standard` buscará todos los archivos que concuerden con los patrones:
`**/*.js`, `**/*.jsx`.
## Lo que podrías hacer si eres inteligente
1. Agregar esto `package.json`
```json
{
"name": "my-cool-package",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}
```
2. Los estilos son comprobados automáticamente cuando ejecutes `npm test`
```
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
3. No vuelvas a dar feedback de estilos en una PR jamás!
## ¿Por qué deberia usar JavaScript Standard Style?
La belleza de JavaScript Standard Style es qué es simple.
Nadie quiere mantener configuración de estilos en múltiples archivos
de cientos de líneas para cada módulo/proyecto en los que trabajan.
¡Se acabó esta locura!
Este módulo te ahorra tiempo a ti (y otros) en tres maneras:
- **Sin configuración.** La manera mas fácil de usar estilos consistentes
en tu proyecto.
- **Automáticamente formatea el código.** Ejecuta `standard --fix` y dile adios a las
inconsistencias en tu código.
- **Captura problemas de estilos y errores del programador muy pronto.** Te ahorras el tiempo
de hacer revisiones de código eliminando inconsistencias entre el dueño del
repositorio y los contribuidores.
Adoptar estilos `standard` significa clasificar la importancia de la claridad del código y las convenciones de la comunidad mucho más que estilo personal. Esto quizás no tenga sentido para el 100% de proyectos y culturas de desarrollo, pero los proyectos de código abierto pueden llegar a ser hostiles para los novatos. Estableciendo expectativas de contribución limpia y automatizada puede hacer el proyecto más saludable.
## ¿Quién usa JavaScript Standard Style?
Un montón de gente!
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/npm.png>](https://www.npmjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/github.png>](https://github.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/opbeat.png>](https://opbeat.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nearform.png>](http://www.nearform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/brave.png>](https://www.brave.com) |
|---|---|---|---|---|
| [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zeit.png>](https://zeit.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zendesk.png>](https://www.zendesk.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/mongodb.jpg>](https://www.mongodb.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/typeform.jpg>](https://www.typeform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/gov-uk.png>](https://gds.blog.gov.uk) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/express.png>](http://expressjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/webtorrent.png>](https://webtorrent.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/ipfs.png>](https://ipfs.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/dat.png>](https://datproject.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bitcoinjs.png>](https://bitcoinjs.org) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/atom.png>](https://atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/electron.png>](http://electron.atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/voltra.png>](https://voltra.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/treasuredata.png>](https://www.treasuredata.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/clevertech.png>](https://clevertech.biz) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/studynotes.jpg>](https://www.apstudynotes.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/optiopay.png>](https://www.optiopay.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/jaguar-landrover.png>](https://www.jlrtechincubator.com/jlrti/) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bustle.jpg>](https://www.bustle.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zentrick.png>](https://www.zentrick.com) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nodesource.png>](https://nodesource.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/greenkeeper.png>](https://greenkeeper.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/karma.png>](https://karma-runner.github.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/taser.png>](https://www.taser.com) |
|---|---|---|---|---|
Adicionalmente a compañías, muchos miembros de la comunidad usan `standard` en modulos que son
[muy numerosos](https://raw.githubusercontent.com/feross/standard-packages/master/all.json) para listar aquí.
También `standard` es el linter con más estrellas en GitHub
[Clean Code Linter](https://github.com/showcases/clean-code-linters).
## ¿Hay plugins para editores de textos?
Primero, instale `standard`. Luego, instale el plugin apropiado para su editor:
#### Sublime Text
Usando **[Package Control][sublime-1]**, instale **[SublimeLinter][sublime-2]** y
**[SublimeLinter-contrib-standard][sublime-3]**.
Para formateo automático al guardar, instale **[StandardFormat][sublime-4]**.
[sublime-1]: https://packagecontrol.io/
[sublime-2]: http://www.sublimelinter.com/en/latest/
[sublime-3]: https://packagecontrol.io/packages/SublimeLinter-contrib-standard
[sublime-4]: https://packagecontrol.io/packages/StandardFormat
#### Atom
Instale **[linter-js-standard][atom-1]**.
Para formateo automático al guardar, instale **[standard-formatter][atom-2]**. Para snippets,
instale **[standardjs-snippets][atom-3]**.
[atom-1]: https://atom.io/packages/linter-js-standard
[atom-2]: https://atom.io/packages/standard-formatter
[atom-3]: https://atom.io/packages/standardjs-snippets
#### Visual Studio Code
Instale **[vscode-standardjs][vscode-1]**. (Incluye soporte para formateo automático.)
Para snippets JS, instale: **[vscode-standardjs-snippets][vscode-2]**.
Para snippets React, instale **[vscode-react-standard][vscode-3]**.
[vscode-1]: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs
[vscode-2]: https://marketplace.visualstudio.com/items?itemName=capaj.vscode-standardjs-snippets
[vscode-3]: https://marketplace.visualstudio.com/items/TimonVS.ReactSnippetsStandard
#### Vim
instale **[Syntastic][vim-1]** y agregue esta línea a su `.vimrc`:
```vim
let g:syntastic_javascript_checkers = ['standard']
```
Para formateo automático al guardar, agregue estas dos líneas a su `.vimrc`:
```vim
autocmd bufwritepost *.js silent !standard --fix %
set autoread
```
[vim-1]: https://github.com/scrooloose/syntastic
#### Emacs
Instale **[Flycheck][emacs-1]** y revise **[manual][emacs-2]** para aprender
como habilitarlo en sus proyectos.
[emacs-1]: http://www.flycheck.org
[emacs-2]: http://www.flycheck.org/en/latest/user/installation.html
#### Brackets
Busque el registro de extension para **["Standard Code Style"][brackets-1]**.
[brackets-1]: https://github.com/ishamf/brackets-standard/
#### [WebStorm and other JetBrains products][webstorm-1]
WebStorm [recientemente anuncio soporte nativo](https://blog.jetbrains.com/webstorm/2017/01/webstorm-2017-1-eap-171-2272/) para `standard` diractemente en el IDE.
Si aun prefieres configurar `standard` manualmente [sigue esta guia](webstorm-2). Esto se aplica a todos los productos de JetBrains, incluyendo PhpStorm, IntelliJ, RubyMine y etc.
[webstorm-1]: https://www.jetbrains.com/webstorm/
[webstorm-2]: webstorm.md
## Hay alguna medalla para readme?
Si! Si estas usando `standard` en tu proyecto, puedes includir una de estas en tu readme para
hacerle saber a las personas que en tu código estas usando estilos standard.
[](https://github.com/standard/standard)
```markdown
[](https://github.com/standard/standard)
```
[](https://standardjs.com/)
```markdown
[](https://standardjs.com/)
```
## No estoy de acuerdo con la regla X, ¿la puedo cambiar?
No. El objetivo de `standard` es evitar [bikeshedding][bikeshedding] en el estilo. Existen un montón de debates online acerca de tabs vs espacios, etc. que nunca serán resueltos. Estos debates solo te distraen de hacer tu trabajo. Al final del día tienes simplemente que “usar alguno”, y esa es toda la filosofía de `standard` -- es un montón de sensibles opiniones de “usar alguno”. Con la esperanza que los usuarios vean el valor en esto más que defender sus propias opiniones.
Si realmente quieres configurar cientos de reglas individualmente, puedes usar `eslint` directamente con [eslint-config-standard](https://github.com/standard/eslint-config-standard) aplicando
cambios encima de este.
Tip: ¡Simplemente usa `standard` y ya está. Existen problemas reales
en los cuales debes usar tu tiempo! :P
[bikeshedding]: https://www.freebsd.org/doc/en/books/faq/misc.html#bikeshed-painting
## ¡Pero esto no un estandar web real!
¡Por su puesto que no lo es! Este estilo no está afiliado a ningún grupo oficial de estándar web, por eso este repositorio se llama `feross/standard` y no `ECMA/standard`.
La palabra “estándar” tiene más significados que solo “estándar web” :-) Por ejemplo:
- Este módulo ayuda a mantener el código a la más alta *calidad estándar*.
- Este módulo asegura que las nuevas contribuciones sigan los *estilos estándar* básicos.
## ¿Hay algún formateador automático?
¡Sí! Puedes usar `standard --fix` para arreglar la mayoría de problemas automáticamente.
`standard --fix` está integrado en `standard` (desde v8.0.0) para máxima conveniencia.
La mayoría de los problemas se arreglan, pero algunos errores (olvidar gestionar errores en callbacks) deben ser arreglados manualmente.
Para no perder el tiempo, `standard` emite un mensaje ("Run `standard --fix` to
automatically fix some problems.") cuando detecta errores que pueden ser arreglados automáticamente.
## ¿Cómo hago para ignorar archivos?
Ciertas rutas (`node_modules/`, `coverage/`, `vendor/`, `*.min.js`, `bundle.js`, y archivos/directorios que empiezan con `.` cómo `.git`) son ignorados automáticamente.
Las rutas del `.gitignore` del proyecto raíz son ignorados automáticamente.
A veces necesitas ignorar directorios o archivos específicos. Para hacerlo, agrega la propiedad `standard.ignore` al `package.json`:
```json
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
```
## ¿Cómo oculto cierta alerta?
En raros casos, necesitarás romper una regla y ocultar la alerta generada por `standard`.
JavaScript Standard Style usa [ESLint](http://eslint.org/) bajo la capucha y puedes ocultar las alertas como normalmente lo harías si usaras ESLint directamente.
Para obtener una salida mas especifica (así puedes encontrar el nombre de la regla a ignorar) ejecute:
```bash
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)
```
Inhabilitar **toda las reglas** en una linea especifica:
```js
file = 'I know what I am doing' // eslint-disable-line
```
O, inhabilitar **solo** la regla `"no-use-before-define"`:
```js
file = 'I know what I am doing' // eslint-disable-line no-use-before-define
```
O, inhabilitar la regla `"no-use-before-define"` para **múltiples lineas**:
```js
/* eslint-disable no-use-before-define */
console.log('offending code goes here...')
console.log('offending code goes here...')
console.log('offending code goes here...')
/* eslint-enable no-use-before-define */
```
## Yo uso una librería que contamina el espacio de nombres global. ¿Cómo puedo evitar los errores "variable is not defined"?
Algunos paquetes (ej `mocha`) colocan sus funciones (ej: `describe`, `it`) en el objeto global (¡mala manera!). Como estas funciones no están definidas o requeridas (ej: `require`) en ningún lugar del código, `standard` te alertara que están usando una variable que no está definida (usualmente, esta regla es realmente útil para detectar errores de tipeo). Pero queremos inhabilitar estas variables globales.
Para hacerle saber a `standard` (como también a los humanos que leen tu código) que ciertas variables son globales en tu código, agregar esto en la parte superior de tu código:
```js
/* global myVar1, myVar2 */
```
Si tienes cientos de archivos, seria deseable evitar agregar comentarios a cada archivo.
En este caso ejecute:
```bash
$ standard --global myVar1 --global myVar2
```
O, agregar esto a su `package.json`
```json
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
```
*Nota: `global` y `globals` son equivalentes*
## ¿Cómo puedo usar características experimentales JavaScript (ES Next)?
`standard` soporta las ultimas características de ECMAscript, ES8 (ES2017) incluyendo todas las características del lenguaje
de las propuestas que estan en "Stage 4" del proceso de propuestas.
Para soportar características experimentales del lenguaje, `standard` soporta especificar un parser JS customizado. Antes de que uses un parser customizado, considera si la complejidad agregada vale la pena.
Para usar un parser customizado, instálalo desde npm (ejemplo: `npm install babel-eslint`) y ejecuta esto:
```bash
$ standard --parser babel-eslint
```
O, agrega esto a `package.json`:
```json
{
"standard": {
"parser": "babel-eslint"
}
}
```
Si `standard` está instalado globalmente (ej: `npm install standard --global`), entonces asegúrate de instalar `babel-eslint` globalmente también com `npm install babel-eslint --global`.
## ¿Puedo usar una variación de lenguaje JavaScript, como Flow?
Antes de usar una variable del lenguaje JavaScript customizado, considera si la complejidad agregada
(y esfuerzo requerido para obtener los contribuidores alcanzarle con rapidez) vale la pena.
`standard` soporta plugins ESLint. Usa uno de estos para transformar el código a JavaScript válido antes de que `standard` lo vea. Para usar un parser customizado, instálalo desde
npm (example: `npm install eslint-plugin-flowtype`) y ejecuta:
```bash
$ standard --plugin flowtype
```
O, agrega esto a `package.json`:
```json
{
"standard": {
"parser": "babel-eslint",
"plugins": [
"flowtype"
]
}
}
```
Si `standard` está instalado globalmente (ej: `npm install standard --global`), entonces asegúrate de instalar `eslint-plugin-flowtype` globalmente también, con `npm install eslint-plugin-flowtype -g`.
*Nota: `plugin` y `plugins` son equivalentes*
## ¿Qué pasa con Mocha, Jasmine, QUnit y etc?
Para soportar mocha en tus archivos de tests, agrega esto al inicio de los archivos:
```js
/* eslint-env mocha */
```
O, ejecuta:
```bash
$ standard --env mocha
```
Donde `mocha` puede ser `jasmine`, `qunit`, `phantomjs`, y así sucesivamente.
Para ver la lista completa, comprueba la documentación de ESLint [especificando entornos](http://eslint.org/docs/user-guide/configuring.html#specifying-environments).
Para una lista de qué variables globales están disponibles en estos entornos comprueba el módulo npm [globals](https://github.com/sindresorhus/globals/blob/master/globals.json).
*Nota: `env` y `envs` son equivalentes*
## ¿Qué pasa con Web Workers?
Agrega esto al inicio de tus archivos:
```js
/* eslint-env serviceworker */
```
Esto le hará saber a` standard` (como también humanos que leen tu código) que
`self` es una variable global en el codigo web worker.
## ¿Puedo verificar código dentro de archivos Markdown o HTML?
Para verificar código dentro de archivos Markdown use [`standard-markdown`](https://www.npmjs.com/package/standard-markdown).
Alternativamente, hay plugins ESLint para verificar código de Markdown,
HTML y otros tipos de lenguajes:
Para verificar código dentro de archivos Markdown, usa el plugin ESLint:
```bash
$ npm install eslint-plugin-markdown
```
Luego para verificar código JS que aparece dentro de bloques código, ejecute:
```bash
$ standard --plugin markdown '**/*.md'
```
Para verificar código dentro de archivos HTML, use el plugin ESLint:
```bash
$ npm install eslint-plugin-html
```
Luego para verificar el código que aparece dentro de etiquetas `<script>`, ejecute:
```bash
$ standard --plugin html '**/*.html'
```
## ¿Hay algún gancho git `pre-commit`?
¡Qué bien que lo preguntes!
```sh
#!/bin/sh
# Asegura que todos los archivos javascript especificados
# para hacer commit pasan los estandares de estilo de código
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi
```
## ¿Cómo hago la salida (output) toda colorida y *bonita*?
La salida integrada es simple y directa, pero si te gustan las cosas brillantes, puedes instalar [snazzy](https://www.npmjs.com/package/snazzy):
```bash
$ npm install snazzy
```
y ejecutar:
```bash
$ standard --verbose | snazzy
```
También tienes [standard-tap](https://www.npmjs.com/package/standard-tap),
[standard-json](https://www.npmjs.com/package/standard-json),
[standard-reporter](https://www.npmjs.com/package/standard-reporter), y
[standard-summary](https://www.npmjs.com/package/standard-summary).
## Node.js API
### `standard.lintText(text, [opts], callback)`
Hacer Lint al texto fuente previsto para hacer cumplir JavaScript Standard Style.
Un objeto `opts` puede ser proporcionado:
```js
var opts = {
fix: false, // automatically fix problems
globals: [], // global variables to declare
plugins: [], // eslint plugins
envs: [], // eslint environment
parser: '' // js parser (e.g. babel-eslint)
}
```
El `callback` será llamado con un objeto de `Error` y `results`:
```js
var results = {
results: [
{
filePath: '',
messages: [
{ ruleId: '', message: '', line: 0, column: 0 }
],
errorCount: 0,
warningCount: 0
}
],
errorCount: 0,
warningCount: 0
}
```
### `standard.lintFiles(files, [opts], callback)`
Hacer Lint a los archivos que concuerden con el patrón globs.
Un objeto `opts` puede ser proporcionado:
```js
var opts = {
ignore: [], // file globs to ignore (has sane defaults)
cwd: '', // current working directory (default: process.cwd())
fix: false, // automatically fix problems
globals: [], // global variables to declare
plugins: [], // eslint plugins
envs: [], // eslint environment
parser: '' // js parser (e.g. babel-eslint)
}
```
El `callback` será llamado con un objeto de `Error` y `results`: (igual al de arriba).
## ¿Cómo puedo contribuir a `standard`?
Las contribuciones son bienvenidas! Comprueba los [issues](https://github.com/standard/standard/issues) o [PRs](https://github.com/standard/standard/pulls), o haz el tuyo propio si quieres algo que nos ves allí
Unete a nosotros `#standard` en freenode.
- **[standard](https://github.com/standard/standard)** - este repositorio
- **[standard-engine](https://github.com/flet/standard-engine)** - motor arbitrario cli de relgas eslint
- **[eslint-config-standard](https://github.com/standard/eslint-config-standard)** - reglas eslint para standard
- **[eslint-config-standard-jsx](https://github.com/standard/eslint-config-standard-jsx)** - reglas eslint para standard (JSX)
- **[eslint-plugin-standard](https://github.com/xjamundx/eslint-plugin-standard)** - reglas customizadas eslint para standard (no es parte del nucleo eslint)
- **[eslint](https://github.com/eslint/eslint)** - linter que da poder a standard
- **[snazzy](https://github.com/standard/snazzy)** - salida colorida o *bonita* en el terminal para standard
- **[standard-www](https://github.com/standard/standard-www)** - codigo de https://standardjs.com
- **[semistandard](https://github.com/Flet/semistandard)** - standard, con punto y coma (sí es necesario)
También hay un montón **[plugins editores de textos](#plugins-editores-de-textos)**, una lista de
**[paquetes npm que usan `standard`](https://github.com/standard/standard-packages)**,
y una impresionante lista de
**[paquetes en el ecosistema `standard`](https://github.com/standard/awesome-standard)**.
## Licencia
[MIT](LICENSE). Copyright (c) [Feross Aboukhadijeh](http://feross.org).
================================================
FILE: docs/README-iteu.md
================================================
<h1 align="center">
<a href="https://standardjs.com"><img src="https://cdn.rawgit.com/feross/standard/master/sticker.svg" alt="Standard - JavaScript Style Guide" width="200"></a>
<br>
JavaScript Standard Style
<br>
<br>
</h1>
<p align="center">
<a href="https://travis-ci.org/feross/standard"><img src="https://img.shields.io/travis/feross/standard/master.svg" alt="travis"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/v/standard.svg" alt="npm version"></a>
<a href="https://www.npmjs.com/package/eslint-config-standard"><img src="https://img.shields.io/npm/dm/eslint-config-standard.svg" alt="npm downloads"></a>
<a href="https://standardjs.com"><img src="https://img.shields.io/badge/code_style-standard-brightgreen.svg" alt="Standard - JavaScript Style Guide"></a>
</p>
<h4 align="center">Un solo Stile JavaScript per domarli tutti</h4>
<p align="center">
<a href="README-en.md">English</a> •
<a href="README-esla.md">Español (Latinoamérica)</a> •
<a href="README-iteu.md">Italiano (Italian)</a> •
<a href="README-kokr.md">한국어 (Korean)</a> •
<a href="README-ptbr.md">Português (Brasil)</a> •
<a href="README-zhcn.md">简体中文 (Simplified Chinese)</a> •
<a href="README-zhtw.md">繁體中文 (Taiwanese Mandarin)</a>
</p>
<br>
## Guida allo stile JavaScript, con linter e autocorrettore del codice
Questo modulo fa risparmiare tempo a te (e altri!) in tre modi:
- **Nessuna configurazione** La maniera più veloce per rafforzare un stile consistente
nel tuo progetto. Basta solo installarlo.
- **Codice automatica formattato** Esegui solamente `standard --fix` e puoi dire addio
a tutto quel codice inconsistente e disordinato.
- **Trova errori di stile ed errori di programmazione** Risparmia tempo durante i controlli
del codice senza fare avanti e indietro tra i vari collaboratori
Non ci sono decisioni da prendere. Nessun `.eslintrc`, `jshintrc`, o `.jscsrc` file da mantenere.
Funziona e basta.
Installa con:
```
npm install standard --save-dev
```
## Le regole
- **2 spazi** per indentare
- **Singolo apostrofo per le stringhe** - eccetto per evitare l'escaping
- **Nessuna variabile non utilizzata** - questo cattura *molti* errori!
- **Nessun punto e virgola** [È][1] [OK.][2] [Davvero!][3]
- **Mai iniziare una linea di codice con `(`, `[`, or `` ` ``**
- Questa è l'unica scappatoia per omettere i punto e virgola *automaticamente controllato per te!*
- [Maggiori dettagli][4]
- **Spazio dopo le parole chiave** `if (condition) { ... }`
- **Spazio dopo il nome di una funzione** `function name (arg) { ... }`
- Usare sempre `===` invece di `==` ma `obj == null` è consentito per controllare `null || undefined`.
- Sempre gestire l'errore node.js `err` dato come parametro da una funzione
- Usare sempre il prefisso per le variabili globali del browser con `window` - eccezione per `document` e `navigator`
- Previene l'uso di nomi riservati per le variabili globali del browser, come ad esempio `open`, `length`,
`event`, e `name`.
- **E [ancora di più][5]** *prova `standard`, oggi!*
[1]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
[2]: http://inimino.org/~inimino/blog/javascript_semicolons
[3]: https://www.youtube.com/watch?v=gsfbh17Ax9I
[4]: RULES.md#semicolons
[5]: RULES.md#javascript-standard-style
Per avere le idee più chiari, da un'occhiata al
[file d'esempio](https://github.com/expressjs/body-parser/blob/master/index.js) scritto
usando JavaScript Standard Style. O guarda i
[millemila progetti](https://raw.githubusercontent.com/feross/standard-packages/master/all.json)
che usano `standard`!
## Tabella dei contenuti
- Settaggio veloce
- [Installazione](#installazione)
- [Utilizzo](#utilizzo)
- [Cosa vorresti fare se sei intelligente](#cosa-vorresti-fare-sei-intelligente)
- FAQ
- [Perchè dovrei usare JavaScript Standard Style?](#perche-dovrei-usare-javascript-standard-style)
- [Chi usa JavaScript Standard Style?](#chi-usa-javascript-standard-style)
- [Ci sono dei plugin per gli editor di testo?](#ci-sono-dei-plugin-per-gli-editor-di-testo)
- [Esiste un banner?](#esiste-un-banner)
- [Non sono d'accordo con la regola X, posso cambiarla?](#non-sono-daccordo-con-la-regola-x-posso-cambiarla)
- [Ma questo non è un vero web standard!](#bma-questo-non-e-un-vero-web-standard)
- [Esiste un formattatore automatico?](#esiste-un-formattatore-automatico)
- [Come posso ignorare dei file?](#come-posso-ignorare-dei-file)
- [Come posso nascondere un determinato warning?](#come-posso-nascondere-un-determinato-warning)
- [Utilizzo una libreria che inquina il namespace globale. Come posso prevenire errori del tipo "variable is not defined"?](#tilizzo-una-libreria-che-inquina-il-namespace-globale-come-posso-prevenire-errori-del-tipo-variable-is-not-defined)
- [Come posso usare funzionalità sperimentali di JavaScript (ES Next)?](#ome-posso-usare-funzionalita-sperimentali-di-javascript-es-next)
- [Posso usare varianti di JavaScript come Flow?](#posso-usare-varianti-di-javascript-come-flow)
- [Riguardo Mocha, Jasmine, QUnit, ecc.?](#riguardo-mocha-jasmine-qunit-ecc)
- [Riguardo Web Workers?](#riguardo-web-workers)
- [Posso controllare codice dentro file di tipo Markdown o HTML?](#osso-controllare-codice-dentro-file-di-tipo-markdown-o-html)
- [C'è un hook Git per `pre-commit`?](#ce-un-hook-git-per-pre-commit)
- [Come posso mostrare l'output del mio codice colorato e *carino*?](#ome-posso-mostrare-loutput-del-mio-codice-colorato-e-carino)
- [C'è un API per Node.js?](#ce-un-api-per-nodejs)
- [Come posso contribuire a `standard`?](#come-posso-contribuire-per-standard)
- [Licenza](#licenza)
## Installazione
La maniera più semplice per usare JavaScript Standard Style è quella di installarlo globalmente usando la linea di comando di Node. Esegui il seguente comando da terminale:
```bash
$ npm install standard --global
```
O, se vuoi installare `standard` localmente, da utilizzare in un singolo progetto:
```bash
$ npm install standard --save-dev
```
*Nota: per eseguire i precedenti comandi, [Node.js](http://nodejs.org) and [npm](https://npmjs.com) deve essere già installato
sulla propria macchina.*
## Utilizzo
Dopo aver installato `standard`, dovresti essere in grado di utilizzarlo come programma. Lo scenario d'uso più comune sarebbe quello di
controllare lo stile di tutti i tuoi file JavaScript attualmente presenti nel tuo progetto:
```bash
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
Puoi opzionalmente passare una cartella (o cartelle) usando il pattern globale. Assicurati di mettere
tra virgolette i percorsi contenenti il pattern globale, così verranno espansi da `standard` invece che dalla tua shell:
```bash
$ standard "src/util/**/*.js" "test/**/*.js"
```
**Nota**: di default `standard` controllerà tutti i file che corrispondono al seguente pattern:
`**/*.js`, `**/*.jsx`.
## Cosa vorresti fare se sei intelligente
1. Aggiungerlo al tuo `package.json`
```json
{
"name": "my-cool-package",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}
2. Lo stile del tuo codice verrà controllato automaticamente quando esegui `npm test`
```bash
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
3. Mai più suggerimenti riguardo lo stile del tuo codice durante le pull request!
## Perchè dovrei usare JavaScript Standard Style?
La bellezza di JavaScript Standard Style è la sua semplicità. Nessuno vuole mantenere migliaia di linee di codice di configurazione per lo stile del codice per ogni progetto/module sul quale si lavora. Basta impazzire!
Questo modulo fa risparmiare tempo a te (e altri!) in tre modi:
- **Nessuna configurazione** La maniera più veloce per rafforzare un stile consistente
nel tuo progetto. Basta solo installarlo.
- **Codice automatica formattato** Esegui solamente `standard --fix` e puoi dire addio
a tutto quel codice inconsistente e disordinato.
- **Trova errori di stile ed errori di programmazione** Risparmia tempo durante i controlli
del codice senza fare avanti e indietro tra i vari collaboratori
Adottare lo stile `standard` signica dare più importanza alla chiarezza del codice e convenzioni della comunità rispetto che allo stile personale. Questo non potrebbe avere senso per il 100% dei progetti e modi di sviluppo, ma l'open source può essere un posto ostile per i nuovi arrivati. Decidere le aspettative dei collaboratori in modo chiaro e automatizzato rendere un progetto più sano.
## Chi usa JavaScript Standard Style?
Un sacco di gente!
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/npm.png>](https://www.npmjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/github.png>](https://github.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/opbeat.png>](https://opbeat.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nearform.png>](http://www.nearform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/brave.png>](https://www.brave.com) |
|---|---|---|---|---|
| [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zeit.png>](https://zeit.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zendesk.png>](https://www.zendesk.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/mongodb.jpg>](https://www.mongodb.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/typeform.jpg>](https://www.typeform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/gov-uk.png>](https://gds.blog.gov.uk) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/express.png>](http://expressjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/webtorrent.png>](https://webtorrent.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/ipfs.png>](https://ipfs.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/dat.png>](https://datproject.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bitcoinjs.png>](https://bitcoinjs.org) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/atom.png>](https://atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/electron.png>](http://electron.atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/voltra.png>](https://voltra.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/treasuredata.png>](https://www.treasuredata.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/clevertech.png>](https://clevertech.biz) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/studynotes.jpg>](https://www.apstudynotes.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/optiopay.png>](https://www.optiopay.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/jaguar-landrover.png>](https://www.jlrtechincubator.com/jlrti/) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bustle.jpg>](https://www.bustle.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zentrick.png>](https://www.zentrick.com) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nodesource.png>](https://nodesource.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/greenkeeper.png>](https://greenkeeper.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/karma.png>](https://karma-runner.github.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/taser.png>](https://www.taser.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/neo4j.png>](https://www.neo4j.com) |
|---|---|---|---|---|
Oltre alle aziende, anche molti membri della comunità usano `standard` su pacchetti che sono [troppo numerosi](https://raw.githubusercontent.com/feross/standard-packages/master/all.json) da mostrare qui.
`standard` è inoltre il miglior linter favorito dal caso d'uso dalla GitHub [Clean Code Linter](https://github.com/showcases/clean-code-linters).
## Ci sono dei plugin per gli editor di testo?
Primo, installa `standard`. Dopo di che installa il plugin più appropriato per il tuo editor:
### Sublime Text
Usano **[Package Control][sublime-1]**, installa **[SublimeLinter][sublime-2]** e
**[SublimeLinter-contrib-standard][sublime-3]**.
Per la formattazione automatica durante il salvataggio, installa **[StandardFormat][sublime-4]**.
[sublime-1]: https://packagecontrol.io/
[sublime-2]: http://www.sublimelinter.com/en/latest/
[sublime-3]: https://packagecontrol.io/packages/SublimeLinter-contrib-standard
[sublime-4]: https://packagecontrol.io/packages/StandardFormat
### Atom
Installa **[linter-js-standard][atom-1]**.
In alternativa, puoi installare **[linter-js-standard-engine][atom-4]**. Invece di installare la sua versione di `standard`, userà automaticamente la version installata all'interno del tuo progetto. Funzionerà automaticamente anche con altri linters che si basano su **[standard-engine][atom-5]**.
Per la formattazione automatica, installa **[standard-formatter][atom-2]**. Per aiuti (snippets),
installa **[standardjs-snippets][atom-3]**.
[atom-1]: https://atom.io/packages/linter-js-standard
[atom-2]: https://atom.io/packages/standard-formatter
[atom-3]: https://atom.io/packages/standardjs-snippets
[atom-4]: https://atom.io/packages/linter-js-standard-engine
[atom-5]: https://github.com/Flet/standard-engine
### Visual Studio Code
Installa **[vscode-standardjs][vscode-1]**. (Include supporto per la formattazione automatica.)
Per JS snippets, installa: **[vscode-standardjs-snippets][vscode-2]**. Per ReactJS snippets, installa **[vscode-react-standard][vscode-3]**.
[vscode-1]: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs
[vscode-2]: https://marketplace.visualstudio.com/items?itemName=capaj.vscode-standardjs-snippets
[vscode-3]: https://marketplace.visualstudio.com/items/TimonVS.ReactSnippetsStandard
### Vim
Installa **[ale][vim-1]**.
Per la formattazione automatica al salvataggio, aggiungi quelle linee a `.vimrc`:
```vim
autocmd bufwritepost *.js silent !standard --fix %
set autoread
```
Pacchetti alternativi che possono essere inclusi sono [neomake][vim-2] e [syntastic][vim-3], entrambi hanno all'interno il supporto per `standard` (configurazione potrebbe essere necessaria).
[vim-1]: https://github.com/w0rp/ale
[vim-2]: https://github.com/neomake/neomake
[vim-3]: https://github.com/vim-syntastic/syntastic
### Emacs
Installa **[Flycheck][emacs-1]** e controlla **[manual][emacs-2]** per imparare come abilitarlo all'interno del tuo progetto.
[emacs-1]: http://www.flycheck.org
[emacs-2]: http://www.flycheck.org/en/latest/user/installation.html
### Brackets
Cerca l'estenzione di registro per **["Standard Code Style"][brackets-1]** and clicca "Install".
[brackets-1]: https://github.com/ishamf/brackets-standard/
### WebStorm (PhpStorm, IntelliJ, RubyMine, JetBrains, etc.)
WebStorm [ha annunciato recentemente supporto nativo](https://blog.jetbrains.com/webstorm/2017/01/webstorm-2017-1-eap-171-2272/)
per `standard` direttamente nell'IDE.
Se preferisci configurare `standard` manualmente, [segui questa guida][webstorm-1]. Questa guida va bene per tutti i prodotti JetBrains, come ad esempio PhpStorm, IntelliJ, RubyMine, ecc.
If you still prefer to configure `standard` manually, [follow this guide][webstorm-1]. This applies to all JetBrains products, including PhpStorm, IntelliJ, RubyMine, etc.
[webstorm-1]: docs/webstorm.md
## Esiste un banner?
Sì! Se usi `standard` nel tuo progetto, puoi includere uno di questi banner nel tuo readme file per far sapere alle persone the il tuo codice usa JavaScript Standard Style.
[](https://github.com/standard/standard)
```md
[](https://github.com/standard/standard)
```
[](https://standardjs.com)
```md
[](https://standardjs.com)
```
## Non sono d'accordo con la regola X, posso cambiarla?
No. Il punto essenziale di `standard` è di aiutarti a salvare tempo evitando [bikeshedding][bikeshedding] (discussioni su piccole cose mentre la cosa più importante non è terminata) sullo stile del codice. Ci sono un sacco di grandi discussioni riguardo tabs vs. spazi, ecc. che non saranno mai risolte. Queste discussioni semplicemente fanno perdere tempo. Alla fine, quello che ti rimane da fare è solamente 'scegli qualcosa', è questa la filosofia di `standard` - un sensato insieme di opinioni di 'scegli qualcosa'. Con un po' di fiducia, gli utenti vedranno il valore in ciò invece di difendere il proprie opinioni personali.
Se davvero vuoi configurare centinaia di regole ESLint individualmente, puoi sempre usare `eslint` direttamente con [eslint-config-standard](https://github.com/standard/eslint-config-standard) in modo da usare le tue regole.
Suggerimento: usa semplicemente `standard` e vai avanti. Ci sono problemi più reali dove puoi spendere il tuo prezioso tempo! :P
[bikeshedding]: https://www.freebsd.org/doc/en/books/faq/misc.html#bikeshed-painting
## Ma questo non è un vero web standard!
Ovvio che no! Lo stile presentato qui non è affiliato con nessuno degli gruppi standard web, ecco perchè questo repository si chiama `feross/standard` e non `ECMA/standard`.
La parola "standard" signica più di un "web standard" :-) Per esempio:
- Questo module aiuta a tenere il codice vicino ad uno *standard di qualità*
- Questo module assicura che nuovi contribtori seguano gli *stili standard*
## Esiste un formattatore automatico?
Sì! Puoi usare `standard --fix` per correggere la maggior parte degli errori automaticamente.
`standard --fix` è direttamente offerto da `standard` per offrire il massimo della convenienza. La maggior parte degli errori possono essere corretti, ma alcuni errori (come ad esempio dimenticarsi di gestire gli errori) devono essere corretti a mano.
Per risparmiare tempo, l'ouput di `standard` è un messaggio del tipo "`Run standard --fix to automatically fix some problems`" quando rileva problemi che possono essere risolti automaticamente.
## Come posso ignorare dei file?
Alcuni percorsi (`node_modules/`, `coverage/`, `vendor/`, `*.min.js`, `bundle.js`,
e file/cartelle the iniziano con `.` come `.git/`) sono automaticamente ignorati.
Anche i percorsi specificati all'interno del file `.gitignore` sono automaticamente ignorati.
Alle volte hai bisogno di ignorare file minificati o cartelle in più. Per farlo, aggiungi la proprietà `standard.ignore` all'interno di `package.json`:
```json
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
```
## Come posso nascondere un determinato avviso?
In rari casi, avarai la necessità di rompere le regole e nascondere l'avviso generato da `standard`.
JavaScript Standard Style usa [ESLint](http://eslint.org/) al di sotto del suo engine e puoi nascondere gli avvisi come se lo facessi direttamente per ESLint.
Per avere un output più verboso (e così avere accesso al nome della regola), esegui:
```bash
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)
```
Disabilita **tutte le regole** in una specifica riga:
```js
file = 'So cosa sto facendo' // eslint-disable-line
```
O, disabilita **solo** la regola `"no-use-before-define"`:
```js
file = 'So cosa sto facendo' // eslint-disable-line no-use-before-define
```
O, disabilita la regola `"no-use-before-define"` per **più righe**:
```js
/* eslint-disable no-use-before-define */
console.log('offending code goes here...')
console.log('offending code goes here...')
console.log('offending code goes here...')
/* eslint-enable no-use-before-define */
```
## Utilizzo una libreria che inquina il namespace globale. Come posso prevenire errori del tipo "variable is not defined"?
Alcune librerie (es. `mocha`) mettono le loro funzionalità (es. `describe`, `it`) nell'oggetto globale. Considerato il fatto che queste funzioni definite o non sono importate usando il `require` all'interno del tuo codice, `standard` vi avviserà che stai per utilizzare una variabile che non è non stata definita. (di solito questa regola è utile per trovare errori di scrittura!). Ma vogliamo disabilitarlo per questi oggetti globali.
Per permettere a `standard` (anche per quando qualcun altro leggerà il tuo codice) di far sapere che certe variabili sono globali all'interno del tuo codice, aggiungi questo all'inizio del tuo file:
```js
/* global myVar1, myVar2 */
```
Se hai centiaia di file, sarebbe più conveniente evitare di aggiungere commenti su ogni file. In questo caso, esegui:
```bash
$ standard --global myVar1 --global myVar2
```
Oppure aggiungi questo al tuo `package.json`:
```json
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
```
*Nota: `global` e `globals` sono equivalenti.*
## Come posso usare funzionalità sperimentali di JavaScript (ES Next)?
`standard` supporta le ultime funzionalità di ECMAScript, ES8 (ES2017), includendo anche funzionalità proposte (proposals) che si trovano allo "Stage 4" del processo decisionale.
Per supportare funzionalità sperimentali, `standard` permette di configurare uno perser JavaScript su misura (custom). Prima di aggiungere un diverso parser, considera se la complessità che si andrà ad aggiungere ne valga la pena.
Per usare un parser su misura (custom), installalo da npm (esempio: `npm install --save-dev babel-eslint`) ed esegui:
```bash
$ standard --parser babel-eslint
```
Oppure aggiungi questo al tuo `package.json`:
```json
{
"standard": {
"parser": "babel-eslint"
}
}
```
Se `standard` è installato globalmente (i.e. `npm install standard --global`), allora assicurati che anche `babel-eslint` sia installato globalmente, con
`npm install babel-eslint --global`.
## Posso usare varianti di JavaScript come Flow?
Prima di usare una variante di JavaScript, considera se l'aggiunta di complessità (ed energie richieste per permettere i nuovi sviluppatori di essere pronti) ne valga la pena.
`standard` supporta plugins ESLint. Utilizza uno di questi plugins per trasformare il codice in valido JavaScript prima che `standard` lo veda. Per usare un parser ad-hoc, installalo tramite npm ed esegui:
```bash
$ standard --plugin PLUGIN_NAME
```
Oppure aggiungi questo al tuo `package.json`:
```json
{
"standard": {
"plugins": [ "PLUGIN_NAME" ]
}
}
```
Per usare Flow, hai bisogno di usare `babel-eslint` come parser, Quindi, esegui `npm install eslint-plugin-flowtype babel-eslint` e dopo di che esegui:
```bash
$ standard --plugin flowtype --parser babel-eslint
```
Oppure aggiungi questo al tuo `package.json`:
```json
{
"standard": {
"plugins": [ "flowtype" ],
"parser": "babel-eslint"
}
}
```
Se `standard` è installato globalmente (es. `npm install standard --global`), allora assicurati che anche `eslint-plugin-flowtype` sia installato globalmente, con
`npm install eslint-plugin-flowtype --global`.
*Nota: `plugin` e `plugins` sono equivalenti.*
## Riguardo Mocha, Jasmine, QUnit, ecc.?
Per supportare mocha nei tuoi file di test, aggiungi questo all'inizio dei tuoi file:
```js
/* eslint-env mocha */
```
O esegui:
```bash
$ standard --env mocha
```
Dove `mocha` può essere anche `jasmine`, `qunit`, `phantomjs`, e così via. Per vedere l'intera lista, controlla la documentazione di ESlint su come
[specificare degli ambienti](http://eslint.org/docs/user-guide/configuring.html#specifying-environments). Per una lista completa degli oggetti globali a disposizione degli ambienti, controlla la sezione
[globals](https://github.com/sindresorhus/globals/blob/master/globals.json) del modulo npm.
*Nota: `env` e `envs` sono equivalenti.*
## Riguardo Web Workers?
Aggiungi questo all'inizio del tuo file:
```js
/* eslint-env serviceworker */
```
Per permettere a `standard` (anche per quando qualcun altro leggerà il tuo codice) di far sapere
che `self` è un oggetto globale all'interno del codice del tuo web worker.
## Posso controllare codice dentro file di tipo Markdown o HTML?
Per controllare codice all'interno di file di tipo Markdown, usa [`standard-markdown`](https://www.npmjs.com/package/standard-markdown).
In alternativa, ci sono diversi plugin di ESLint per controllare il codice all'interno di Markdown, HTML e altri tipi di file:
Per controllare il codice dentro un file Markdown, usa il plugin ESLint:
```bash
$ npm install eslint-plugin-markdown
```
Dopodiche, per controllare codice JavaScript che compare dentro un blocco di codice, esegui:
```bash
$ standard --plugin markdown '**/*.md'
```
Per controllare codice dentro file HTML, usa il plugin ESLint:
```bash
$ npm install eslint-plugin-html
```
Dopodiche, per controllare codice JavaScript che compare dentro i tag `<script>`, esegui:
```bash
$ standard --plugin html '**/*.html'
```
## C'è un hook Git per `pre-commit`?
Divertente!
```sh
#!/bin/sh
#Assicurati che tutti i file javascript pronti per il commit passano lo standard code style
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi
```
## Come posso mostrare l'output del mio codice colorato e *carino*?
L'output all'interno della libreria è alquanto basilare, ma se ti piacciono le cose sfarzose, allora installa [snazzy](https://www.npmjs.com/package/snazzy):
```bash
$ npm install snazzy
```
Ed esegui:
```bash
$ standard --verbose | snazzy
```
Ci sono anche [standard-tap](https://www.npmjs.com/package/standard-tap),
[standard-json](https://www.npmjs.com/package/standard-json),
[standard-reporter](https://www.npmjs.com/package/standard-reporter), e
[standard-summary](https://www.npmjs.com/package/standard-summary).
## C'è un API per Node.js?
Sì!
### `standard.lintText(text, [opts], callback)`
Esegue il lint sul parametro passato come input `text`. Il parametro `opts` è un oggetto con le seguenti opzioni:
```js
{
cwd: '', // l'attuale cartella del tuo progetto (default: process.cwd())
filename: '', // percorso del file al quale verrà eseguito il lint (opzionale, visto che alcuni plugin ne hanno bisogno)
fix: false, // corregge gli errori automaticamente
globals: [], // particolari variabili globali da dichiarare
plugins: [], // particolari plugin eslint
envs: [], // particolari eslint environments
parser: '' // particolari parser JavaScript (es. babel-eslint)
}
```
Ulteriori opzioni possono essere caricate usando `package.json` se si trova all'interno della cartella del tuo progetto.
Il parametro `callback` sarà chiamato con un `Error` ed un oggetto `results`.
L'oggetto `results` conterrà se seguenti proprietà:
```js
var results = {
results: [
{
filePath: '',
messages: [
{ ruleId: '', message: '', line: 0, column: 0 }
],
errorCount: 0,
warningCount: 0,
output: '' // codice sorgente fissato (accessibile solo con opzione {fix: true})
}
],
errorCount: 0,
warningCount: 0
}
```
### `results = standard.lintTextSync(text, [opts])`
Versione sincrona di `standard.lintText()`. Se si verifica un errore, viene lanciata un'eccezione. Altrimenti viene ritornato l'oggetto `results`.
### `standard.lintFiles(files, [opts], callback)`
Esegue il lint sui `files` glob. È possibile passare un oggetto `opts`:
```js
var opts = {
ignore: [], // file globs da ignorare (ha alcuni defaults)
cwd: '', // l'attuale cartella del tuo progetto (default: process.cwd())
fix: false, // corregge gli errori automaticamente
globals: [], // particolari variabili globali da dichiarare
plugins: [], // particolari plugin eslint
envs: [], // particolari eslint environments
parser: '' // particolari parser JavaScript (es. babel-eslint)
}
```
Il parametro `callback` sarà chiamato con un `Error` ed un oggetto `results`. (lo stesso di prima).
## Come posso contribuire a `standard`?
I collaboratori sono i benvenuti! Controlla le [issue](https://github.com/standard/standard/issues) o le [PR](https://github.com/standard/standard/pulls) e crea la tua di PR se vuoi qualcosa che non vedi.
Vuoi chattare? Unisciti ai collaboratori su IRC nel canale `#standard` su freenode.
Eccoti importanti module che sono importanti nell'ecosistema di `standard`:
- **[standard](https://github.com/standard/standard)** - questo repository
- **[standard-engine](https://github.com/flet/standard-engine)** - motore cli per regole eslint arbitrarie
- **[eslint-config-standard](https://github.com/standard/eslint-config-standard)** - regole eslint per standard
- **[eslint-config-standard-jsx](https://github.com/standard/eslint-config-standard-jsx)** - regole eslint per standard (JSX)
- **[eslint-plugin-standard](https://github.com/xjamundx/eslint-plugin-standard)** - regole eslint personalizzate per standard (non fanno parte del cuore di eslint)
- **[eslint](https://github.com/eslint/eslint)** - il linter che da energie a standard
- **[snazzy](https://github.com/standard/snazzy)** - generate output carino nel terminale per standard
- **[standard-www](https://github.com/standard/standard-www)** - codice per https://standardjs.com
- **[semistandard](https://github.com/Flet/semistandard)** - standard, ma con i punti e virgola (se proprio sei obbligato)
Ci sono anche molti **[plugin per l'editor di testo](#ci-sono-dei-plugin-per-gli-editor-di-testo)**, una lista di **[npm packages che usano `standard`](https://github.com/standard/standard-packages)**,
una incredibile lista di
**[packages nell'ecosistema di `standard`](https://github.com/standard/awesome-standard)**.
## Licenza
[MIT](LICENSE). Copyright (c) [Feross Aboukhadijeh](http://feross.org).
================================================
FILE: docs/README-kokr.md
================================================
<h1 align="center">
<a href="https://standardjs.com"><img src="https://cdn.rawgit.com/feross/standard/master/sticker.svg" alt="Standard - JavaScript Style Guide" width="200"></a>
<br>
JavaScript Standard Style
<br>
<br>
</h1>
<p align="center">
<a href="https://travis-ci.org/feross/standard"><img src="https://img.shields.io/travis/feross/standard/master.svg" alt="travis"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/v/standard.svg" alt="npm version"></a>
<a href="https://www.npmjs.com/package/eslint-config-standard"><img src="https://img.shields.io/npm/dm/eslint-config-standard.svg" alt="npm downloads"></a>
<a href="https://standardjs.com"><img src="https://img.shields.io/badge/code_style-standard-brightgreen.svg" alt="Standard - JavaScript Style Guide"></a>
</p>
<h4 align="center">One JavaScript Style to Rule Them All</h4>
<p align="center">
<a href="README-en.md">English</a> •
<a href="README-esla.md">Español (Latinoamérica)</a> •
<a href="README-iteu.md">Italiano (Italian)</a> •
<a href="README-kokr.md">한국어 (Korean)</a> •
<a href="README-ptbr.md">Português (Brasil)</a> •
<a href="README-zhcn.md">简体中文 (Simplified Chinese)</a> •
<a href="README-zhtw.md">繁體中文 (Taiwanese Mandarin)</a>
</p>
<br>
## 교정 & 자동 코드 수정을 도와주는 JavaScript 스타일 가이드
이 모듈은 다음과 같은 세 가지 방법으로 시간을 절약할 수 있습니다.
- **환경설정이 필요없습니다.** 프로젝트에서 일관된 스타일을 적용하는 가장 쉬운 방법입니다. 그냥 넣기만 하면 됩니다.
- **자동으로 코드 포멧을 맞춰줍니다.** `standard --fix`를 실행하면 지저분하거나 일관성없는 코드와 작별인사 할 수 있습니다.
- **스타일 이슈 및 프로그래머의 오류를 조기에 파악할 수 있습니다.** 리뷰어와 기여자 사이의 관계를 제거함으로써 귀중한 코드 리뷰 시간을 절약할 수 있습니다.
만드는 것의 대해 결정할 필요가 없습니다. `.eslintrc`, `.jshintrc`, `.jscsrc` 파일들을 관리할 필요가 없이 바로 가능합니다.
설치하는 방법입니다.
```
npm install standard --save-dev
```
## 규칙
- **2칸 공백을 사용합니다.** – 들여쓰기
- **문자열에 작은 따옴표를 사용합니다.** – 누락된 곳은 제외합니다.
- **사용되지 않는 변수가 없어야 합니다.** – 이 것은 대량의 버그를 초래하는 원인입니다.
- **세미콜론이 없어야 합니다.** – [It's][1] [fine.][2] [Really!][3]
- **`(`, `[`, or `` ` ``과 같이 라인을 시작하지 말아야 합니다.**
- 세미콜론 생략시 반드시 문제가 생길 수 있습니다. – *자동으로 체크할 수 있도록 준비되어 있습니다.*
- [More details][4]
- **키워드 뒤에 공백을 사용합니다.** `if (condition) { ... }`
- **함수명 뒤에 공백을 사용합니다.** `function name (arg) { ... }`
- 항상 `==` 대신 `===`을 사용합니다. - 단, `null || undefined`는 `obj == null`로 확인할 수 있습니다.
- node.js에서 err 파라미터는 항상 처리해야 합니다.
- 항상 브라우저 전역에 `window` 접두사를 붙입니다. - `document`와 `navigator`는 괜찮습니다.
- `open`, `length`, `event`, `name` 등 불분명하게 브라우저 전역을 우연히 사용하는 것을 방지합니다.
- **[더 많은 장점][5]이 있습니다.** - *`standard`를 시도해보세요!*
[1]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
[2]: http://inimino.org/~inimino/blog/javascript_semicolons
[3]: https://www.youtube.com/watch?v=gsfbh17Ax9I
[4]: RULES.md#semicolons
[5]: RULES.md#javascript-standard-style
더 나은 아이디어를 얻으려면 JavaScript Standard 스타일로 작성된 [샘플 파일](https://github.com/expressjs/body-parser/blob/master/index.js)을 살펴보십시오. 또는 `standard`을 사용하는 [수천 개의 프로젝트](https://raw.githubusercontent.com/feross/standard-packages/master/all.json) 중 하나를 확인하십시오!
## 목차
- 빠른 시작
- [설치](#설치)
- [사용법](#사용법)
- [이해가 잘되면 다음을 수행합니다](#이해가-잘되면-다음을-수행합니다)
- 질의응답
- [왜 JavaScript Standard Style을 사용해야 할까요?](#왜-JavaScript-Standard-Style을-사용해야-할까요)
- [누가 JavaScript Standard Style을 사용하나요?](#누가-JavaScript-Standard-Style을-사용하나요)
- [텍스트 편집 플러그인이 있나요?](#텍스트-편집-플러그인이-있나요)
- [readme에 넣을 수 있는 뱃지로고가 있나요?](#readme에-넣을-수-있는-뱃지로고가-있나요)
- [나와는 룰이 맞지 않습니다. 변경 가능합니까?](#나와는-룰이-맞지-않습니다.-변경-가능합니까)
- [그러나 이 것은 실제 웹표준이 아닙니다!](#그러나-이-것은-실제-웹표준이-아닙니다)
- [자동으로 포멧을 맞춰주는 것이 있나요?](#자동으로-포멧을-맞춰주는-것이-있나요)
- [어떻게하면 파일들을 무시할 수 있나요?](#어떻게하면-파일들을-무시할-수-있나요)
- [어떻게하면 경고를 숨길 수 있나요?](#어떻게하면-경고를-숨길-수-있나요)
- [전역 namespace를 오염시키는 라이브러리를 사용합니다. "vaiable is not defined" 오류를 방지하려면 어떻게 해야 하나요?](#전역-namespace를-오염시키는-라이브러리를-사용합니다-vaiable-is-not-defined-오류를-방지하려면-어떻게-해야-하나요)
- [실험용 JavaScript (ES Next) 기능은 어떻게 사용하나요?](#실험용-javascript-es-next-기능은-어떻게-사용하나요)
- [Flow와 같은 JavaScrpt 언어 변형을 사용할 수 있나요?](#flow와-같은-javascrpt-언어-변형을-사용할-수-있나요)
- [Mocha, Jasmine, QUnit 등은 어떻습니까?](#mocha-jasmine-qunit-등은-어떻습니까)
- [Web Workes는 어떻습니까?](#web-workes는-어떻습니까)
- [Markdown 또는 HTML 파일 내부의 코드를 확인할 수 있나요?](#markdown-또는-html-파일-내부의-코드를-확인할-수-있나요)
- [Git `pre-commit` hook이 있나요?](#git-pre-commit-hook이-있나요)
- [출력을 모두 화려하고 예쁘게 만드려면 어떻게 해야 하나요?](#출력을-모두-화려하고-예쁘게-만드려면-어떻게-해야-하나요)
- [Node.js API가 있나요?](#nodejs-api가-있나요)
- [`standard` 기여는 어떻게 하나요?](#standard-기여는-어떻게-하나요)
- [라이선스](#라이선스)
## 설치
JavaScript Standard Style을 사용하는 가장 쉬운 방법은 Node 명령 프로그램을 통해 전역으로 설치하는 것입니다. 터미널에서 다음 명령을 실행하세요.
```bash
$ npm install standard --global
```
또는 `standard`를 로컬에 설치하여 단일 프로젝트에서 사용할 수 있습니다.
```bash
$ npm install standard --save-dev
```
*메모: 위 명령을 실행하려면 [Node.js](http://nodejs.org)와 [npm](https://npmjs.com)이 설치되어 있어야 합니다.*
## 사용법
`standard`를 설치 한 후에 `standard` 프로그램을 사용할 수 있습니다. 가장 간단한 사용 사례는 현재 작업 디렉토리에있는 모든 JavaScript 파일의 스타일을 확인하는 것입니다.
```bash
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
You can optionally pass in a directory (or directories) using the glob pattern. Be
sure to quote paths containing glob patterns so that they are expanded by
`standard` instead of your shell:
glob 패턴을 사용하여 디렉토리(또는 디렉토리들)를 선택적으로 전달할 수 있습니다. glob 패턴을 포함하는 경로를 인용 부호로 묶어 쉘 대신에 `standard`에 의해 확장되도록 할 수 있습니다.
```bash
$ standard "src/util/**/*.js" "test/**/*.js"
```
**메모** 기본적으로`standard`는 `**/*.js`, `**/*.jsx` 패턴과 일치하는 모든 파일을 찾을 것입니다.
## 이해가 잘되면 다음을 수행합니다
1. `package.json`에 다음코드를 추가합니다.
```json
{
"name": "my-cool-package",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}
```
2. `npm test`를 실행할 때 자동으로 스타일을 검사합니다.
```bash
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
3. style 의견의 대해 절대로 풀 리퀘스트를 요청하지 마세요.
## 왜 JavaScript Standard Style을 사용해야 할까요?
JavaScript Standard Style의 장점은 간단하다는 것입니다. 어느누구도 작업하는 모든 모듈/프로젝트에 대해 수백 줄 style의 구성 파일을 유지하려고하지 않습니다. 더 이상 바보같은 짓은 그만하세요.
이 모듈은 세가지의 방법으로 당신(또는 주변사람들)의 시간을 절약할 수 있습니다.
- **환경설정이 필요없습니다.** 프로젝트에서 일관된 스타일을 적용하는 가장 쉬운 방법입니다. 그냥 넣기만 하면 됩니다.
- **자동으로 코드 포멧을 맞춰줍니다.** `standard --fix`를 실행하면 지저분하거나 일관성없는 코드와 작별인사 할 수 있습니다.
- **스타일 이슈 및 프로그래머의 오류를 조기에 파악할 수 있습니다.** 리뷰어와 기여자 사이의 관계를 제거함으로써 귀중한 코드 리뷰 시간을 절약할 수 있습니다.
`standard` 스타일을 채택한다는 것은 개인적 스타일보다 코드 명확성과 커뮤니티 협업의 중요성을 우선으로 하는 것을 의미합니다. 이것은 프로젝트와 개발문화에 100% 타당하지 않을 수도 있지만, 오픈소스는 초보자들에게 적대적인 장소가 될 수 있습니다. 명확하고 자동화된 기여를 기대할수록 프로젝트가 더욱 건강해 집니다.
## 누가 JavaScript Standard Style을 사용하나요?
주변에 많은 사람들!
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/npm.png>](https://www.npmjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/github.png>](https://github.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/opbeat.png>](https://opbeat.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nearform.png>](http://www.nearform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/brave.png>](https://www.brave.com) |
|---|---|---|---|---|
| [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zeit.png>](https://zeit.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zendesk.png>](https://www.zendesk.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/mongodb.jpg>](https://www.mongodb.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/typeform.jpg>](https://www.typeform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/gov-uk.png>](https://gds.blog.gov.uk) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/express.png>](http://expressjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/webtorrent.png>](https://webtorrent.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/ipfs.png>](https://ipfs.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/dat.png>](https://datproject.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bitcoinjs.png>](https://bitcoinjs.org) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/atom.png>](https://atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/electron.png>](http://electron.atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/voltra.png>](https://voltra.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/treasuredata.png>](https://www.treasuredata.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/clevertech.png>](https://clevertech.biz) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/studynotes.jpg>](https://www.apstudynotes.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/optiopay.png>](https://www.optiopay.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/jaguar-landrover.png>](https://www.jlrtechincubator.com/jlrti/) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bustle.jpg>](https://www.bustle.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zentrick.png>](https://www.zentrick.com) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nodesource.png>](https://nodesource.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/greenkeeper.png>](https://greenkeeper.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/karma.png>](https://karma-runner.github.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/taser.png>](https://www.taser.com) |
|---|---|---|---|
회사 이외에 많은 커뮤니티 회원은 여기에 나열하기에는 [너무 많은](https://raw.githubusercontent.com/feross/standard-packages/master/all.json) 패키지들이 `standard`를 사용합니다.
또한 GitHub의 [Clean Code Linter](https://github.com/showcases/clean-code-linters) 쇼케이스에서도 볼 수 있습니다.
## 텍스트 편집 플러그인이 있나요?
먼저, `standard`를 설치합니다. 그런 다음, 편집기에 적절한 플러그인을 설치하세요.
### Sublime Text
**[Package Control][sublime-1]** 을 사용하여, **[SublimeLinter][sublime-2]** 와 **[SublimeLinter-contrib-standard][sublime-3]** 를 설치합니다.
저장시 자동포멧을 적용하려면 **[StandardFormat][sublime-4]** 을 설치하세요.
[sublime-1]: https://packagecontrol.io/
[sublime-2]: http://www.sublimelinter.com/en/latest/
[sublime-3]: https://packagecontrol.io/packages/SublimeLinter-contrib-standard
[sublime-4]: https://packagecontrol.io/packages/StandardFormat
### Atom
**[linter-js-standard][atom-1]** 를 설치합니다.
저장시 자동포멧을 적용하려면 **[standard-formatter][atom-2]** 를 설치합니다. 스니펫의 경우 **[standardjs-snippets][atom-3]** 을 설치합니다.
[atom-1]: https://atom.io/packages/linter-js-standard
[atom-2]: https://atom.io/packages/standard-formatter
[atom-3]: https://atom.io/packages/standardjs-snippets
### Visual Studio Code
**[vscode-standardjs][vscode-1]** 를 설치합니다. (자동포멧을 지원합니다.)
JS 스니펫의 경우 **[vscode-standardjs-snippets][vscode-2]** 을 설치합니다. React 스니펫의 경우 **[vscode-react-standard][vscode-3]** 를 설치합니다.
[vscode-1]: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs
[vscode-2]: https://marketplace.visualstudio.com/items?itemName=capaj.vscode-standardjs-snippets
[vscode-3]: https://marketplace.visualstudio.com/items/TimonVS.ReactSnippetsStandard
### Vim
**[ale][vim-1]** 를 설치합니다.
For automatic formatting on save, add these lines to `.vimrc`:
저장시 자동포멧을 적용하려면 해당 코드를 `.vimrc`에 추가하세요.
```vim
autocmd bufwritepost *.js silent !standard --fix %
set autoread
```
고려해야 할 대체 플러그인으로는 [neomake][vim-2] 및 [syntastic][vim-3]이 있으며, 둘 다 표준에 대한 지원이 내장되어 있습니다. (추가적으로 구성이 필요할 수도 있습니다)
[vim-1]: https://github.com/w0rp/ale
[vim-2]: https://github.com/neomake/neomake
[vim-3]: https://github.com/vim-syntastic/syntastic
### Emacs
**[Flycheck][emacs-1]** 를 설치하고 **[manual][emacs-2]** 을 확인하여 프로젝트에서 활성화하는 방법을 확인하십시오.
[emacs-1]: http://www.flycheck.org
[emacs-2]: http://www.flycheck.org/en/latest/user/installation.html
### Brackets
extension registry에서 **["Standard Code Style"][brackets-1]** 을 검색하여 "Install"을 클릭하세요.
[brackets-1]: https://github.com/ishamf/brackets-standard/
### WebStorm (PhpStorm, IntelliJ, RubyMine, JetBrains, etc.)
WebStrom은 `standard`가 직접적으로 IDE에서 사용가능다고 [기본적인 지원에 관한 최근 발표](https://blog.jetbrains.com/webstorm/2017/01/webstorm-2017-1-eap-171-2272/) 했습니다.
만약 수동으로 `standard`를 구성하려면 [안내서]([webstorm-1])를 따르십시오. 이것은 PhpStorm, IntelliJ, RubyMine 등 모든 JetBrains 제품에 적용됩니다.
[webstorm-1]: docs/webstorm.md
## readme에 넣을 수 있는 뱃지로고가 있나요?
네! 프로젝트에서 `standard`를 사용한다면, readme에 이 뱃지들 중 하나를 포함시켜 코드가 standard 스타일을 사용하고 있음을 사람들에게 알릴 수 있습니다.
[](https://github.com/standard/standard)
```md
[](https://github.com/standard/standard)
```
[](https://standardjs.com)
```md
[](https://standardjs.com)
```
## 나와는 룰이 맞지 않습니다. 변경 가능합니까?
안됩니다. `standard`의 전체적인 요점은 코드 스타일에 대한 [bikeshedding][bikeshedding]을 피함으로써 시간을 절약하는 것입니다. 탭과 공백 등에 관해서는 온라인으로 많은 논쟁이 있기때문에 해결되지 않을 것입니다. 이러한 논쟁은 어떠한 것도 얻지 못하게합니다. 결국 `뭔가를 골라야 한다`입니다. 그것은 `standard`의 철학입니다. 이는 `단지 뭔가를 선택하세요`라는 의견입니다. 바라건대, 사용자들이 자신들의 의견을 방어하는 것에 대해 가치를 보게 되기를 바랍니다.
수백 개의 ESLint 규칙을 개별적으로 구성하려는 경우 `eslint`를 직접 [eslint-config-standard](https://github.com/standard/eslint-config-standard)와 함께 사용하여 변경 사항을 맨 위에 배치 할 수 있습니다.
팁 : 표준을 사용하고 계속 진행하십시오. 당신의 시간을 소비하고 있는 실질적인 문제를 해결하세요! :P
[bikeshedding]: https://www.freebsd.org/doc/en/books/faq/misc.html#bikeshed-painting
## 그러나 이 것은 실제 웹표준이 아닙니다!
물론 표준이 아닙니다! 여기에 제시된 스타일은 공식 웹 표준 그룹과 관련이 없으므로 `ECMA/standard`이 아닌 `feross/standard`라고하는 이유입니다.
"standard"이라는 단어는 "web standard"이상의 의미를 가지고 있습니다 :-)
예를 들어,
- 이 모듈은 우리의 코드를 높은 수준의 품질로 유지하는 데 도움이됩니다.
- 이 모듈은 새로운 기여자가 몇 가지 기본 스타일 표준을 준수하도록합니다.
## 자동으로 포멧을 맞춰주는 것이 있나요?
예! `standard --fix`를 사용하면 자동으로 대부분의 문제를 자동으로 해결할 수 있습니다.
`standard --fix`는 최대의 편의를 위해 `standard`에 내장되어 있습니다. 대부분의 문제점은 고칠 수 있지만 일부 오류(오류 처리를 잊어 버리는 것)는 수동으로 해결해야합니다.
시간을 절약하기 위해 `standard`는 자동으로 수정할 수있는 문제를 발견하면 "`Run standard --fix to automatically fix some problems`" 메시지를 출력합니다.
## 어떻게하면 파일들을 무시할 수 있나요?
특정 경로 (`node_modules/`, `coverage/`, `vendor/`, `*.min.js`, `bundle.js`, `.git/`와 같이 `.`으로 시작하는 파일/폴더)는 자동으로 무시됩니다.
프로젝트의 루트 `.gitignore` 파일에 있는 경로도 자동으로 무시됩니다.
때로는 추가 폴더 또는 특정 축소 파일을 무시해야합니다. 이를 수행하려면 `package.json`에 `standard.ignore` 속성을 추가하십시오.
```json
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
```
## 어떻게하면 경고를 숨길 수 있나요?
드문 경우이지만 규칙을 위반하고 `standard`에 의해 생성 된 경고를 숨길 필요가 있습니다.
JavaScript 표준 스타일은 [ESLint](http://eslint.org/)를 사용하며 ESLint를 직접 사용한 경우 일반적으로 경고를 숨길 수 있습니다.
자세한 출력을 얻으려면 (무시할 특정 규칙 이름을 찾을 수 있도록) 다음을 실행하십시오.
```bash
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)
```
특정 줄에서 **모든 규칙** 을 비활성화할 수 있습니다.
```js
file = 'I know what I am doing' // eslint-disable-line
```
혹은, 특정 줄에서 **`"no-use-before-define"` 규칙만** 비활성화 할 수 있습니다.
```js
file = 'I know what I am doing' // eslint-disable-line no-use-before-define
```
`"no-use-before-define"` 규칙을 여러 줄에 적용할 수 있습니다.
```js
/* eslint-disable no-use-before-define */
console.log('offending code goes here...')
console.log('offending code goes here...')
console.log('offending code goes here...')
/* eslint-enable no-use-before-define */
```
## 전역 namespace를 오염시키는 라이브러리를 사용합니다. "vaiable is not defined" 오류를 방지하려면 어떻게 해야 하나요?
일부 패키지 (예 : `mocha`)는 전역 개체 (가난한 형태!)에 기능 (예 : `describe`, `it`)을 지정합니다. 이 함수는 정의되지 않았거나 코드의 어느 곳에서든지 요구 될 수 있기 때문에 `standard`에서는 정의되지 않은 변수를 사용하고 있다고 경고합니다 (일반적으로 이 규칙은 오타를 잡는 데 유용합니다). 그러나 우리는 이 전역 변수들에 대해 이를 비활성화 하고자합니다.
`standard` (코드를 읽는 사람뿐만 아니라)에서 특정 변수가 코드에서 전역이라는 것을 알 수 있도록 파일의 맨 위에 추가하십시오.
```js
/* global myVar1, myVar2 */
```
수백 개의 파일이 있다면 모든 파일에 주석을 추가하지 않는 것이 좋습니다. 이 경우 다음을 실행하십시오.
```bash
$ standard --global myVar1 --global myVar2
```
혹은 `package.json`에 다음코드를 추가하세요.
```json
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
```
*노트: `global`과 `globals`는 같습니다.
## 실험용 JavaScript (ES Next) 기능은 어떻게 사용하나요?
`standard`는 제안 프로세스의 "단계 4"에있는 언어 기능 제안을 포함하여 최신 ECMAScript 기능인 ES8 (ES2017)을 지원합니다.
실험용 언어 기능을 지원하기 위해 `standard`는 맞춤 JavaScript 파서를 지정하는 것을 지원합니다. 커스텀 파서를 사용하기 전에 추가 된 복잡성이 그럴 가치가 있는지 고려하십시오.
```bash
$ standard --parser babel-eslint
```
혹은, `package.json`에 아래코드를 추가하세요.
```json
{
"standard": {
"parser": "babel-eslint"
}
}
```
`standard'가 전역으로 설치되면 (즉,`npm install standard --global`), `babel-eslint`를 `npm install babel-eslint --global`과 함께 설치하십시오.
## Flow와 같은 JavaScrpt 언어 변형을 사용할 수 있나요?
커스텀 JS 언어 변형을 사용하기 전에 추가된 복잡성 (그리고 새로운 기여자를 최신으로 만드는데 필요한 노력)이 그만한 가치가 있는지 고려하십시오.
`standard`는 ESLint 플러그인을 지원합니다. `standard` 중 하나를 보기 전에 코드를 유효한 JavaScript로 변환하려면 이 중 하나를 사용하십시오. 맞춤 구문 분석기를 사용하려면 npm에서 설치하고 다음을 실행하십시오.
```bash
$ standard --plugin 플러그인_이름
```
아니면, `package.json`에 아래 코드를 추가하세요.
```json
{
"standard": {
"plugins": [ "플러그인_이름" ]
}
}
```
Flow를 사용하려면 `babel-eslint`를 파서로 사용해야합니다. 따라서 `npm install eslint-plugin-flowtype babel-eslint`를 수행한 후에, 다음을 실행하십시오.
```bash
$ standard --plugin flowtype --parser babel-eslint
```
아니면, `package.json`에 아래 코드를 추가하세요.
```json
{
"standard": {
"plugins": [ "flowtype" ],
"parser": "babel-eslint"
}
}
```
`standard`가 전역으로 설치된 경우 (즉, `npm install standard --global`) `npm install-eslint-plugin-flowtype --global`을 사용하여 `eslint-plugin-flowtype`을 전역으로 설치해야합니다.
**참고 : 플러그인 및 플러그인은 동일합니다.**
## Mocha, Jasmine, QUnit 등은 어떻습니까?
테스트 파일에서 mocha를 지원하려면 테스트 파일의 시작 부분에 다음을 추가하십시오.
```js
/* eslint-env mocha */
```
혹은 다음을 실행하세요.
```bash
$ standard --env mocha
```
`mocha`는 `jasmine`, `qunit`, `phantomjs` 중 하나가 될 수 있습니다. 전체 목록을 보려면 ESLint의 [specifying environments(스펙문서)](http://eslint.org/docs/user-guide/configuring.html#specifying-environments)를 확인하십시오. 이러한 환경에서 사용할 수있는 전역의 목록을 보려면 [globals](https://github.com/sindresorhus/globals/blob/master/globals.json) npm 모듈을 확인하십시오.
**참고 : `env` 및 `envs`는 동일합니다.**
## Web Workes는 어떻습니까?
적용하려는 파일 상단에 아래 주석코드를 추가하세요.
```js
/* eslint-env serviceworker */
```
이것은 `standard` (자신의 코드를 읽는 사람뿐만 아니라)이 web worker 코드에서 `자신`이 전역(global)이라는 것을 알 수 있게 해줍니다.
## Markdown 또는 HTML 파일 내부의 코드를 확인할 수 있나요?
Markdown 파일 내의 코드를 확인하려면 [`standard-markdown`](https://www.npmjs.com/package/standard-markdown)을 사용하십시오.
또는 Markdown, HTML 및 기타 여러 유형의 언어 파일에서 코드를 확인할 수있는 ESLint 플러그인이 있습니다.
Markdown 파일 내의 코드를 확인하려면 ESLint 플러그인을 사용하십시오.
```bash
$ npm install eslint-plugin-markdown
```
그런 다음, 코드 블록 안에있는 JS를 확인하려면 다음을 실행하십시오.
```bash
$ standard --plugin markdown '**/*.md'
```
HTML 파일 내부의 코드를 확인하려면 ESLint 플러그인을 사용하십시오.
```bash
$ npm install eslint-plugin-html
```
그런 다음, `<script>`태그 안에있는 JS를 확인하려면 다음을 실행하십시오.
```bash
$ standard --plugin html '**/*.html'
```
## Git `pre-commit` hook이 있나요?
재미있는 질문이네요!
```sh
#!/bin/sh
# 커밋을 위해 준비된 모든 자바 스크립트 파일이 표준 코드 스타일을 통과하는지 확인합니다.
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi
```
## 출력을 모두 화려하고 *예쁘게* 만드려면 어떻게 해야 하나요?
내장 된 출력물은 간단하고 간단하지만 반짝이는 물건을 원한다면 [snazzy](https://www.npmjs.com/package/snazzy) 설치하십시오.
```bash
$ npm install snazzy
```
그리고 아래 명령어를 실행합니다.
```bash
$ standard --verbose | snazzy
```
[standard-tap](https://www.npmjs.com/package/standard-tap),
[standard-json](https://www.npmjs.com/package/standard-json),
[standard-reporter](https://www.npmjs.com/package/standard-reporter),
[standard-summary](https://www.npmjs.com/package/standard-summary)도 있습니다..
## Node.js API가 있나요?
네!
### `standard.lintText(text, [opts], callback)`
린트에 제공할 소스 `text`를 준비합니다. `opts` 객체를 추가할 수 있습니다.
```js
{
cwd: '', // 현재 작업 디렉토리 (기본: process.cwd())
filename: '', // 린트 텍스트를 포함하는 파일의 경로 (선택, 일부 eslint 플러그인이 필요함)
fix: false, // 자동 문제 해결
globals: [], // 선언할 커스텀 글로벌 변수
plugins: [], // 커스텀 eslint 플러그인
envs: [], // 커스텀 eslint 환경
parser: '' // 커스텀 js 파서 (예: babel-eslint)
}
```
`package.json`가 현재 작업 디렉토리에서 발견되면 추가옵션을 로드 할 수 있습니다.
`콜백(callback)`은 `Error`와 `results`객체와 함께 호출 될 것입니다.
`results`객체는 다음과 같은 속성을 포함합니다.
```js
var results = {
results: [
{
filePath: '',
messages: [
{ ruleId: '', message: '', line: 0, column: 0 }
],
errorCount: 0,
warningCount: 0,
output: '' // 고정 소스 코드 ({fix : true} 옵션과 함께 제공)
}
],
errorCount: 0,
warningCount: 0
}
```
### `results = standard.lintTextSync(text, [opts])`
`standard.lintText()`의 동기화 버전. 오류가 발생하면 예외가 발생합니다. 그렇지 않으면 `results`객체가 반환됩니다.
### `standard.lintFiles(files, [opts], callback)`
제공된 'files' 덩어리를 린트에 적용할 수 있습니다. `opts` 객체를 추가할 수 있습니다.
```js
var opts = {
ignore: [], // 파일뭉치를 무시합니다. (기본적인 무시파일들이 포함되어 있습니다)
cwd: '', // 현재 작업 디렉토리 (기본: process.cwd())
fix: false, // 자동 문제 해결
globals: [], // 선언할 글로벌 변수
plugins: [], // eslint 플러그인
envs: [], // eslint 환경
parser: '' // js 파서 (예: babel-eslint)
}
```
`callback`은 `Error`와 `results`객체로 호출됩니다. (위와 같습니다)
## `standard` 기여는 어떻게 하나요?
기여를 환영합니다! [issues](https://github.com/standard/standard/issues) 나 [PRs](https://github.com/standard/standard/pulls)를 확인하고 거기에 보이지 않는 것을 원한다면 직접 만들어주세요.
채팅을 원하시나요? freenode의 `#standard` 채널에서 IRC의 참여자와 함께하세요.
다음은 `standard` 생태계의 중요한 패키지입니다.
- **[standard](https://github.com/standard/standard)** - 현재 저장소
- **[standard-engine](https://github.com/flet/standard-engine)** - 임의의 eslint 규칙에 대한 cli 엔진
- **[eslint-config-standard](https://github.com/standard/eslint-config-standard)** - `standard`을 위한 eslint 규칙
- **[eslint-config-standard-jsx](https://github.com/standard/eslint-config-standard-jsx)** - `standard`을 위한 eslint 규칙 (JSX)
- **[eslint-plugin-standard](https://github.com/xjamundx/eslint-plugin-standard)** - `standard`을 위한 커스텀 eslint 규칙 (eslint 코어의 일부가 아닙니다.)
- **[eslint](https://github.com/eslint/eslint)** - 강력한 standard linter
- **[snazzy](https://github.com/standard/snazzy)** - standard를 예쁘게 터미널에 출력해줍니다.
- **[standard-www](https://github.com/standard/standard-www)** - https://standardjs.com에 대한 코드
- **[semistandard](https://github.com/Flet/semistandard)** - 세미콜론이 포함된 standard (필요한 경우)
또한 많은 **[에디터 플러그인](#text-editor-plugins)**, **[`standard`를 사용하는 npm 패키지 목록](https://github.com/standard/standard-packages)**, **[`standard` 에코 시스템의 멋진 패키지 목록](https://github.com/standard/awesome-standard)** 이 있습니다.
## 라이선스
[MIT](LICENSE). Copyright (c) [Feross Aboukhadijeh](http://feross.org).
================================================
FILE: docs/README-ptbr.md
================================================
<h1 align="center">
<a href="https://standardjs.com"><img src="https://cdn.rawgit.com/feross/standard/master/sticker.svg" alt="Standard - JavaScript Style Guide" width="200"></a>
<br>
JavaScript Standard Style
<br>
<br>
</h1>
<p align="center">
<a href="https://travis-ci.org/feross/standard"><img src="https://img.shields.io/travis/feross/standard/master.svg" alt="Travis"></a>
<a href="https://standardjs.com"><img src="https://img.shields.io/badge/code_style-standard-brightgreen.svg" alt="Standard - JavaScript Style Guide"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/dm/standard.svg" alt="npm downloads"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/v/standard.svg" alt="npm version"></a>
</p>
<h4 align="center">Um Guia de Estilo JavaScript para a todos governar</h4>
<p align="center">
<a href="README-en.md">English</a> •
<a href="README-esla.md">Español (Latinoamérica)</a> •
<a href="README-iteu.md">Italiano (Italian)</a> •
<a href="README-kokr.md">한국어 (Korean)</a> •
<a href="README-ptbr.md">Português (Brasil)</a> •
<a href="README-zhcn.md">简体中文 (Simplified Chinese)</a> •
<a href="README-zhtw.md">繁體中文 (Taiwanese Mandarin)</a>
</p>
<br>
Sem ter que tomar decisões; Sem gerenciar `.eslintrc`, `.jshintrc`, ou `.jscsrc` . Funciona logo de cara.
Esse módulo salva o seu tempo (e de outras pessoas!) de duas formas:
- **Zero configuração.** A forma mais fácil de forçar consistência de estilo no seu projeto. É só tacar lá e pronto.
- **Captura erros de estilo antes de serem enviados em PR's.** Salva um tempo precioso de code review eliminando vai-e-vem entre mantenedor e contribuínte.
Instale:
```
npm install standard
```
### As Regras
- **2 espaços** – para identação
- **Aspas simples para strings** – exceto para evitar escapamentos
- **Sem variáveis não-utilizadas** – resolve *uma porrada* de bugs!
- **Sem vírgulas-e-vírgula** – [Dá][1] [boa.][2] [Sério!][3]
- **Nunca comece uma linha com `(`, `[`, ou `` ` ``**
- Esse é o único **problema** em omitir ponto-e-vírgula – *checado automaticamente pra você!*
- [Mais detalhes][4]
- **Espaço após keywords** `if (condição) { ... }`
- **Espaço antes dos nomes das funções** `function nome (arg) { ... }`
- Sempre use `===` ao invés de `==` – mas `obj == null` é permitido para checar se `null || undefined`.
- Sempre lide com o parâmetro `err` do node.
- Sempre prefixe globais de browser com `window` – exceto `document` e `navigator`, essas tudo bem.
- Previne o uso acidental de globais de browser mal-nomeadas como `open`, `length`,
`event`, e `name`.
- **E [mais benefícios][5]** – *dê uma chance para `standard` hoje!*
[1]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
[2]: http://inimino.org/~inimino/blog/javascript_semicolons
[3]: https://www.youtube.com/watch?v=gsfbh17Ax9I
[4]: RULES.md#semicolons
[5]: RULES.md#javascript-standard-style
Para ter uma idéia melhor, dê uma olhada
[num arquivo amostra](https://github.com/webtorrent/bittorrent-dht/blob/master/client.js) escrito no JavaScript Standard Style, ou dê uma olhada em alguns dos
[repositórios](https://github.com/standard/standard-packages/blob/master/all.json) que usam
`standard`.
## Índice
- [Instalação](#instala%C3%A7%C3%A3o)
- [Uso](#uso)
- [O que você pode fazer se for espertinho](#o-que-voc%C3%AA-pode-fazer-se-for-espertinho)
- [Insígnia](#ins%C3%ADgnia)
- [Plugins de Editores de Texto](#plugins-de-editores-de-texto)
- [FAQ](#faq)
- [Por que eu deveria usar o JavaScript Standard Style?](#por-que-eu-deveria-usar-o-javascript-standard-style)
- [Discordo da regra X, você pode mudá-la?](#discordo-da-regra-x-voc%C3%AA-pode-mud%C3%A1-la)
- [Mas isso não é um padrão legítimo!](#mas-isso-n%C3%A3o-%C3%A9-um-padr%C3%A3o-leg%C3%ADtimo)
- [Existe um formatador automático?](#existe-um-formatador-autom%C3%A1tico)
- [Como ignoro arquivos?](#como-ignoro-arquivos)
- [Como escondo um determinado aviso?](#como-escondo-um-determinado-aviso)
- [Eu uso uma biblioteca que polui o namespace global. Como eu previno erros de "variable is not defined"?](#eu-uso-uma-biblioteca-que-polui-o-namespace-global-como-eu-previno-erros-de-variable-is-not-definedfunctions)
- [Posso usar um custom parser de JS novinho em folha que saiu ontem para suporte ao ES Next?](#posso-usar-um-custom-parser-de-js-novinho-em-folha-que-saiu-ontem-para-suporte-ao-es-next)
- [Posso usar uma linguagem variante de JavaScript, tipo Flow?](#posso-usar-uma-linguagem-variante-de-javascript-tipo-flow)
- [Você pode tornar regra X configurável?](#voc%C3%AA-pode-tornar-regra-x-configur%C3%A1vel)
- [E os Web Workers?](#e-os-web-workers)
- [E a respeito de Mocha, Jasmine, QUnit, etc?](#e-a-respeito-de-mocha-jasmine-qunit-etc)
- [Existe um hook `pre-commit` para Git?](#existe-um-hook-pre-commit-para-git)
- [Como eu deixo o output todo coloridinho e *bonitinho*?](#como-eu-deixo-o-output-todo-coloridinho-e-bonitinho)
- [Quero contribuir com o `standard`. Quais packages eu devo conhecer?](#quero-contribuir-com-o-standard-quais-packages-eu-devo-conhecer)
- [Node.js API](#nodejs-api)
- [`standard.lintText(text, [opts], callback)`](#standardlinttexttext-opts-callback)
- [`standard.lintFiles(files, [opts], callback)`](#standardlintfilesfiles-opts-callback)
- [Licensa](#licensa)
## Instalação
A forma mais fácil de usar o JavaScript Standard Style para checar seu código é instalá-lo globalmente como se fosse um programa de linha de comando do Node. Para isso, simplesmente execute o seguinte comando no seu terminal (a flag `-g` instala o `standard` globalmente no seu sistema, omita-a se quiser instalar no seu diretório de trabalho atual.)
```bash
npm install standard --global
```
Ou você pode rodar este comando para instalar `standard` localmente, para usar no seu módulo:
```bash
npm install standard --save-dev
```
[Node.js](http://nodejs.org) e [npm](https://npmjs.com) são requisitos para rodar este programa.
## Uso
Depois de você ter instalado `standard`, você será capaz de usá-lo. O caso de uso mais simples seria checar o estilo de todos os arquivos JavaScript no diretório de trabalho atual:
```bash
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
Você pode passar opcionalmente um diretório (ou diretórios) usando o padrões glob. Assegure-se de colocar aspas nos caminhos contendo padrões glob para que eles sejam expandidos pelo `standard` ao invés da sua shell.
```bash
$ standard "src/util/**/*.js" "test/**/*.js"
```
**Note:** por padrão `standard` vai procurar por todos os arquivos que casarem com os padrões::
`**/*.js`, `**/*.jsx`.
### O que você pode fazer se for espertinho
1. Adicione isso ao `package.json`
```json
{
"name": "meu-package-legalzao",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}
```
2. Cheque os estilos manualmente quando rodar `npm test`
```
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
3. Nunca dê feedback de estilo num pull request de novo!
### Insígnia
Está usando em um dos seus projetos? Inclua uma dessas insígnias no seu readme para que as pessoas saibam que seu código está em standard style.
[](https://github.com/standard/standard)
```markdown
[](https://github.com/standard/standard)
```
[](https://standardjs.com/)
```markdown
[](https://standardjs.com/)
```
### Plugins de Editores de Texto
Primeiro, instale `standard`. Então, instale o plugin apropriado para o seu editor.
#### [Sublime Text](https://www.sublimetext.com/)
Usando **[Package Control][sublime-1]**, instale **[SublimeLinter][sublime-2]** e
**[SublimeLinter-contrib-standard][sublime-3]**.
Para formatação automática ao salvar, instale **[StandardFormat][sublime-4]**.
[sublime-1]: https://packagecontrol.io/
[sublime-2]: http://www.sublimelinter.com/en/latest/
[sublime-3]: https://packagecontrol.io/packages/SublimeLinter-contrib-standard
[sublime-4]: https://packagecontrol.io/packages/StandardFormat
#### [Atom](https://atom.io)
Instale **[linter-js-standard][atom-1]**.
Para formatação automática, instale **[standard-formatter][atom-2]**. Para snippets,
installe **[standardjs-snippets][atom-3]**.
[atom-1]: https://atom.io/packages/linter-js-standard
[atom-2]: https://atom.io/packages/standard-formatter
[atom-3]: https://atom.io/packages/standardjs-snippets
#### [Vim](http://www.vim.org/)
Instale **[Syntastic][vim-1]** e adicione essa linha ao seu `.vimrc`:
```vim
let g:syntastic_javascript_checkers = ['standard']
```
Para formatação automática ao salvar, instale [standard-format](https://github.com/maxogden/standard-format)
```bash
npm install -g standard-format
```
e adicione essas duas linhas ao seu `.vimrc`:
```vim
autocmd bufwritepost *.js silent !standard-format -w %
set autoread
```
[vim-1]: https://github.com/scrooloose/syntastic
#### [Emacs](https://www.gnu.org/software/emacs/)
Instale **[Flycheck][emacs-1]** e cheque o **[manual][emacs-2]** para aprender a habilitar nos seus projetos.
[emacs-1]: http://www.flycheck.org
[emacs-2]: http://www.flycheck.org/en/latest/user/installation.html
#### [Brackets](http://brackets.io/)
Selecione o registro da extensão do **["Standard Code Style"][brackets-1]**.
[brackets-1]: https://github.com/ishamf/brackets-standard/
#### [Visual Studio Code](https://code.visualstudio.com/)
Instale **[vscode-standardjs][vscode-1]**. (Inclui suporte para formatação automática.)
Para snippets de React, instale **[vscode-react-standard][vscode-2]**.
[vscode-1]: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs
[vscode-2]: https://marketplace.visualstudio.com/items/TimonVS.ReactSnippetsStandard
#### [WebStorm/PhpStorm][webstorm-1]
Ambos PhpStorm e WebStorm podem ser [configurados para Standard Style][webstorm-2].
[webstorm-1]: https://www.jetbrains.com/webstorm/
[webstorm-2]: https://github.com/standard/standard/blob/master/docs/webstorm.md
## FAQ
### Por que eu deveria usar o JavaScript Standard Style?
A beleza do JavaScript Standard Style reside no fato de ser simples. Ninguém quer manter vários arquivos de centenas de linhas de configuração de estilo para cada módulo/projeto em que trabalham. Chega dessa patifaria!
Esse módulo te faz economizar tempo de 2 formas:
- **Zero configuração.** A forma mais fácil de forçar consistência de estilo no seu projeto. É só tacar lá e pronto.
- **Captura erros de estilo antes de serem enviados em PR's.** Salva um tempo precioso de code review eliminando vai-e-vem entre mantenedor e contribuínte.
Adotar o estilo `standard` significa elevar a importância da clareza de código e convenções de comunidade a um patamar acima do estilo pessoal. Pode não fazer sentido para TODOS os projetos e culturas de desenvolvimento, porém, o opens ource pode ser um lugar hostil para novatos. Deixar as expectativas do contribuínte claras e automatizadas deixa o projeto mais saudável.
### Discordo da regra X, você pode mudá-la?
Não. O ponto principal do `standard` é evitar [bikeshedding][bikeshedding] sobre estilos. Há vários debates online sobre tabs vs. espaços, etc., que nunca vão terminar. Esses debates apenas tiram as pessoas do foco, que deveria ser terminar seus projetos. No fim das contas você só tem que 'escolher um', e essa é a filosofia do `standard` - um monte de opiniões 'escolha um' juntadas com todo o cuidado. Espero que os usuários percebam o valor nisso ao invés de defender suas próprias opiniões.
[bikeshedding]: https://www.freebsd.org/doc/en/books/faq/misc.html#bikeshed-painting
### Mas isso não é um padrão legítimo!
Claro que não! O estilo aqui disposto não é afiliado com nenhum grupo de padrões web oficiais, e é por isso que esse repo se chama `feross/standard` e não `ECMA/standard`.
A palavra "standard" tem muito mais significado do que só "web standard" :-) Por exemplo:
- Esse módulo ajuda a manter seu código num alto *padrão de qualidade*.
- Esse módulo assegura que novos contribuíntes sigam alguns *padrões de estilo* básicos.
### Existe um formatador automático?
Sim! Você pode usar `standard --fix` para consertar a maioria dos problemas automaticamente.
`standard --fix` vem junto do `standard` (since v8.0.0) para conveniência máxima. Há muitos problemas corrigíveis, mas alguns erros, tipo não tratar erros nos callbacks do node, devem ser corrigidos manualmente.
Para economizar seu tempo, `standard` solta uma mensagem ("Run `standard --fix` to automatically fix some
problems.") quando detecta problemas que podem ser corrigidos manualmente.
Alternativamente, se seu código é feito apenas de ES5, você pode tentar usar
[`standard-format`][standard-format] (um pacote separado), mas provavlemente não vai ser mantido pois `standard --fix` funciona muito bem, e isso faz com que não precisemos manter duas ferramentas com regras de configuração separadas.
[standard-format]: https://github.com/maxogden/standard-format
### Como ignoro arquivos?
Os caminhos `node_modules/**`, `*.min.js`, `bundle.js`, `coverage/**`, pastas/arquivos escondidos (começando com `.`), e todos os arquivos nos padrões no
`.gitignore` da raiz do projeto são automaticamente ignorados.
Às vezes você precisa ignorar algumas pastas adicionais ou arquivos minificados específicos. Para fazer isso, adicione uma propriedade `standard.ignore` no `package.json`:
```json
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
```
### Como escondo um determinado aviso?
Em casos raros, você vai precisar quebrar uma regra e esconder um warning gerado pelo `standard`.
JavaScript Standard Style usa o [`eslint`](http://eslint.org/) por baixo dos panos, sendo assim, você pode esconder algum aviso da mesma forma que você faria se utilizasse `eslint` diretamente.
Para receber output verboso (para que você descubra que regra em particular precisa ignorar), execute:
```bash
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)
```
Desabilite **todas as regras** oem uma linha específica:
```js
file = 'Eu sei bem o que tô fazendo' // eslint-disable-line
```
Ou, desabilite **apenas** na regra `"no-use-before-define"`:
```js
file = 'Eu sei bem o que tô fazendo' // eslint-disable-line no-use-before-define
```
Ou, desabilite a regra `"no-use-before-define"` em **várias linhas**:
```js
/* eslint-disable no-use-before-define */
console.log('código fora do padrão...')
console.log('código fora do padrão...')
console.log('código fora do padrão...')
/* eslint-enable no-use-before-define */
```
### Eu uso uma biblioteca que polui o namespace global. Como eu previno erros de "variable is not defined"?
Alguns packages (tipo o `mocha`) colocam suas funções (tipo `describe`, `it`) no objeto global (que ruim!). Devido ao fato dessas funções não serem definidas ou chamadas via `require` em lugar algum do seu código, `standard` vai te avisar que você tá usando uma variável que não está definida (geralmente essa regra é bastante útil para pegar typos!). Mas queremos desabilitar essa função para variáveis globais.
Para fazer com que o `standard` (e outros humanos que lerão seu código) saibam que algumas variáveis são globais no seu código, adicione isso ao topo do seu arquivo:
```
/* global myVar1, myVar2 */
```
Se você possui centenas de arquivps, adicionar comentários em cada um pode ficar um saco; Nesses casos, você pode adicionar isso ao `package.json`:
```json
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
```
### Posso usar um custom parser de JS novinho em folha que saiu ontem para suporte ao ES Next?
Antes de usar um custom parser, considere se a complexidade a mais no seu código faz com que o processo valha a pena.
`standard` suporta custom JS parsers. Para usar um custom parser, instale via npm
(por exemplo: `npm install babel-eslint`) e adicione isso ao seu `package.json`:
```json
{
"standard": {
"parser": "babel-eslint"
}
}
```
Se você está usando `standard` de forma global (instalou com `-g`), você vai precisar instalar `babel-eslint` globalmente como `npm install babel-eslint -g`.
### Posso usar uma linguagem variante de JavaScript, tipo Flow?
Antes de usar uma variante de JS customizada, considere se a complexidade a mais no seu processo de construção (e os esforços necessários para conseguir contribuíntes numa velocidade boa) valem a pena.
`standard` suporta plugins de ESLint. Use um desses para transformar seu código em JavaScript válido antes que `standard` o veja. Para usar um custom parser, instale via npm (exemplo: `npm install eslint-plugin-flowtype`) e adicione isso ao seu `package.json`:
```json
{
"standard": {
"parser": "babel-eslint",
"plugins": [
"flowtype"
]
}
}
```
Se você está usando `standard` globalmente (instalou com `-g`), você também terá que instalar `eslint-plugin-flowtype` globalmente com
`npm install eslint-plugin-flowtype -g`.
### Você pode tornar regra X configurável?
Não. O objetivo do `standard` é economizar seu tempo escolhendo regras razoáveis para que você gaste seu tempo resolvendo problemas de verdade. Se você realmente quer configurar centenas de regras ESLint individualmente, você sempre pode usar `eslint` diretamente.
Se você apenas quer trocar algumas regras, considere usar
[essa configuração compartilhável](https://github.com/standard/eslint-config-standard) e jogue suas mudanças em cima.
Dica: Use `standard` e pronto. Há problemas reais que você poderia usar seu tempo resolvendo! :P
### E os Web Workers?
Adicione isso no topo do seu arquivo:
```js
/* eslint-env serviceworker */
```
Isso permite que `standard` (e outras pessoas que lerão seu código) saibam que `self` é uma global num código de web worker.
### E a respeito de Mocha, Jasmine, QUnit, etc?
Para ter suporte a mocha nos seus arquivos de teste, adicione isso no começo do seus arquivos de teste:
```js
/* eslint-env mocha */
```
Onde `mocha` pode ser `jasmine`, `qunit`, `phantomjs`, e por aí vai. Para ver a lista completa, cheque a documentação para
[especificar ambientes](http://eslint.org/docs/user-guide/configuring.html#specifying-environments) do ESLint.
Para uma lista de quais variávies globais estão disponíveis nesses ambientes, cheque o módulo npm [globals](https://github.com/sindresorhus/globals/blob/master/globals.json) .
### Existe um hook `pre-commit` para Git?
Curioso você perguntar!
```sh
#!/bin/sh
# Ensure all javascript files staged for commit pass standard code style
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi
```
Alternativamente, [overcommit](https://github.com/brigade/overcommit) é um gerenciador de ganchos Git que incluem suporte para rodar `standard` como um gancho pre-commit de Git.
Para habilitar, adicione o seguinte ao seu `.overcommit.yml`:
```yaml
PreCommit:
Standard:
enabled: true
```
### Como eu deixo o output todo coloridinho e *bonitinho*?
O output de fábrica é simples e direto, mas se você gosta de coisinhas brilhantes, instale [snazzy](https://www.npmjs.com/package/snazzy):
```
npm install snazzy
```
E rode:
```bash
$ standard --verbose | snazzy
```
Há também [standard-tap](https://www.npmjs.com/package/standard-tap),
[standard-json](https://www.npmjs.com/package/standard-json),
[standard-reporter](https://www.npmjs.com/package/standard-reporter), e
[standard-summary](https://www.npmjs.com/package/standard-summary).
## Node.js API
### `standard.lintText(text, [opts], callback)`
Aplica lint no código fornecido `text` para forçar JavaScript Standard Style. Um objeto `opts` pode ser fornecido:
```js
var opts = {
fix: false, // automaticamente corrige problemas
globals: [], // declaração de variáveis globais
plugins: [], // plugins eslint
envs: [], // ambiente eslint
parser: '' // js parser (e.g. babel-eslint)
}
```
O `callback` vai ser chamado com os objetos `Error` e `results`:
```js
var results = {
results: [
{
filePath: '',
messages: [
{ ruleId: '', message: '', line: 0, column: 0 }
],
errorCount: 0,
warningCount: 0
}
],
errorCount: 0,
warningCount: 0
}
```
### `standard.lintFiles(files, [opts], callback)`
Aplica lint nos globs `files`. Um objeto `opts` pode ser passado
```js
var opts = {
ignore: [], // globs de arquivo para ser ignorados (has sane defaults)
cwd: '', // diretório atual de trabalho (default: process.cwd())
fix: false, // corrige problemas automaticamente
globals: [], // variáveis globais para declarar
plugins: [], // plugins eslint
envs: [], // ambiente eslint
parser: '' // js parser (e.g. babel-eslint)
}
```
O `callback` vai ser chamado com os objetos `Error` e `results`:
## Contribuições
Contribuições são bem-vindas! Cheque o [issues](https://github.com/standard/standard/issues) ou os [PRs](https://github.com/standard/standard/pulls), e faça o seu próprio se quiser algo que não encontra aqui.
Junte-se ao `#standard` no freenode.
### Quero contribuir com o `standard`. Quais packages eu devo conhecer?
- **[standard](https://github.com/standard/standard)** - esse repo
- **[standard-engine](https://github.com/flet/standard-engine)** - Motor cli para regras arbritrárias de ESLint
- **[eslint-config-standard](https://github.com/standard/eslint-config-standard)** - Regras ESLint para `standard`
- **[eslint-plugin-standard](https://github.com/xjamundx/eslint-plugin-standard)** - Regras ESLint custom para `standard` (Não fazem parte do core do ESLint)
- **[eslint](https://github.com/eslint/eslint)** - O linter que move o `standard`
- **[standard-format](https://github.com/maxogden/standard-format)** - Formatador de código automático
- **[snazzy](https://github.com/standard/snazzy)** - Output de terminal bonitinho
- **[standard-www](https://github.com/standard/standard-www)** - código do https://standardjs.com
- **[semistandard](https://github.com/Flet/semistandard)** - standard, com ponto-e-vírgula (se você precisar)
Há vários **[plugins de editores](#text-editor-plugins)**, uma lista de
**[packages que usam `standard`](https://github.com/standard/standard-packages)**,
e uma awesome list de
**[packages do ecossistema `standard` ](https://github.com/standard/awesome-standard)**.
## License
[MIT](LICENSE). Copyright (c) [Feross Aboukhadijeh](http://feross.org).
================================================
FILE: docs/README-zhcn.md
================================================
<h1 align="center">
<a href="https://standardjs.com"><img src="https://cdn.rawgit.com/feross/standard/master/sticker.svg" alt="Standard - JavaScript 代码规范" width="200"></a>
<br>
JavaScript Standard Style
<br>
<br>
</h1>
<p align="center">
<a href="https://travis-ci.org/feross/standard"><img src="https://img.shields.io/travis/feross/standard/master.svg" alt="travis"></a>
<a href="https://www.npmjs.com/package/standard"><img src="https://img.shields.io/npm/v/standard.svg" alt="npm version"></a>
<a href="https://www.npmjs.com/package/eslint-config-standard"><img src="https://img.shields.io/npm/dm/eslint-config-standard.svg" alt="npm downloads"></a>
<a href="https://standardjs.com"><img src="https://img.shields.io/badge/code_style-standard-brightgreen.svg" alt="Standard - JavaScript Style Guide"></a>
</p>
<h4 align="center">One JavaScript Style to Rule Them All</h4>
<p align="center">
<a href="README-en.md">English</a> •
<a href="README-esla.md">Español (Latinoamérica)</a> •
<a href="README-iteu.md">Italiano (Italian)</a> •
<a href="README-kokr.md">한국어 (Korean)</a> •
<a href="README-ptbr.md">Português (Brasil)</a> •
<a href="README-zhcn.md">简体中文 (Simplified Chinese)</a> •
<a href="README-zhtw.md">繁體中文 (Taiwanese Mandarin)</a>
</p>
<br>
## JavaScript 代码规范，自带 linter & 代码自动修正
本工具通过以下三种方式为你（及你的团队）节省大量时间：
- **无须配置。** 史上最便捷的统一代码风格的方式，轻松拥有。
- **自动代码格式化。** 只需运行 `standard --fix` 从此和脏乱差的代码说再见。
- **提前发现风格及程序问题。** 减少代码审查过程中反反复复的修改过程，节约时间。
无须犹豫。再也不用维护 `.eslintrc`, `.jshintrc`, or `.jscsrc` 。开箱即用。
安装：
```
npm install standard --save-dev
```
## 细则
- **使用两个空格** – 进行缩进
- **字符串使用单引号** – 需要转义的地方除外
- **不再有冗余的变量** – 这是导致 *大量* bug 的源头!
- **无分号** – [这][1][没什么不好。][2][不骗你！][3]
- **行首不要以 `(`, `[`, or `` ` `` 开头**
- 这是省略分号时**唯一**会造成问题的地方 – *工具里已加了自动检测！*
- [详情][4]
- **关键字后加空格** `if (condition) { ... }`
- **函数名后加空格** `function name (arg) { ... }`
- 坚持使用全等 `===` 摒弃 `==` 一但在需要检查 `null || undefined` 时可以使用 `obj == null`。
- 一定要处理 Node.js 中错误回调传递进来的 `err` 参数。
- 使用浏览器全局变量时加上 `window` 前缀 – `document` 和 `navigator` 除外
- 避免无意中使用到了这些命名看上去很普通的全局变量， `open`, `length`,
`event` 还有 `name`。
- **[查看更多][5]** – *为何不试试 `standard` 规范呢！*
[1]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
[2]: http://inimino.org/~inimino/blog/javascript_semicolons
[3]: https://www.youtube.com/watch?v=gsfbh17Ax9I
[4]: RULES-zhcn.md#semicolons
[5]: RULES-zhcn.md#javascript-standard-style
说了那么多，看看[这个遵循了 Standard 规范的示例文件](https://github.com/expressjs/body-parser/blob/master/index.js) 中的代码吧。或者，这里还有[一大波使用了此规范的项目](https://raw.githubusercontent.com/feross/standard-packages/master/all.json) 代码可供参考。
## 目录
- 上手
- [安装](#install)
- [使用](#usage)
- [如果你聪明的话会这样做](#what-you-might-do-if-youre-clever)
- FAQ
- [为何要使用 JavaScript Standard 规范？](#why-should-i-use-javascript-standard-style)
- [谁在用 JavaScript Standard 规范？](#who-uses-javascript-standard-style)
- [有现成的编辑器插件吗？](#are-there-text-editor-plugins)
- [有专属徽章可以用来放到项目的 README 文件中吗？](#is-there-a-readme-badge)
- [如果我不同意某条规则，可以改吗？](#i-disagree-with-rule-x-can-you-change-it)
- [毕竟这不是一份正式的 Web 规范啊！](#but-this-isnt-a-real-web-standard)
- [有自动格式化工具么？](#is-there-an-automatic-formatter)
- [如何排除某些文件？](#how-do-i-ignore-files)
- [如何隐藏某类警告？](#how-do-i-hide-a-certain-warning)
- [使用的三方插件向全局暴露了变量，如何避免 "variable is not defined" 的错误提示？](#i-use-a-library-that-pollutes-the-global-namespace-how-do-i-prevent-variable-is-not-defined-errors)
- [如何才能使用处于实验阶段的 JavaScript 特性（譬如 ES Next）？](#how-do-i-use-experimental-javascript-es-next-features)
- [我能使用其他 JavaScript 变种吗，例如 Flow？](#can-i-use-a-javascript-language-variant-like-flow)
- [如何与 Mocha，Jasmine 和 QUnit 这些测试工具搭配工作?](#what-about-mocha-jasmine-qunit-etc)
- [Web Workers 有考虑过么？](#what-about-web-workers)
- [Markdown 或者 HTML 文件中的代码能检查到吗？](#can-i-check-code-inside-of-markdown-or-html-files)
- [有为 git 添加 `pre-commit` 钩子么？](#is-there-a-git-pre-commit-hook)
- [怎样使输出好看些，带颜色？](#how-do-i-make-the-output-all-colorful-and-pretty)
- [有相关的 Node.js API 没？](#is-there-a-nodejs-api)
- [如何参与到 `standard` 规范中来？](#how-do-i-contribute-to-standard)
- [协议](#license)
## 安装
使用本规范最便捷的方式是全局安装，运行：
```bash
$ npm install standard --global
```
或者非全局的方式，针对某个项目进行安装：
```bash
$ npm install standard --save-dev
```
*注意：运行以上命令的前提是已经安装了 [Node.js](http://nodejs.org) 和 [npm](https://npmjs.com) 。*
## 使用
安装完就可以开心使用了。最简单的使用场景是检查项目内所有的 JavaScript 文件：
```bash
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
可以跟上 glob 形式的路径参数，但记得带引号以确保 `standard` 工具正确解析，否则会被命令行解析。
```bash
$ standard "src/util/**/*.js" "test/**/*.js"
```
**注意：** `standard` 默认查找 `**/*.js`, `**/*.jsx` 所匹配到的文件。
## 如果你聪明的话会这样做
1. 添加配置到 `package.json`
```json
{
"name": "my-cool-package",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}
```
2. 这样检查工作就会在运行 `npm test` 自动进行
```bash
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
```
3. 从此告别在提 PR 时的代码风格的问题！
## 为何要使用 JavaScript Standard 规范？
本规范特点之一是简洁。谁也不想为每个项目维护一份有成百上千行语句的代码风格配置文件。有此规范就够了。
本工具通过以下三种方式为你（及你的团队）节省大量时间：
- **无须配置。** 史上最便捷的统一代码风格的方式，轻松拥有。
- **自动的代码格式化。** 只需运行 `standard --fix` 从此和脏乱差的代码说再见。
- **提前发现风格及程序问题。** 减少代码审查时的反反复复修改过程，节约时间。
一旦使用 `standard` 规范表明代码的简明性及社区的约定要高于个人的编码风格。这不一定100%适用于所有项目和多元的编程文化，但开源项目代码容易受到新手的影响。把规范讲明，严格执行对于项目的长远维护不无裨益。
## 谁在用 JavaScript Standard 规范？
我们是有群众基础的！
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/npm.png>](https://www.npmjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/github.png>](https://github.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/opbeat.png>](https://opbeat.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nearform.png>](http://www.nearform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/brave.png>](https://www.brave.com) |
|---|---|---|---|---|
| [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zeit.png>](https://zeit.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zendesk.png>](https://www.zendesk.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/mongodb.jpg>](https://www.mongodb.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/typeform.jpg>](https://www.typeform.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/gov-uk.png>](https://gds.blog.gov.uk) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/express.png>](http://expressjs.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/webtorrent.png>](https://webtorrent.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/ipfs.png>](https://ipfs.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/dat.png>](https://datproject.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bitcoinjs.png>](https://bitcoinjs.org) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/atom.png>](https://atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/electron.png>](http://electron.atom.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/voltra.png>](https://voltra.co) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/treasuredata.png>](https://www.treasuredata.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/clevertech.png>](https://clevertech.biz) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/studynotes.jpg>](https://www.apstudynotes.org) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/optiopay.png>](https://www.optiopay.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/jaguar-landrover.png>](https://www.jlrtechincubator.com/jlrti/) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/bustle.jpg>](https://www.bustle.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/zentrick.png>](https://www.zentrick.com) |
|---|---|---|---|---|
[<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/nodesource.png>](https://nodesource.com) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/greenkeeper.png>](https://greenkeeper.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/karma.png>](https://karma-runner.github.io) | [<img width=150 src=https://cdn.rawgit.com/feross/standard/master/docs/logos/taser.png>](https://www.taser.com) |
|---|---|---|---|
除公司组织外，[很多个人](https://raw.githubusercontent.com/feross/standard-packages/master/all.json)也在项目中使用，这里就不一一罗列了。
并且 `standard` 在 GitHub 的[代码检查类工具](https://github.com/showcases/clean-code-linters) 展示列表中也排名第一。
## 有现成的编辑器插件吗？
首先安装 `standard`。剩下的就是不同编译器安装对应的插件：
### Sublime Text
通过 **[Package Control][sublime-1]**，安装 **[SublimeLinter][sublime-2]** 和
**[SublimeLinter-contrib-standard][sublime-3]**。
如果想要保存时自动格式化，还需安装 **[StandardFormat][sublime-4]**。
[sublime-1]: https://packagecontrol.io/
[sublime-2]: http://www.sublimelinter.com/en/latest/
[sublime-3]: https://packagecontrol.io/packages/SublimeLinter-contrib-standard
[sublime-4]: https://packagecontrol.io/packages/StandardFormat
### Atom
安装 **[linter-js-standard][atom-1]**。
如果想要保存时自动格式化，还需安装 **[standard-formatter][atom-2]**。安装 **[standardjs-snippets][atom-3]** 可以获得 snippets 特性。
[atom-1]: https://atom.io/packages/linter-js-standard
[atom-2]: https://atom.io/packages/standard-formatter
[atom-3]: https://atom.io/packages/standardjs-snippets
### Visual Studio Code
安装 **[vscode-standardjs][vscode-1]**（已经包含了自动格式化）。
安装 **[vscode-standardjs-snippets][vscode-2]** 以获得 JS snippets。安装 **[vscode-react-standard][vscode-3]** 以获得 React snippets。
[vscode-1]: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs
[vscode-2]: https://marketplace.visualstudio.com/items?itemName=capaj.vscode-standardjs-snippets
[vscode-3]: https://marketplace.visualstudio.com/items/TimonVS.ReactSnippetsStandard
### Vim
安装 **[Syntastic][vim-1]** 并添加如下配置到 `.vimrc`：
```vim
let g:syntastic_javascript_checkers = ['standard']
```
如果想要保存时自动格式化，添加以下配置到 `.vimrc`：
```vim
autocmd bufwritepost *.js silent !standard --fix %
set autoread
```
[vim-1]: https://github.com/scrooloose/syntastic
### Emacs
安装 **[Flycheck][emacs-1]** 后查看 **[manual][emacs-2]** 以了解如何在项目在启用。
[emacs-1]: http://www.flycheck.org
[emacs-2]: http://www.flycheck.org/en/latest/user/installation.html
### Brackets
插件中搜索 **["Standard Code Style"][brackets-1]** 然后点击 "Install"。
[brackets-1]: https://github.com/ishamf/brackets-standard/
### WebStorm (PhpStorm, IntelliJ, RubyMine, JetBrains 等 jetbrains 全家桶系列)
WebStorm [最近宣布](https://blog.jetbrains.com/webstorm/2017/01/webstorm-2017-1-eap-171-2272/)在其 IDE 中
自带 `standard` 规范。
但是如果你仍然想自己动手配置，[那么请看此教程][webstorm-1]。此教程适用于 JetBrains 全家桶，包括 PhpStorm、IntelliJ、RubyMine 等。
[webstorm-1]: docs/webstorm.md
## 有专属徽章可以用来放到项目的 README 文件中吗？
必需的！如果你的项目使用了 `standard` 规范，可以任选一个下面的徽章放入项目中来进行展示。
[](https://github.com/standard/standard)
```md
[](https://github.com/standard/standard)
```
[](https://standardjs.com)
```md
[](https://standardjs.com)
```
## 如果我不同意某条规则，可以改吗？
不行。制定这套 `standard` 规范的目的就是让大家都不必再花时间浪费在[无谓的][bikeshedding]代码风格之争上面了。关于缩进该用制表符还是空格这个问题已经争论了很久了，永远也没有答案。争论这个都可以把需求提前写完了。遵循 `standard` 规范，你就不用再犹豫了，毕竟不管怎样争论总归会选择一种风格的。希望大家也能在个人语义和普适价值上做一个权衡。
如果你非要自己去配置成百上千项的 ESLint 规则，那你可以直接使用
[eslint-config-standard](https://github.com/standard/eslint-config-standard) 来将个人配置包装在上层。
小贴士：选择 `standard` 然后保持吧。把时间留下来解决其他有意义的问题！\(^____^)/
[bikeshedding]: https://www.freebsd.org/doc/en/books/faq/misc.html#bikeshed-painting
## 毕竟这不是一份正式的 Web 规范啊！
确实！这份规范不隶属于任何官方组织，所以才叫 `feross/standard` 而不是 `ECMA/standard` 嘛。
而 `standard` (标准) 一词在这里不局限于 “web 标准” :-) 。 举个例子：
- 这个模块帮助我们将代码维持在一个*高的水准（standard of quality）*
- 这个模块确定项目中的新手遵循一些基本的*样式规范（style standards）*
## 有自动格式化工具么？
当然！你可以使用 `standard --fix` 来纠正大部分的代码问题。
`standard --fix` 可以修正大部分约定俗成的问题，但有些错误（譬如忘记了错误处理）只能手动去修复了。
为了使用方便，`standard` 会在检测到有能够自动被修复的问题的时候，给出相应的提示 "`运行 standard --fix 来自动修正一些问题`"。
## 如何排除某些文件？
`node_modules/`、`coverage/`、`vendor/`、`*.min.js`、`bundle.js` 这些目录，还有以 `.` 开头的文件（譬如 `.git/`）或者文件夹自动被排除在外。
`.gitignore` 里配置的文件也会自动排除掉。
有时你还是需要添加一些自定义的排除文件，可以在 `package.json` 里添加 `standard.ignore` 属性来配置：
```json
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
```
## 如何隐藏某类警告？
很少的情况下你需要绕开 `standard` 以隐藏某些警告信息。
JavaScript Standard 代码规范底层使用的是 [ESLint](http://eslint.org/)。所以如果你想隐藏某些警告，方法和使用 ESLint 时一样。
打印详细信息（这样你就能找到你想隐藏的警告在配置中对应的名称了）：
```bash
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)
```
对某一行禁用**所有规则**：
```js
file = 'I know what I am doing' // eslint-disable-line
```
或者，**只禁**用 `"no-use-before-define"` 这条规则：
```js
file = 'I know what I am doing' // eslint-disable-line no-use-before-define
```
或者，对**多行**禁用 `"no-use-before-define"` 这一规则：
```js
/* eslint-disable no-use-before-define */
console.log('offending code goes here...')
console.log('offending code goes here...')
console.log('offending code goes here...')
/* eslint-enable no-use-before-define */
```
## 使用的三方插件向全局暴露了变量，如何避免 "variable is not defined" 的错误提示？
一些三方库（比如 `mocha`）会向全局暴露变量（`describe`、`it`）。这些变量或方法即没有定义，也没有被 `require` 进来，所以 `standard` 会报出变量未定义的警告（这种警告通常情况下是很有用的）。这种情况下我们想对这些全局变量禁用检查。
为了让 `standard` 检测通过（同时也使代码更加易懂），在文件顶部添加如下配置：
```js
/* global myVar1, myVar2 */
```
但如果你需要添加的文件太多，这种方式就显得繁琐了。这种情况下，运行：
```bash
$ standard --global myVar1 --global myVar2
```
或者在 `package.json` 里配置：
```json
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
```
*注意：`global` 和 `globals` 效果一样*
## 如何才能使用处于实验阶段的 JavaScript 特性（譬如 ES Next）？
`standard` 支持最新的 ECMAScript 特性，ES8（ES2017），包括处于 “Stage 4” 仍在提案阶段的特性。
为了支持实验性的特性，`standard` 支持自定义 JavaScript 解析器。添加自定义解析器前请思考一下必要性。
从 npm 安装并使用自定义的解析器（示例：`npm install babel-eslint`）：
```bash
$ standard --parser babel-eslint
```
或者将其添加到 `package.json` 配置中：
```json
{
"standard": {
"parser": "babel-eslint"
}
}
```
如果全局安装（`npm install standard --global`）了 `standard` 的话，那么请确保 `babel-eslint` 也用 `npm install babel-eslint --global` 全局安装。
## 我能使用其他 JavaScript 变种吗，例如 Flow？
同样地，想要使用一个 JS 变种之前，先考虑添加和使用它所带来的复杂度看是否值得这么去做。
`standard` 支持 ESLint 插件。在 `standard` 处理代码前，使用任何一个插件来将代码编译成合法的 JS 即可。 从 npm 安装一个自定义的解析器 (示例：`npm install eslint-plugin-flowtype`) 然后运行：
```bash
$ standard --plugin flowtype
```
或者添加到`package.json`:
```json
{
"standard": {
"plugins": [ "flowtype" ]
}
}
```
如果全局安装（`npm install standard --global`）了 `standard` 的话，那么请确保 `eslint-plugin-flowtype` 也用 `npm install eslint-plugin-flowtype --global` 全局安装。
*注意：`plugin` 和 `plugins` 等价*
## 如何与 Mocha，Jasmine 和 QUnit 这些测试工具搭配工作?
为了能让 mocha 在你的测试文件中工作，将以下配置添加到测试文件头部：
```js
/* eslint-env mocha */
```
或者运行：
```bash
$ standard --env mocha
```
上面 `mocha` 也可以是 `jasmine`, `qunit`, `phantomjs` 等同类工具。这里有个来自 ESLint 的完整列表
[环境配置](http://eslint.org/docs/user-guide/configuring.html#specifying-environments)
文档。环境中所有可用的全局变量可以这个
[globals](https://github.com/sindresorhus/globals/blob/master/globals.json) npm 包中查到。
*注意: `env` 与 `envs` 用哪个都一样。*
## Web Workers 有考虑过么？
添加以下注释到文件头部：
```js
/* eslint-env serviceworker */
```
这样可以让 `standard` 知道 `self` 是 web worker 中的全局变量（同时也让人更容易看懂）。
## Markdown 或者 HTML 文件中的代码能检查到吗？
可以使用 [`standard-markdown`](https://www.npmjs.com/package/standard-markdown) 来检查 Markdown 里的区位码。
此外，也有 ESLint 插件可以检查 Markdown、HTML 等其他类型文件中的代码：
检查 Markdown 文件中的代码，可以用这个 ESLint 插件：
```bash
$ npm install eslint-plugin-markdown
```
然后运行以下命令来检查文件代码块中的代码：
```bash
$ standard --plugin markdown '**/*.md'
```
HTML 文件可以下面这个插件：
```bash
$ npm install eslint-plugin-html
```
然后运行以下命令来检查包含在 `<script>` 标签中的代码：
```bash
$ standard --plugin html '**/*.html'
```
## 有为 git 添加 `pre-commit` 钩子么？
这个问题问得好！
```sh
#!/bin/sh
# 确保将要提交的所有 JavaScript 代码通过 standard 规范的检查
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi
```
## 怎样使输出好看些，带颜色？
自带的输出信息简洁原始，如果想要炫酷好看，安装 [snazz
gitextract_6yufa38k/
├── .gitignore
├── .npmignore
├── .travis.yml
├── AUTHORS.md
├── CHANGELOG.md
├── CONTRIBUTING.md
├── LICENSE
├── README.md
├── RULES.md
├── bin/
│ ├── cmd.js
│ └── update-authors.sh
├── docs/
│ ├── README-en.md
│ ├── README-esla.md
│ ├── README-iteu.md
│ ├── README-kokr.md
│ ├── README-ptbr.md
│ ├── README-zhcn.md
│ ├── README-zhtw.md
│ ├── RULES-en.md
│ ├── RULES-esla.md
│ ├── RULES-iteu.md
│ ├── RULES-kokr.md
│ ├── RULES-ptbr.md
│ ├── RULES-zhcn.md
│ ├── RULES-zhtw.md
│ └── webstorm.md
├── eslintrc.json
├── index.js
├── options.js
├── package.json
└── test/
├── api.js
├── clone.js
└── cmd.js
Condensed preview — 33 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (486K chars).
[
{
"path": ".gitignore",
"chars": 19,
"preview": "node_modules/\ntmp/\n"
},
{
"path": ".npmignore",
"chars": 117,
"preview": "test/\ndocs/logos/\ntmp/\nbin/update-authors.sh\n.travis.yml\nbadge.png\nbadge.svg\nCONTRIBUTING.md\nsticker.png\nsticker.svg\n"
},
{
"path": ".travis.yml",
"chars": 54,
"preview": "language: node_js\nnode_js:\n - '4'\n - '6'\n - 'node'\n"
},
{
"path": "AUTHORS.md",
"chars": 2485,
"preview": "# Authors\n\n#### Ordered by first contribution.\n\n- Feross Aboukhadijeh (feross@feross.org)\n- Jonny Buchanan (jonathan.buc"
},
{
"path": "CHANGELOG.md",
"chars": 30683,
"preview": "# Change Log\n\nAll notable changes to this project will be documented in this file.\nThis project adheres to [Semantic Ver"
},
{
"path": "CONTRIBUTING.md",
"chars": 3197,
"preview": "# Contributing Guidelines\n\nContributions welcome!\n\n**Before spending lots of time on something, ask for feedback on your"
},
{
"path": "LICENSE",
"chars": 1072,
"preview": "The MIT License (MIT)\n\nCopyright (c) Jed Watson\n\nPermission is hereby granted, free of charge, to any person obtaining a"
},
{
"path": "README.md",
"chars": 4418,
"preview": "<h4 align=\"center\">One Style You Might Like</h4>\n\n[![travis][travis-image]][travis-url]\n[![npm][npm-image]][npm-url]\n[](http"
},
{
"path": "bin/cmd.js",
"chars": 241,
"preview": "#!/usr/bin/env node\n\nif (process.version.match(/v(\\d+)\\./)[1] < 4) {\n\tconsole.error('happiness: Node v4 or greater is re"
},
{
"path": "bin/update-authors.sh",
"chars": 573,
"preview": "#!/bin/sh\n# Update AUTHORS.md based on git history.\n\ngit log --reverse --format='%aN (%aE)' | perl -we '\nBEGIN {\n %seen"
},
{
"path": "docs/README-en.md",
"chars": 29275,
"preview": "<h1 align=\"center\">\n <a href=\"https://standardjs.com\"><img src=\"https://cdn.rawgit.com/standard/standard/master/sticker"
},
{
"path": "docs/README-esla.md",
"chars": 28017,
"preview": "<h1 align=\"center\">\n <a href=\"https://standardjs.com\"><img src=\"https://cdn.rawgit.com/feross/standard/master/sticker.s"
},
{
"path": "docs/README-iteu.md",
"chars": 30802,
"preview": "<h1 align=\"center\">\n <a href=\"https://standardjs.com\"><img src=\"https://cdn.rawgit.com/feross/standard/master/sticker.s"
},
{
"path": "docs/README-kokr.md",
"chars": 22978,
"preview": "<h1 align=\"center\">\n <a href=\"https://standardjs.com\"><img src=\"https://cdn.rawgit.com/feross/standard/master/sticker.s"
},
{
"path": "docs/README-ptbr.md",
"chars": 23143,
"preview": "<h1 align=\"center\">\n <a href=\"https://standardjs.com\"><img src=\"https://cdn.rawgit.com/feross/standard/master/sticker.s"
},
{
"path": "docs/README-zhcn.md",
"chars": 20026,
"preview": "<h1 align=\"center\">\n <a href=\"https://standardjs.com\"><img src=\"https://cdn.rawgit.com/feross/standard/master/sticker.s"
},
{
"path": "docs/README-zhtw.md",
"chars": 18366,
"preview": "<h1 align=\"center\">\n <a href=\"https://standardjs.com\"><img src=\"https://cdn.rawgit.com/feross/standard/master/sticker.s"
},
{
"path": "docs/RULES-en.md",
"chars": 32507,
"preview": "# JavaScript Standard Style\n\n<p align=\"center\">\n <a href=\"RULES-en.md\">English</a> •\n <a href=\"RULES-esla.md\">Español "
},
{
"path": "docs/RULES-esla.md",
"chars": 33640,
"preview": "# JavaScript Standard Style\n\n<p align=\"center\">\n <a href=\"RULES-en.md\">English</a> •\n <a href=\"RULES-esla.md\">Español "
},
{
"path": "docs/RULES-iteu.md",
"chars": 33790,
"preview": "# JavaScript Standard Style\n\n<p align=\"center\">\n <a href=\"RULES-en.md\">English</a> •\n <a href=\"RULES-esla.md\">Español "
},
{
"path": "docs/RULES-kokr.md",
"chars": 29302,
"preview": "# JavaScript Standard Style\n\n<p align=\"center\">\n <a href=\"RULES-en.md\">English</a> •\n <a href=\"RULES-esla.md\">Español "
},
{
"path": "docs/RULES-ptbr.md",
"chars": 8629,
"preview": "# JavaScript Standard Style\n\n<p align=\"center\">\n <a href=\"RULES-en.md\">English</a> •\n <a href=\"RULES-esla.md\">Español "
},
{
"path": "docs/RULES-zhcn.md",
"chars": 27728,
"preview": "# JavaScript Standard Style\n\n<p align=\"center\">\n <a href=\"RULES-en.md\">English</a> •\n <a href=\"RULES-esla.md\">Español "
},
{
"path": "docs/RULES-zhtw.md",
"chars": 27831,
"preview": "# JavaScript Standard Style\n\n<p align=\"center\">\n <a href=\"RULES-en.md\">English</a> •\n <a href=\"RULES-esla.md\">Español "
},
{
"path": "docs/webstorm.md",
"chars": 3653,
"preview": "# [WebStorm][webstorm-1] configuration for Standard Style\n\n## Native support for `standard`\n\nWebStorm [recently announce"
},
{
"path": "eslintrc.json",
"chars": 48,
"preview": "{\n \"extends\": [\"happiness\", \"happiness-jsx\"]\n}\n"
},
{
"path": "index.js",
"chars": 117,
"preview": "var Linter = require('standard-engine').linter;\nvar opts = require('./options');\n\nmodule.exports = new Linter(opts);\n"
},
{
"path": "options.js",
"chars": 341,
"preview": "var eslint = require('eslint');\nvar path = require('path');\nvar pkg = require('./package.json');\n\nmodule.exports = {\n\tbu"
},
{
"path": "package.json",
"chars": 2265,
"preview": "{\n \"name\": \"happiness\",\n \"description\": \"JavaScript Happiness Style\",\n \"version\": \"10.0.2\",\n \"author\": {\n \"email\""
},
{
"path": "test/api.js",
"chars": 619,
"preview": "var standard = require('../');\nvar test = require('tape');\n\ntest('api: lintFiles', function (t) {\n\tt.plan(3);\n\tstandard."
},
{
"path": "test/clone.js",
"chars": 3579,
"preview": "/**\n * Clones several projects that are known to follow \"JavaScript Standard Style\" and runs\n * the `standard` style che"
},
{
"path": "test/cmd.js",
"chars": 409,
"preview": "var path = require('path');\nvar test = require('tape');\nvar crossSpawn = require('cross-spawn');\n\nvar CMD_PATH = path.jo"
}
]
About this extraction
This page contains the full source code of the JedWatson/happiness GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 33 files (413.9 KB), approximately 134.9k tokens. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.