English • Español (Latinoamérica) • Français • Bahasa Indonesia • Italiano (Italian) • 日本語 (Japanese) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin)
このモジュールは、3つの方法であなたの（そして他の人の！）時間を節約します。：
- 設定不要 プロジェクトのコード品質を高める最も簡単な方法です。決断はいりません。管理するための
.eslintrcファイルも不要です。ただこれだけで動作します。 - コードを自動的にフォーマット ただ
standard --fixを実行するだけで、汚いコードや一貫性のないコードにサヨナラしましょう。 - スタイルの問題やプログラマーのエラーを早期にキャッチ レビュアーと作業者の間の往復をなくすことで、貴重なコードレビューの時間を節約します。
今すぐnpx standard --fixを実行して、試してみましょう！
- クイックスタート
- FAQ
- なぜJavaScript Standard Styleを使うべきなのですか？
- 誰がJavaScript Standard Styleを使用していますか？
- テキストエディタのプラグインはありますか？
- readme用のバッジはありますか？
- 私はあるルールに反対なのですが、変更してもらえますか？
- でもこれは本当のウェブ標準ではありません！
- 自動フォーマッターはありますか？
- ファイルを無視するには？
- ルールを無効にするには？
- 私はグローバル名前空間を汚染するライブラリを使用しています。"variable is not defined"というエラーを防ぐには？
- 実験的なJavaScriptの機能（ES Next）を使用するには？
- FlowやTypeScriptのようなJavaScriptの代替言語を使用できますか？
- Mocha、Jest、Jasmine、QUnitなどはどうすれば？
- Web WorkersとService Workersはどうすれば？
- 警告とエラーの違いは？
- MarkdownやHTMLファイル内のコードをチェックできますか？
- Gitの
pre-commitフックはありますか？ - 出力をすべてカラフルで綺麗にするには？
- Node.jsのAPIはありますか？
- StandardJSにコントリビュートするには？
JavaScript Standard Styleを使用する最も簡単な方法は、Nodeのコマンドラインプログラムとしてグローバルインストールすることです。ターミナルで次のコマンドを実行してください。：
$ npm install standard --globalまたは、standardを一つのプロジェクトで使うためにローカルインストールできます。：
$ npm install standard --save-dev注：上記のコマンドを実行するには、Node.jsとnpmがインストールされている必要があります。
standardをインストールしたら、standardプログラムが使用できるはずです。最もシンプルな使用例は、現在の作業ディレクトリ内のすべてのJavaScriptファイルのスタイルをチェックすることです。：
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.standardをローカルにインストールした場合は、かわりにnpxで実行します。:
$ npx standardglobパターンを用いてディレクトリを渡すこともできます。globパターンを含むパスは、シェルではなくstandardで展開されるようにクォートで囲んでください。：
$ standard "src/util/**/*.js" "test/**/*.js"注： デフォルトでは、standardは次のパターンに一致するすべてのファイルを探索します。：**/*.js、**/*.jsx
- 以下を
package.jsonに追加します
{
"name": "my-cool-package",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}- スタイルは
npm testを実行する際に自動的にチェックされます
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.- もう二度とプルリクエストでスタイルのフィードバックをさせないでください！
JavaScript Standard Styleの美しさは、シンプルなことです。作業しているすべてのモジュール/プロジェクトのために、数百行のスタイル設定ファイルをいくつも管理したい人はいません。こんな狂気はもうたくさんです！
このモジュールは、3つの方法であなた（と他の人！）の時間をセーブします。：
- 設定なし プロジェクトに一貫性のあるスタイルを適用する最も簡単な方法です。
- コードを自動的にフォーマット ただ
standard --fixを実行し、汚いコードや一貫性のないコードにサヨナラしましょう。 - スタイルの問題やプログラマーのエラーを早期にキャッチ レビュアーと作業者の間の往復をなくすことで、貴重なコードレビューの時間をセーブします。
standardなスタイルを採用することは、個人のスタイルよりもコードの明確さやコミュニティの慣習を重要視することを意味します。これはプロジェクトと開発文化にとって100%意義があるわけではありませんが、オープンソースは初学者には適さない場所になりえます。コントリビューターの期待を明確にすることで、プロジェクトがより健全な状態になります。
より詳しくは、"Write Perfect Code with Standard and
ESLint"をご覧ください。このトークでは、リントについて、standardとeslintの使い分けについて、そしてprettierとの比較について学ぶことができます。
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
 |
 |
 |
|---|
 |
Your logo here | Your logo here | Your logo here |
|---|
企業に加えて、多くのコミュニティメンバーがここに載せるには多すぎるパッケージでstandardを使用しています。
standardは、GitHubのClean Code Linterにおいて最もスターの多いリンターでもあります。
まず、standardをインストールしてください。それから、あなたのエディタに適したプラグインをインストールしてください。
Package Control を用いて、 SublimeLinter と SublimeLinter-contrib-standard をインストールしてください。
保存時に自動でフォーマットするには、 StandardFormat をインストールしてください。
linter-js-standard をインストールしてください。
あるいは、 linter-js-standard-engine をインストールしてもよいでしょう。バンドルされたstandardのバージョンではなく、プロジェクトにインストールされているバージョンが自動的に使用されます。 また、 standard-engine を元にした他のリンターでも動作します。
自動フォーマットには、 standard-formatter をインストールしてください。スニペットには、 standardjs-snippets をインストールしてください。
vscode-standard をインストールしてください（自動フォーマットもサポートしています）。
JavaScriptのスニペットには、 vscode-standardjs-snippets をインストールしてください。Reactのスニペットには、 vscode-react-standard をインストールしてください。
ale をインストールしてください。そして、次の行を.vimrcファイルに追加してください。
let g:ale_linters = {
\ 'javascript': ['standard'],
\}
let g:ale_fixers = {'javascript': ['standard']}これは、standardをJavaScriptファイルのための唯一のリンターとして設定し、eslintとの競合を防ぎます。保存時に自動でリントと修正を行なうには、次の行を.vimrcに追加してください。：
let g:ale_lint_on_save = 1
let g:ale_fix_on_save = 1考慮すべき他のプラグインにはneomakeやsyntasticがあり、いずれもstandardのビルトインサポートを備えています（設定が必要かもしれませんが）。
Flycheck をインストールし、プロジェクトで有効にする方法については マニュアル を参照してください。
extension registryで "Standard Code Style" を検索し、"Install"をクリックしてください。
WebStormでは、IDEでstandardがネイティブサポートされるようになりました。
standardを手動で設定したい場合、こちらのガイドに従ってください。これは、PhpStorm、IntelliJ、RubyMineなど、すべてのJetBrains製品に適用されます。
はい！プロジェクトでstandardを使っているなら、コードがstandardスタイルを使用していることを示すためにこれらのバッジをreadmeに含めることができます。
[](https://github.com/standard/standard)[](https://standardjs.com)いいえ。standardのすべては、スタイルについてのbikeshedding（自転車置き場の議論）を避けることであなたの時間をセーブするためにあります。タブ対スペースについてのような議論はオンライン上にたくさんありますが、決して結論は出ません。これらの議論はただ物事を終わらせることから目を逸らさせるだけです。結局のところ、あなたは何かを選ばなければなりません。これは、standardの哲学のすべてです。うまくいけば、ユーザーは自身の意見を守るうえでその価値に気づくでしょう。
standardを完全には受け入れたくない人のために、似たようなパッケージが2つあります:
- semistandard - セミコロンありのstandard
- standardx - カスタマイズ可能なstandard
本当に何百ものESLintのルールを個別に設定したいなら、ルールを上書きするためにeslint-config-standardでeslintを直接使うことができます。standard-ejectは、standardからeslintとeslint-config-standardへの移行を支援します。
Pro tip: ただstandardを使っていってください。時間をかけて解決すべき現実の問題があるでしょう！ :P
もちろん違います！ここに記載されたルールはいかなるウェブ標準グループにも属していません。これは、このリポジトリがstandard/standardであり、、ECMA/standardではないゆえんです。
"standard"という言葉には、単なる"ウェブ標準"よりも多くの意味があります。 :-) たとえば：
- このモジュールは、コードを高い品質基準に保つのに役立ちます。
- このモジュールは、新たなコントリビューターがいくつかの基本的なスタイル基準に従うことを保証します。
はい！ ほとんどの問題を自動的に修正するために、standard --fixが使えます。
standard --fixは、最大限の利便性のためにstandardにビルトインされています。ほとんどの問題は修正可能ですが、いくつかのエラー（エラーのハンドルし忘れなど）は手動で修正する必要があります。
時間をセーブするために、standardは自動的に修正可能な問題を検出すると"Run standard --fix to automatically fix some problems"というメッセージを出力します。
特定のパス（node_modules/、coverage/、vendor/、*.min.js、.git/のようなドットファイル）は自動的に無視されます。
プロジェクトルートの.gitignoreファイルに記載されているパスも自動的に無視されます。
ときには、追加のフォルダや特定の縮小ファイルを無視する必要があるでしょう。そのためには、package.jsonにstandard.ignoreプロパティを追加してください。：
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}まれにルールを破り、standardによって生成されたエラーを非表示にする必要があるでしょう。
JavaScript Standard Styleは内部でESLintを使用していますが、ESLintを直接使用した場合、通常どおりエラーを非表示にすることができます。
（無視するルール名を見つけるために）詳細な出力を得るには：
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)特定の行の すべてのルール を無効にするには：
file = 'I know what I am doing' // eslint-disable-lineあるいは、"no-use-before-define"ルール のみ を無効にするには：
file = 'I know what I am doing' // eslint-disable-line no-use-before-defineあるいは、 複数行 の"no-use-before-define"ルールを無効にするには：
/* 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 */一部のパッケージ（例：mocha）は、関数（例：describe、it）をグローバルオブジェクトに配置します。これらの関数は定義されていないか、どこかでrequireされているため、standardは未定義の変数を使用していることを警告します（通常、このルールはタイプミスを検知するのに本当に役立ちます！）。しかし、これらのグローバル変数に対しては無効にしたいでしょう。
特定の変数がグローバルに存在することを（コードを読んでいる人だけでなく）standardに知らせるには、次のコメントをファイルの先頭に追加します。：
/* global myVar1, myVar2 */何百ものファイルがある場合、すべてのファイルにコメントを追加しないほうが望ましいでしょう。次のコマンドを実行してください。：
$ standard --global myVar1 --global myVar2あるいは、次の内容をpackage.jsonに追加してください。：
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}注： globalとglobalsは同じです。
standardは、最新のECMAScriptの機能、プロポーザルプロセスの「ステージ4」にある言語機能の提案を含むES8（ES2017）をサポートしています。
実験的な言語機能をサポートするため、standardはJavaScriptのカスタムパーサーを指定することができます。カスタムパーサーを使用する前に、複雑さに見合う価値があるかどうかをよく考えてください。
カスタムパーサーを使用するには、まずnpmから以下をインストールしてください。：
npm install @babel/eslint-parser --save-devそして、次のコマンドを実行します。：
$ standard --parser @babel/eslint-parserあるいは、次の内容をpackage.jsonに追加してください。：
{
"standard": {
"parser": "@babel/eslint-parser"
}
}standardは最新のECMAScriptの機能をサポートしています。しかしながら、FlowやTypeScriptは言語に新たな構文を追加するため、そのまま使用することはできません。
JavaScriptの代替言語をサポートするため、standardは変更された構文をハンドルするためのESLintプラグインはもちろん、JavaScriptのカスタムパーサーの指定をサポートしています。JavaScriptの代替言語を使う前に、複雑さに見合う価値があるかどうかをよく考えてください。
Flowを使用するには、@babel/eslint-parserをパーサとして、eslint-plugin-flowtypeをプラグインとしてstandardを実行する必要があります。
npm install @babel/eslint-parser eslint-plugin-flowtype --save-devそして、次のコマンドを実行します。：
$ standard --parser @babel/eslint-parser --plugin flowtypeあるいは、次の内容をpackage.jsonに追加してください。：
{
"standard": {
"parser": "@babel/eslint-parser",
"plugins": [ "flowtype" ]
}
}注： pluginとpluginsは同じです。
standardをTypeScriptファイルで使用するには、公式にサポートされた2つの方法があります。
standardに似ていますが、TypeScript固有のCLIオプションとルールを持っています。このプロジェクトでは、ルールとしてeslint-config-standard-with-typescriptを使用しています。
eslint-config-standard-with-typescript
standardスタイルのJavaScriptとTypeScriptのルールを持ったESLint設定ファイルです。
テストファイルでmochaをサポートするには、次のコメントをテストファイルの先頭に追加します。：
/* eslint-env mocha */あるいは、次のコマンドを実行してください。：
$ standard --env mochamochaはjest、jasmine、qunit、phantomjsなどのいずれかになります。完全なリストを見るには、ESLintのspecifying environmentsを参照してください。これらの環境で使用可能なグローバルオブジェクトのリストについては、globalsのnpm moduleを参照してください。
注： envとenvsは同じです。
次のコメントをweb workerファイルの先頭に追加してください。：
/* eslint-env worker */これにより、selfがweb workerのコードでグローバルであることを（コードを読んでいる人だけでなく）standardに知らせます。
Service workersには、かわりに次のコメントを追加してください。：
/* eslint-env serviceworker */standardは、すべてのルール違反をエラーとして扱います。つまり、0以外の終了コード（エラー）で終了するということです。
しかしながら、我々はときどきstandardのユーザーの大多数に影響を与えうるルールを変更するような、新しいメジャーバージョンをリリースすることがあります（たとえば、varからlet、constへの移行など）。これを行なうのは、利点がコストに見合うと考えられ、かつルールが自動修正可能な場合に限られます。
このような状況では、ルールの変更を「警告」に留めた「移行期間」を設けています。警告は、standardに0以外の終了コード（エラー）を返させません。しかしながら、警告メッセージは依然としてコンソールに表示されます。移行期間中にstandard --fixを使うと、次のメジャーバージョンに備えてあなたのコードが更新されます。
我々は、standardでゆっくりと慎重なアプローチに励んでいます。我々は一般的に、新しい言語機能の使用を強制することに関して極めて保守的です。我々はstandardを気軽で楽しいものにしたいので、その妨げになるような変更には留意しています。いつも通り、必要に応じていつでもルールを無効にすることができます。
Markdownファイル内のコードをチェックするには、standard-markdownを使用してください。
あるいは、MarkdownやHTML、その他多くの言語ファイル内のコードをチェックできるESLintプラグインがあります。
Markdownファイル内のコードをチェックするには、次のESlintプラグインを使用してください。：
$ npm install eslint-plugin-markdownそして、コードブロック内のJavaScriptをチェックするために次のコマンドを実行します。：
$ standard --plugin markdown '**/*.md'HTMLファイル内のコードをチェックするには、次のESlintプラグインを使用してください。：
$ npm install eslint-plugin-htmlそして、<script>タグ内のJavaScriptをチェックするために次のコマンドを実行します。：
$ standard --plugin html '**/*.html'はい！フックは、スタイルが適用されていないコードがリポジトリに含まれないことを確実にするのに最適です。 もう二度とプルリクエストでスタイルのフィードバックをさせないでください！
選択肢があります……
#!/bin/bash
# Ensure all JavaScript files staged for commit pass standard code style
function xargs-r() {
# Portable version of "xargs -r". The -r flag is a GNU extension that
# prevents xargs from running if there are no input files.
if IFS= read -r -d $'\n' path; then
echo "$path" | cat - | xargs "$@"
fi
}
git diff --name-only --cached --relative | grep '\.jsx\?$' | sed 's/[^[:alnum:]]/\\&/g' | xargs-r -E '' -t standard
if [[ $? -ne 0 ]]; then
echo 'JavaScript Standard Style errors were detected. Aborting commit.'
exit 1
fipre-commitライブラリを使うとリポジトリ内の.pre-commit-config.yamlファイルでフックを宣言できるようになるので、チーム全体でより簡単に管理できます。
pre-commitのユーザーは、.pre-commit-config.yamlファイルにstandardを追加するだけで、.js、.jsx、.ts、.tsx、.mjs、.cjsファイルが自動的に修正されます。：
- repo: https://github.com/standard/standard
rev: master
hooks:
- id: standardあるいは、より高度なスタイル設定のためにeslint hookの中でstandardを使用します。：
- repo: https://github.com/pre-commit/mirrors-eslint
rev: master
hooks:
- id: eslint
files: \.[jt]sx?$ # *.js, *.jsx, *.ts and *.tsx
types: [file]
additional_dependencies:
- eslint@latest
- eslint-config-standard@latest
# and whatever other plugins...ビルトインの出力はシンプルで簡単ですが、きらきらしたものが好きならsnazzyをインストールしてください。
$ npm install snazzyそして、次のコマンドを実行します。：
$ standard --verbose | snazzystandard-tap、standard-json、standard-reporter、standard-summaryもあります。
はい！
渡されたtextをリントします。optsオブジェクトを指定できます。：
{
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-parser)
}現在の作業ディレクトリ内にpackage.jsonがあれば、追加のオプションが読み込まれます。
callbackは、Errorオブジェクトとresultsオブジェクトを引数として実行されます。
resultsオブジェクトは、次のプロパティを含みます。：
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
}standard.lintText()の同期バージョンです。エラーが発生すると、例外がスローされます。それ以外の場合は、resultsオブジェクトが返されます。
渡されたfilesをリントします。optsオブジェクトを指定できます。：
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-parser)
}callbackは、Errorオブジェクトとresultsオブジェクトを引数として実行されます（上記と同じ）。
コントリビューションは歓迎されます！IssuesやPull Requestsをチェックし、望みのものがなければ作成してください。
チャットしたい？それなら、freenodeの#standardチャンネルでIRCに参加してください。
standardのエコシステムには、いくつかの重要なパッケージがあります：
- standard - このリポジトリ
- standard-engine - 任意のESLintルールのCLIエンジン
- eslint-config-standard - standardのESLintルール
- eslint-config-standard-jsx - standardのESLintルール（JSX）
- eslint - standardを動作させるリンター
- snazzy - standardのきれいなターミナル出力
- standard-www - https://standardjs.com のコード
- semistandard - セミコロンありのstandard（必要ならば）
- standardx - カスタマイズ可能なstandard
多くの エディタープラグイン 、 standardを使用しているnpmパッケージ のリスト、 standardのエコシステムのパッケージ の素晴らしいリストもあります。
standardチームとコミュニティは、standardにおけるすべてのバグを真摯に受け止めています。問題を報告する方法については、security policies and proceduresを参照してください。
MIT. Copyright (c) Feross Aboukhadijeh.