コード提出ガイドライン

Sailsコアで受け入れることができるコードの貢献には、パッチと新機能の2種類があります。

パッチは、タイプミスからタイミングの問題まで、あらゆるものを表す小規模な修正です。ファイルの先頭から未使用のrequire()を削除したり、Travisでマスターブランチのテストをクラッシュさせているタイプミスを修正したりすることは、パッチの好例です。複数のファイルにわたって空白や変数名を変更する大規模なリファクタリングプロジェクトは、パッチではありません。また、一見些細な変更であっても、Sailsのドキュメント化された機能の使用方法に影響を与える場合、またはドキュメント化されていないパブリック関数を追加する場合は、パッチではないことに注意してください。

新機能は、Sailsロードマップファイルに要約されているTODOであり、付随するプルリクエストに詳細情報が記載されています。ROADMAP.mdファイルに明記されていないものは、新機能として提出しないでください。

自分が行いたい変更が「パッチ」と見なされるかどうか疑問がある場合は、プルリクエストの作業を開始する前に、イシュートラッカーで issue を開くか、Twitterでコアチームの誰かに連絡してください。特に、大きな作業を計画している場合はそうしてください。あなたのビジョンがプロジェクトのメンテナーの計画または進行中の開発作業と一致しないために、あなたの努力が無駄になることほどイライラすることはありません。

一般的なルール

• メンテナンスされているLTS でサポートされているJavascriptのみを使用してください。一貫性を保つために、コアフックとコアジェネレーターを含むSailsコアのすべての命令型コードは、CoffeeScript、TypeScript、またはその他のプリコンパイルまたはトランスパイルされた言語ではなく、JavaScriptで記述する必要があります。誤解しないでください。ユーザーランドコードでES6、TypeScript、および/またはCoffeeScript構文を使用することで生産性が向上する場合は、素晴らしいことだと思います。ただし、互換性と一貫性の理由から、メンテナンスされているLTSでサポートされているJavaScriptで記述されていない限り、プルリクエストをマージすることはできません。
• コードを自動フォーマットしたり、コアの既存ファイルで認識されているスタイルの問題を修正しようとしないでください。
• 各プルリクエストは、単一の目標に焦点を絞り、変更するLoC/ファイル数をできるだけ少なくしてください。
• 明確に定義された提案に基づいて作業していない限り、新機能を実装したり、既存の機能を強化したりするプルリクエストを送信しないでください。上記のように、あなたのビジョンがプロジェクトのメンテナーと一致しないために、あなたの努力がマージされないことほどイライラすることはありません。
• 機能の作業を開始する前に、他のコントリビューターにその機能に取り組んでいることを伝えるコメントを残してください。進捗状況について他のコントリビューターに積極的に通知しない場合、沈黙は非アクティブと見なされ、他の誰かがその機能の作業を開始する可能性があることに注意してください。

コアへの貢献

Sailsコア内のサブモジュールは、APIの安定性のレベルが異なります。バグ修正（パッチ）は常に歓迎されますが、上記の機能提案のプロセスに記載されているように、APIまたは動作の変更は、綿密な計画なしにマージすることはできません。

Sailsには、package.jsonファイルで参照されている依存関係がいくつかありますが、これらはプロジェクト自体の一部ではありません。これらの依存関係またはそれらの依存関係に対する変更の提案は、それぞれのプロジェクト（Express、Socket.ioなど）に送信する必要があります。Sailsリポジトリにパッチや機能のリクエストを送信しないでください。受け入れることも満たすこともできません。（チャットでご連絡いただければ、可能な限りお手伝いいたします。）

アダプターへの貢献

アダプターがコアの一部である場合（コードベースはSailsリポジトリにあります）、Sailsコアへの貢献に関する一般的なベストプラクティスに従ってください。別のリポジトリにある場合は、機能のリクエストとパッチをそこに送信してください。

新しいアダプターの作成

Sailsアダプターは、Waterlineクエリ構文を統合データベースの低レベル言語に変換し、データベースからの結果を取得して、Waterline（SailsフレームワークのORM）が期待する応答にマッピングします。新しいアダプターの作成は軽視すべきではありませんが、多くの場合、アダプターの作成はそれほど難しくありません（通常は既存のnpmパッケージをラップするため）。SailsのORMフックとWaterlineコードベースに貢献するための素晴らしい方法です。

新しいアダプターの作業を開始する前に、npm、Google、Githubで徹底的に検索して、他の誰かが同じ作業をすでに開始していないことを確認してください。アダプターの詳細については、概念> Sailsの拡張>アダプターをご覧ください。

フックへの貢献

フックがコアの一部である場合（コードベースはSailsリポジトリにあります）、Sailsコアへの貢献に関する一般的なベストプラクティスに従ってください。フックが別のリポジトリにある場合は、機能のリクエスト、パッチ、およびissueをそこに送信してください。多くのコアフックには、その目的、アタッチするメソッド、トリガーするイベント、および実装に関するその他の関連情報が記載されたREADME.mdファイルがあります。

新しいフックの作成

フックを作成することは、Sailsコアでほぼ何でもを実現するための素晴らしい方法です。新しいカスタムフックの作業を開始する前に、npm、Google、Githubで徹底的に検索して、他の誰かが同じ作業をすでに開始していないことを確認してください。カスタムフックの詳細については、概念> Sailsの拡張>フックをご覧ください。

ジェネレーターへの貢献

ジェネレーターがコアの一部である場合（コードベースはSailsリポジトリにあります）、Sailsコアへの貢献に関する一般的なベストプラクティスに従ってください。別のリポジトリにある場合は、機能のリクエスト、パッチ、およびissueをそこに送信してください。

新しいジェネレーターの作成

カスタムジェネレーターAPIはまだ100％安定していませんが、落ち着いてきています。新しいカスタムジェネレーターの作業を自由に開始できますが、最初にnpm、Google、Githubで徹底的に検索して、他の誰かが同じ作業をすでに開始していないことを確認してください。カスタムジェネレーターは、Sailsコードベースに貢献するための素晴らしい方法です。