このページのコンテンツは、JSHintプロジェクトのリポジトリから提供されています。もし間違いを見つけたら、issueをオープンするか、（できれば）プルリクエストを作成してください！

貢献方法

プロジェクトへの貢献は、一般的に以下の3つの形式のいずれかになります。

  • バグレポート
  • 機能リクエスト
  • パッチ

このドキュメントでは、それぞれの貢献の最適な方法について説明します。メンテナンスチームは、レポートの重大度を示すために、以下のラベルのいずれかを割り当てます。

  • P1: 例外が発生している、JSHintの下位互換性が壊れている。
  • P2: 何かが正しく解析されていない。
  • P3: コアチームがP2およびP1が完了次第取り組む機能。
  • P4: パッチ歓迎。リクエストは適切だが、優先度が低い。

バグレポート

もし不正な動作を発見したと思われる場合は、issueを提出してチームに知らせてください。チームが問題の診断と修正を支援するために、issueレポートには以下の情報が必要です。

  • 使用しているJSHintのバージョン
  • 入力ソースコード（問題を実証するために必要な詳細のみに簡略化されたもの）
  • 設定値
  • 期待される動作の説明
  • 実際の動作の説明

問題を実証するためにスクリーンショットを使用することは避けてください。問題をプレーンテキストで説明する（および必要に応じて「コード」のMarkdown書式を使用する）ことで、より多くの人がレポートにアクセスしやすくなり、検索エンジンで簡単に見つけられるようになります。

機能リクエスト

もしJSHintを改善すると思われる新機能がある場合、ぜひお知らせください！優れた機能リクエストには、以下の情報が含まれています。

  • 機能が解決する問題の説明
  • 機能の意図された動作の概要
  • エッジケース/例外的な状況のリストと、それらに対処する方法

もし機能の実装とパッチの送信が可能であれば、なお良いです！まず機能リクエストを作成して、メンテナーがそれが適切かどうかを確認し、設計を形作るのを手伝ってください。

パッチ

問題が確実に対処されるようにするための最良の方法は、パッチを送信することです。プルリクエスト、メール、issueのコメント、スニペットへのリンク付きのツイートなど、あらゆる手段でパッチを受け付けます。

ただし、パッチを送信する前に、以下が適用されていることを確認してください。

  • コミットメッセージがコミットメッセージのガイドラインに従っている。
  • パッチに無意味なマージコミットがない。
  • コーディングスタイルが私たちのものと似ている（下記参照）。
  • パッチが100％テストされている。テストの回帰は受け付けません。
  • すべてのテストとlintチェックに合格する (npm test)。
  • あなたのパッチに非常に感謝していることを理解している。

開発環境

JSHintはNode.jsを使用して開発されており、package.jsonファイルに指定された多くの依存関係があります。インストールするには、リポジトリディレクトリ内で次のコマンドを実行してください。

$ npm install

その後、bin/jshintを使用してJSHintのエッジバージョンを実行したり、bin/buildを使用してリリースバンドルをビルドしたりできるようになります。

コーディングスタイル

このセクションでは、私たちのコーディングスタイルガイドについて説明します。あなたはそれに同意しないかもしれませんが、それは構いませんが、パッチを送信する場合は、このガイドを法律として扱ってください。

私たちの主なルールはシンプルです。

コードベース内のすべてのコードは、何人が貢献したかに関わらず、単一の人がタイプしたように見えるはずです。 —idiomatic.js

空白

  • どこでも2つのスペースを使用します。
  • if、for、whileなどの後に1つのスペースを使用します。

  • 無名関数の場合はfunctionと(の間にスペースを入れず、名前付き関数の場合は名前と(の間にスペースを入れないでください。

    var a = function() {};
function a() {}

  • コードが見やすくなる場合は、変数代入またはプロパティ定義をインデントしてもかまいません。ただし、乱用しないでください。

    // Good
var next = token.peak();
var prev = token.peak(-1);
var cur  = token.current;

var scope = {
  name:   "(global)",
  parent: parentScope,
  vars:   [],
  uses:   []
};

// Bad
var cur         = token.current;
var isSemicolon = cur.isPunctuator(";");

  • 複数行のコメントを両側の改行で囲みます。

変数

  • 値が割り当てられていない場合（および十分に短い場合）を除き、変数ごとに1つのvarを使用します。

    var token = tokens.find(index);
var scope = scopes.current;
var next, prev, cur;

  • 変数名に過度に説明的にならないでください。ただし、1文字の変数を乱用しないでください。中間くらいの適切な場所を見つけてください。

コメント

  • 明白ではないものはすべてコメントしてください。
  • 新しいチェックを追加する場合は、このチェックが重要な理由と、チェックする内容を説明するコメントを記述します。

その他

  • 常に厳格モードを使用します。
  • 常に厳密な比較を使用します：===と!==。
  • セミコロンを使用します。
  • カンマファースト記法を使用しないでください。
  • 本当に役立つ場合（たとえば、テストなど）を除き、チェーン化を試みないでください。

  • 結果を割り当てていない場合は、ショートサーキット式を使用しないでください。

    // Good
token = token || tokens.find(0);

// Bad
token.isPunctuator(";") && report.addWarning("W001");

// Good
if (token.isPunctuator(";"))
  report.addWarning("W001");

コミットメッセージのガイドライン

コミットメッセージは、変更の目的を明確に説明する簡単な形式で記述されます。

一般的に、形式は次のようになります。

[[TYPE]] <Short description>
<Blank line>

<Body / Detailed description>

<Footer>

コミットメッセージの行の長さは厳密ではありませんが、優れたコミットメッセージには、60文字以下のヘッダーと、100列で折り返された本文/フッターが必要です。これにより、GithubのUIで適切にレンダリングされます。

ヘッダー

最初の行はコミットメッセージヘッダーであり、変更のタイプと、変更の一般的な説明を示します。理想的には、これは60文字以内に収まる必要があります。例えば

[[FIX]] Ignore "nocomma" when parsing object literals

タイトル[[FIX]]は、変更がバグ修正であることを示し、残りの部分で変更の内容が実際に明確になります。

jshintではいくつかのコミットタイプが使用されます。

  1. [[FIX]] --- コミットはバグまたは回帰を修正します。
  2. [[FEAT]] --- コミットは新しい機能を紹介します。
  3. [[DOCS]] --- コミットはドキュメントを変更します。ドキュメントのコミットは、ソースコードのコメント、またはドキュメントの生成に使用されるスクリプトとアセットのみを対象とする必要があります。
  4. [[TEST]] --- コミットはテストまたはテストインフラストラクチャのみを変更します。
  5. [[CHORE]] --- コミットは、dev-ops、CI、またはパッケージの依存関係に影響します。

本文

<本文>は、変更された内容を正確に説明する詳細なコミットメッセージであり、理由の要約です。本文の行は、最適なレンダリングのために100文字で折り返す必要があります。

履歴の例については、この例を参照してください。

フッター

<フッター>には、どれほど微妙であれ、重大な変更の説明と、このコミットによって影響を受けたり修正されたりしたissueのリストが含まれています。フッターの行は、最適なレンダリングのために100文字で折り返す必要があります。

例えば

[[FEAT]] Enable `norecurs` option by default

Commit 124124a7f introduced an option which forbids recursion. We liked it so much, we've enabled
it by default.

BREAKING CHANGE:

This change will break the CI builds of many applications and frameworks.

In order to work around this issue, you will need to re-engineer your applications and frameworks
to avoid making recursive calls. Use Arrays as stacks rather than relying on the VM call stack.

Fixes #1000009
Closes #888888
Closes #77777