JavaScript Standard Style
Sponsored by
English • Español (Latinoamérica) • Français • Bahasa Indonesia • Italiano (Italian) • 日本語 (Japanese) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin)
JavaScript スタイルガイド、リンター、フォーマッター
このモジュールは、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 standard
globパターンを用いてディレクトリを渡すこともできます。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を使うべきなのですか?
JavaScript Standard Styleの美しさは、シンプルなことです。作業しているすべてのモジュール/プロジェクトのために、数百行のスタイル設定ファイルをいくつも管理したい人はいません。こんな狂気はもうたくさんです!
このモジュールは、3つの方法であなた(と他の人!)の時間をセーブします。:
- 設定なし プロジェクトに一貫性のあるスタイルを適用する最も簡単な方法です。
- コードを自動的にフォーマット ただ
standard --fix
を実行し、汚いコードや一貫性のないコードにサヨナラしましょう。 - スタイルの問題やプログラマーのエラーを早期にキャッチ レビュアーと作業者の間の往復をなくすことで、貴重なコードレビューの時間をセーブします。
standard
なスタイルを採用することは、個人のスタイルよりもコードの明確さやコミュニティの慣習を重要視することを意味します。これはプロジェクトと開発文化にとって100%意義があるわけではありませんが、オープンソースは初学者には適さない場所になりえます。コントリビューターの期待を明確にすることで、プロジェクトがより健全な状態になります。
より詳しくは、"Write Perfect Code with Standard and
ESLint"をご覧ください。このトークでは、リントについて、standard
とeslint
の使い分けについて、そしてprettier
との比較について学ぶことができます。
誰がJavaScript Standard Styleを使用していますか?
Your logo here | Your logo here | Your logo here |
---|
企業に加えて、多くのコミュニティメンバーがここに載せるには多すぎるパッケージでstandard
を使用しています。
standard
は、GitHubのClean Code Linterにおいて最もスターの多いリンターでもあります。
テキストエディタのプラグインはありますか?
まず、standard
をインストールしてください。それから、あなたのエディタに適したプラグインをインストールしてください。
Sublime Text
Package Control を用いて、 SublimeLinter と SublimeLinter-contrib-standard をインストールしてください。
保存時に自動でフォーマットするには、 StandardFormat をインストールしてください。
Atom
linter-js-standard をインストールしてください。
あるいは、 linter-js-standard-engine をインストールしてもよいでしょう。バンドルされたstandard
のバージョンではなく、プロジェクトにインストールされているバージョンが自動的に使用されます。 また、 standard-engine を元にした他のリンターでも動作します。
自動フォーマットには、 standard-formatter をインストールしてください。スニペットには、 standardjs-snippets をインストールしてください。
Visual Studio Code
vscode-standard をインストールしてください(自動フォーマットもサポートしています)。
JavaScriptのスニペットには、 vscode-standardjs-snippets をインストールしてください。Reactのスニペットには、 vscode-react-standard をインストールしてください。
Vim
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
のビルトインサポートを備えています(設定が必要かもしれませんが)。
Emacs
Flycheck をインストールし、プロジェクトで有効にする方法については マニュアル を参照してください。
Brackets
extension registryで "Standard Code Style" を検索し、"Install"をクリックしてください。
WebStorm(PhpStorm、IntelliJ、RubyMine、JetBrainsなど)
WebStormでは、IDEでstandard
がネイティブサポートされるようになりました。
standard
を手動で設定したい場合、こちらのガイドに従ってください。これは、PhpStorm、IntelliJ、RubyMineなど、すべてのJetBrains製品に適用されます。
readme用のバッジはありますか?
はい!プロジェクトでstandard
を使っているなら、コードがstandardスタイルを使用していることを示すためにこれらのバッジをreadmeに含めることができます。
[![JavaScript Style Guide](https://cdn.rawgit.com/standard/standard/master/badge.svg)](https://github.com/standard/standard)
[![JavaScript Style Guide](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](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を直接使用した場合、通常どおりエラーを非表示にすることができます。
特定の行の すべてのルール を無効にするには:
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 */
私はグローバル名前空間を汚染するライブラリを使用しています。"variable is not defined"というエラーを防ぐには?
一部のパッケージ(例:mocha
)は、関数(例:describe
、it
)をグローバルオブジェクトに配置します。これらの関数は定義されていないか、どこかでrequire
されているため、standard
は未定義の変数を使用していることを警告します(通常、このルールはタイプミスを検知するのに本当に役立ちます!)。しかし、これらのグローバル変数に対しては無効にしたいでしょう。
特定の変数がグローバルに存在することを(コードを読んでいる人だけでなく)standard
に知らせるには、次のコメントをファイルの先頭に追加します。:
/* global myVar1, myVar2 */
何百ものファイルがある場合、すべてのファイルにコメントを追加しないほうが望ましいでしょう。次のコマンドを実行してください。:
$ standard --global myVar1 --global myVar2
あるいは、次の内容をpackage.json
に追加してください。:
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
注: global
とglobals
は同じです。
実験的なJavaScriptの機能(ES Next)を使用するには?
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"
}
}
FlowやTypeScriptのようなJavaScriptの代替言語を使用できますか?
standard
は最新のECMAScriptの機能をサポートしています。しかしながら、FlowやTypeScriptは言語に新たな構文を追加するため、そのまま使用することはできません。
JavaScriptの代替言語をサポートするため、standard
は変更された構文をハンドルするためのESLintプラグインはもちろん、JavaScriptのカスタムパーサーの指定をサポートしています。JavaScriptの代替言語を使う前に、複雑さに見合う価値があるかどうかをよく考えてください。
Flow
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
は同じです。
TypeScript
standardをTypeScriptファイルで使用するには、公式にサポートされた2つの方法があります。
standard
に似ていますが、TypeScript固有のCLIオプションとルールを持っています。このプロジェクトでは、ルールとしてeslint-config-standard-with-typescript
を使用しています。
eslint-config-standard-with-typescript
standardスタイルのJavaScriptとTypeScriptのルールを持ったESLint設定ファイルです。
Mocha、Jest、Jasmine、QUnitなどはどうすれば?
テストファイルでmochaをサポートするには、次のコメントをテストファイルの先頭に追加します。:
/* eslint-env mocha */
あるいは、次のコマンドを実行してください。:
$ standard --env mocha
mocha
はjest
、jasmine
、qunit
、phantomjs
などのいずれかになります。完全なリストを見るには、ESLintのspecifying environmentsを参照してください。これらの環境で使用可能なグローバルオブジェクトのリストについては、globalsのnpm moduleを参照してください。
注: env
とenvs
は同じです。
Web WorkersとService Workersはどうすれば?
次のコメントを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やHTMLファイル内のコードをチェックできますか?
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'
Gitのpre-commit
フックはありますか?
はい!フックは、スタイルが適用されていないコードがリポジトリに含まれないことを確実にするのに最適です。 もう二度とプルリクエストでスタイルのフィードバックをさせないでください!
選択肢があります……
独自のフックをインストール
# 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
pre-commit
フックを使用
pre-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 | snazzy
standard-tap、standard-json、standard-reporter、standard-summaryもあります。
Node.jsのAPIはありますか?
はい!
async standard.lintText(text, [opts])
渡されたtext
をリントします。opts
オブジェクトを指定できます。:
{
// unique to lintText
filename: '', // path of file containing the text being linted
// common to lintText and lintFiles
cwd: '', // current working directory (default: process.cwd())
fix: false, // automatically fix problems
extensions: [], // file extensions to lint (has sane defaults)
globals: [], // custom global variables to declare
plugins: [], // custom eslint plugins
envs: [], // custom eslint environment
parser: '', // custom js parser (e.g. babel-eslint)
usePackageJson: true, // use options from nearest package.json?
useGitIgnore: true // use file ignore patterns from .gitignore?
}
現在の作業ディレクトリ内にpackage.json
があれば、追加のオプションが読み込まれます。
results
オブジェクトは、次のプロパティを含みます。:
const 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
}
async standard.lintFiles(files, [opts])
渡されたfiles
をリントします。opts
オブジェクトを指定できます。:
{
// unique to lintFiles
ignore: [], // file globs to ignore (has sane defaults)
// common to lintText and lintFiles
cwd: '', // current working directory (default: process.cwd())
fix: false, // automatically fix problems
extensions: [], // file extensions to lint (has sane defaults)
globals: [], // custom global variables to declare
plugins: [], // custom eslint plugins
envs: [], // custom eslint environment
parser: '', // custom js parser (e.g. babel-eslint)
usePackageJson: true, // use options from nearest package.json?
useGitIgnore: true // use file ignore patterns from .gitignore?
}
results
オブジェクトを引数として実行されます(上記と同じ)。
StandardJSにコントリビュートするには?
コントリビューションは歓迎されます!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.