English • Español (Latinoamérica) • Français • Italiano (Italian) • 日本語 (Japanese) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin)
このモジュールは、3つの方法であなたの(そして他の人の!)時間を節約します。:
- 設定不要 プロジェクトに一貫性のあるスタイルを適用する最も簡単な方法です。単に入れるだけ!
- コードを自動的にフォーマット ただ
standard --fixを実行するだけで、汚いコードや一貫性のないコードにサヨナラしましょう。 - スタイルの問題やプログラマーのエラーを早期にキャッチ レビュアーと作業者の間の往復をなくすことで、貴重なコードレビューの時間を節約します。
導入するために考えなければならないことも、管理するための.eslintrc、.jshintrc、.jscsrcファイルも必要ありません。ただこれだけで動作します。
インストール方法:
npm install standard --save-dev
- 2スペース – インデントのため
- 文字列にはシングルクォート – エスケープを避ける場合を除く
- 未使用の変数なし – 多くのバグをキャッチ!
- セミコロンなし – It's fine. Really! (訳注: 試してみなって!マジで良いぞ!)
- キーワードの後にスペース
if (condition) { ... } - 関数名の後にスペース
function name (arg) { ... } - 常に
==ではなく===を使用 – ただしobj == nullはnull || undefinedをチェックするために許容されています - 常にnode.jsの
err引数をハンドル - ファイルの先頭に
/* global */コメントでブラウザのグローバルオブジェクトを宣言open、length、event、nameのようなあいまいな名前のグローバルオブジェクトの誤用を防ぎます- 例:
/* global alert, prompt */ - 例外:
window、document、navigator
- そしてもっと良いこと色々 –
standardを今すぐ試そう!
より良いアイデアを得るには、JavaScript Standard Styleで書かれたサンプルファイルを見てみましょう。
または、standardを使用している何千ものプロジェクトを参照してください!
- クイックスタート
- 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との比較について学ぶことができます。
多くの人々!
![]() |
![]() |
![]() |
![]() |
![]() |
|---|
![]() |
![]() |
![]() |
![]() |
![]() |
|---|
![]() |
![]() |
![]() |
![]() |
![]() |
|---|
![]() |
![]() |
![]() |
![]() |
![]() |
|---|
![]() |
![]() |
![]() |
![]() |
![]() |
|---|
![]() |
![]() |
![]() |
![]() |
![]() |
|---|
![]() |
![]() |
![]() |
![]() |
![]() |
|---|
企業に加えて、多くのコミュニティメンバーがここに載せるには多すぎるパッケージで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-standardjs をインストールしてください(自動フォーマットもサポートしています)。
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、bundle.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 --save-devそして、次のコマンドを実行します。:
$ standard --parser babel-eslintあるいは、次の内容をpackage.jsonに追加してください。:
{
"standard": {
"parser": "babel-eslint"
}
}もしstandardがグローバルインストールされている場合(つまりnpm install standard --global)、npm install babel-eslint --globalでbabel-eslintもグローバルインストールしてください。
standardは最新のECMAScriptの機能をサポートしています。しかしながら、FlowやTypeScriptは言語に新たな構文を追加するため、そのまま使用することはできません。
JavaScriptの代替言語をサポートするため、standardは変更された構文をハンドルするためのESLintプラグインはもちろん、JavaScriptのカスタムパーサーの指定をサポートしています。JavaScriptの代替言語を使う前に、複雑さに見合う価値があるかどうかをよく考えてください。
Flowを使用するには、babel-eslintをパーサとして、eslint-plugin-flowtypeをプラグインとしてstandardを実行する必要があります。
npm install babel-eslint eslint-plugin-flowtype --save-devそして、次のコマンドを実行します。:
$ standard --parser babel-eslint --plugin flowtypeあるいは、次の内容をpackage.jsonに追加してください。:
{
"standard": {
"parser": "babel-eslint",
"plugins": [ "flowtype" ]
}
}注: pluginとpluginsは同じです。
もしstandardがグローバルインストールされている場合(つまりnpm install standard --global)、npm install babel-eslint eslint-plugin-flowtype --globalでbabel-eslintとeslint-plugin-flowtypeもグローバルインストールしてください。
TypeScriptを使用するには、@typescript-eslint/parserをパーサとして、eslint-plugin-typescriptをプラグインとしてstandardを実行し、*.tsファイルをリントするようにstandardに伝える必要があります(デフォルトではリントされないため)。
npm install @typescript-eslint/parser @typescript-eslint/eslint-plugin --save-devそして、次のコマンドを実行します。:
$ standard --parser @typescript-eslint/parser --plugin @typescript-eslint/eslint-plugin *.tsあるいは、次の内容をpackage.jsonに追加してください。:
{
"standard": {
"parser": "@typescript-eslint/parser",
"plugins": [ "@typescript-eslint/eslint-plugin" ]
}
}package.jsonにこれを追加すると、次のコマンドが実行できます。:
standard *.tsもしstandardがグローバルインストールされている場合(つまりnpm install standard --global)、npm install @typescript-eslint/parser eslint-plugin-typescript --globalで@typescript-eslint/parserとeslint-plugin-typescriptもグローバルインストールしてください。
テストファイルで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 */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
fiビルトインの出力はシンプルで簡単ですが、きらきらしたものが好きなら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)
}現在の作業ディレクトリ内に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)
}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-plugin-standard - standardのカスタムESlintルール(ESLintのコアの一部ではない)
- eslint - standardを動作させるリンター
- snazzy - standardのきれいなターミナル出力
- standard-www - https://standardjs.com のコード
- semistandard - セミコロンありのstandard(必要ならば)
- standardx - カスタマイズ可能なstandard
多くの エディタープラグイン 、 standardを使用しているnpmパッケージ のリスト、 standardのエコシステムのパッケージ の素晴らしいリストもあります。
MIT. Copyright (c) Feross Aboukhadijeh.



































