[解決済み] テストは.npmignoreすべきですか？

質問

具体的にどのように .npmignore ?

テスト? のようなもの .travis.yml , .jshintrc ? モジュールを実行するときに必要でないもの（readmeを除く）？

これに関するガイダンスが見当たりません。

どのように解決するのですか？

おそらくお気づきのように、NPM はそこに何を入れるべきかを具体的に述べておらず、むしろ彼らは デフォルトで無視されるファイルのリスト . 多くの人はこれを使用しません。 .gitignore で無視されるからです。 npm である場合、デフォルトでは .npmignore が存在しない場合、デフォルトで無視されます。さらに、多くのファイルは設定に関係なくすでにデフォルトで無視され、一部のファイルは上記のリンクで説明されているように、常に無視されないように除外されています。

のサブセットであるため、何が常にそこにあるべきかということについては、あまり公式なものはありません。 .gitignore のサブセットであるため、公式にはあまり知られていませんが、5年近くnodeを使用してきた経験から、私が思いついたのは以下のとおりです。

注 生産 私は、あなたのモジュールが誰かによって使用されるすべての時間を意味し、モジュール自体で開発するためではありません。

プレリリース版のクロスコンパイルソース

• プロフェッショナル : JavaScript にクロスコンパイルする言語を使用している場合、リリース前にプリコンパイルし、インクルードしないようにすることができます。 .coffee ファイルをパッケージに含めず、git リポジトリで追跡することができます。

ビルドファイルの残骸

• プロフェッショナル : のようなものを使っている人 node-gyp を使っている人は、ビルド中に生成されるオブジェクトファイルがあるかもしれませんが、それは決してパッケージに入れるべきものではありません。
• 短所 : これは常に .gitignore の中に入れる必要があります。を使用している場合は、これらのものをこの中に置かなければなりません。 .npmignore ファイルを使用している場合は、この中に .gitignore を上書きするからです。

テスト内容

• プロフェッショナル : プロダクションコードに含まれる荷物が少なくなる。
• 短所 : 本番環境ではテストを実行できません。システム固有の障害、たとえば古いバージョンのノードが動作していてテストが失敗する可能性があります。

継続的インテグレーション設定/メタファイル

• プロフェッショナル : 繰り返しになりますが、荷物が少ない。例えば .travis.yml などは、コードの使用、テスト、閲覧には必要ありません。

非readmeのドキュメントとコード例

• プロフェッショナル : 荷物が少ない。Readmeで最低限実現可能な機能を表現できなければ、モジュールは大きすぎるという考え方の人もいます。
• 短所 : 自分のファイルシステム上でドキュメントやコード例を見ることができない。リポジトリにアクセスする必要があります (これにはインターネット接続も必要です)。

Github-ページ オブジェクト

• プロフェッショナル : 確かにリリースに CNAME ファイルやプレースホルダー index.html としてモジュールを使用する場合は、プレースホルダの gh-pages リポジトリとしても機能します。

bower.jsonとその仲間たち

• プロフェッショナル : リリース前に依存関係をビルドすることを決定した場合、エンドユーザがbowerをインストールし、さらにそれを使ってインストールする必要がありません。私なら、個人的には、そのようなものはパッケージの中に入れておきます。私が npm install を行うとき、私はnpmにのみ依存し、他の外部ソースには依存しないようにすべきです。

基本的には、npm パッケージから除外したいが npm リポジトリからは除外したくないものがある場合に使用する必要があります。長いリストではありませんが、npmはむしろ、人々がパッケージに無関係なオブジェクトで立ち往生するよりも、機能性を構築することを望んでいます。