README Ja

JavaScript Standard Style

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

1. 以下をpackage.jsonに追加します

{
  "name": "my-cool-package",
  "devDependencies": {
    "standard": "*"
  },
  "scripts": {
    "test": "standard && node my-tests.js"
  }
}

2. スタイルはnpm testを実行する際に自動的にチェックされます

$ npm test
Error: Use JavaScript Standard Style
  lib/torrent.js:950:11: Expected '===' and instead saw '=='.

3. もう二度とプルリクエストでスタイルのフィードバックをさせないでください！

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をインストールしてください。それから、あなたのエディタに適したプラグインをインストールしてください。

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 製品に適用されます。

はい！プロジェクトで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 */

一部のパッケージ（例：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

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 つの方法があります。

ts-standard

standardに似ていますが、TypeScript 固有の CLI オプションとルールを持っています。このプロジェクトでは、ルールとしてeslint-config-standard-with-typescriptを使用しています。

eslint-config-standard-with-typescript

standard スタイルの JavaScript と TypeScript のルールを持った ESLint 設定ファイルです。

テストファイルで mocha をサポートするには、次のコメントをテストファイルの先頭に追加します。：

/* eslint-env mocha */

あるいは、次のコマンドを実行してください。：

$ standard --env mocha

mochaは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
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もあります。

はい！

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 オブジェクトを引数として実行されます（上記と同じ）。

コントリビューションは歓迎されます！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.