Standard - JavaScript Style Guide
JavaScript Standard Style

discord travis npm version npm downloads Standard - JavaScript Style Guide

Sponsored by    Socket – Supply Chain Dependency Security for JavaScript and npm    Wormhole

EnglishEspañol (Latinoamérica)FrançaisBahasa IndonesiaItaliano (Italian)日本語 (Japanese)한국어 (Korean)Português (Brasil)简体中文 (Simplified Chinese)繁體中文 (Taiwanese Mandarin)

JavaScript スタイルガイド、リンター、フォーマッター

このモジュールは、3つの方法であなたの(そして他の人の!)時間を節約します。:

今すぐnpx standard --fixを実行して、試してみましょう!

目次

インストール

JavaScript Standard Styleを使用する最も簡単な方法は、Nodeのコマンドラインプログラムとしてグローバルインストールすることです。ターミナルで次のコマンドを実行してください。:

$ npm install standard --global

または、standardを一つのプロジェクトで使うためにローカルインストールできます。:

$ npm install standard --save-dev

注:上記のコマンドを実行するには、Node.jsnpmがインストールされている必要があります。

使い方

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を使うべきなのですか?

JavaScript Standard Styleの美しさは、シンプルなことです。作業しているすべてのモジュール/プロジェクトのために、数百行のスタイル設定ファイルをいくつも管理したい人はいません。こんな狂気はもうたくさんです!

このモジュールは、3つの方法であなた(と他の人!)の時間をセーブします。:

standardなスタイルを採用することは、個人のスタイルよりもコードの明確さやコミュニティの慣習を重要視することを意味します。これはプロジェクトと開発文化にとって100%意義があるわけではありませんが、オープンソースは初学者には適さない場所になりえます。コントリビューターの期待を明確にすることで、プロジェクトがより健全な状態になります。

より詳しくは、"Write Perfect Code with Standard and ESLint"をご覧ください。このトークでは、リントについて、standardeslintの使い分けについて、そしてprettierとの比較について学ぶことができます。

誰がJavaScript Standard Styleを使用していますか?

Free MIDIs, MIDI file downloadsCollege essays, AP notes
Your logo hereYour logo hereYour logo here

企業に加えて、多くのコミュニティメンバーがここに載せるには多すぎるパッケージでstandardを使用しています。

standardは、GitHubのClean Code Linterにおいて最もスターの多いリンターでもあります。

テキストエディタのプラグインはありますか?

まず、standardをインストールしてください。それから、あなたのエディタに適したプラグインをインストールしてください。

Sublime Text

Package Control を用いて、 SublimeLinterSublimeLinter-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

考慮すべき他のプラグインにはneomakesyntasticがあり、いずれも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

[![JavaScript Style Guide](https://cdn.rawgit.com/standard/standard/master/badge.svg)](https://github.com/standard/standard)

JavaScript Style Guide

[![JavaScript Style Guide](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](https://standardjs.com)

私はあるルールに反対なのですが、変更してもらえますか?

いいえ。standardのすべては、スタイルについてのbikeshedding(自転車置き場の議論)を避けることであなたの時間をセーブするためにあります。タブ対スペースについてのような議論はオンライン上にたくさんありますが、決して結論は出ません。これらの議論はただ物事を終わらせることから目を逸らさせるだけです。結局のところ、あなたは何かを選ばなければなりません。これは、standardの哲学のすべてです。うまくいけば、ユーザーは自身の意見を守るうえでその価値に気づくでしょう。

standardを完全には受け入れたくない人のために、似たようなパッケージが2つあります:

本当に何百ものESLintのルールを個別に設定したいなら、ルールを上書きするためにeslint-config-standardeslintを直接使うことができます。standard-ejectは、standardからeslinteslint-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.jsonstandard.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)は、関数(例:describeit)をグローバルオブジェクトに配置します。これらの関数は定義されていないか、どこかでrequireされているため、standardは未定義の変数を使用していることを警告します(通常、このルールはタイプミスを検知するのに本当に役立ちます!)。しかし、これらのグローバル変数に対しては無効にしたいでしょう。

特定の変数がグローバルに存在することを(コードを読んでいる人だけでなく)standardに知らせるには、次のコメントをファイルの先頭に追加します。:

/* global myVar1, myVar2 */

何百ものファイルがある場合、すべてのファイルにコメントを追加しないほうが望ましいでしょう。次のコマンドを実行してください。:

$ standard --global myVar1 --global myVar2

あるいは、次の内容をpackage.jsonに追加してください。:

{
  "standard": {
    "globals": [ "myVar1", "myVar2" ]
  }
}

注: globalglobalsは同じです。

実験的な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" ]
  }
}

注: pluginpluginsは同じです。

TypeScript

standardをTypeScriptファイルで使用するには、公式にサポートされた2つの方法があります。

ts-standard

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

mochajestjasminequnitphantomjsなどのいずれかになります。完全なリストを見るには、ESLintのspecifying environmentsを参照してください。これらの環境で使用可能なグローバルオブジェクトのリストについては、globalsのnpm moduleを参照してください。

注: envenvsは同じです。

Web WorkersとService Workersはどうすれば?

次のコメントをweb workerファイルの先頭に追加してください。:

/* eslint-env worker */

これにより、selfがweb workerのコードでグローバルであることを(コードを読んでいる人だけでなく)standardに知らせます。

Service workersには、かわりに次のコメントを追加してください。:

/* eslint-env serviceworker */

警告とエラーの違いは?

standardは、すべてのルール違反をエラーとして扱います。つまり、0以外の終了コード(エラー)で終了するということです。

しかしながら、我々はときどきstandardのユーザーの大多数に影響を与えうるルールを変更するような、新しいメジャーバージョンをリリースすることがあります(たとえば、varからletconstへの移行など)。これを行なうのは、利点がコストに見合うと考えられ、かつルールが自動修正可能な場合に限られます。

このような状況では、ルールの変更を「警告」に留めた「移行期間」を設けています。警告は、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フックはありますか?

はい!フックは、スタイルが適用されていないコードがリポジトリに含まれないことを確実にするのに最適です。 もう二度とプルリクエストでスタイルのフィードバックをさせないでください!

選択肢があります……

独自のフックをインストール

#!/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-tapstandard-jsonstandard-reporterstandard-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にコントリビュートするには?

コントリビューションは歓迎されます!IssuesPull Requestsをチェックし、望みのものがなければ作成してください。

チャットしたい?それなら、freenodeの#standardチャンネルでIRCに参加してください。

standardのエコシステムには、いくつかの重要なパッケージがあります:

多くの エディタープラグインstandardを使用しているnpmパッケージ のリスト、 standardのエコシステムのパッケージ の素晴らしいリストもあります。

セキュリティポリシーと手続き

standardチームとコミュニティは、standardにおけるすべてのバグを真摯に受け止めています。問題を報告する方法については、security policies and proceduresを参照してください。

ライセンス

MIT. Copyright (c) Feross Aboukhadijeh.