Node.jsの12の簡単な初期モジュール開発手順

「最初はすべての半分以上です。」



これは非常に古いGTDの原則です。その年齢はおそらく数千歳です。 （たとえば、ウィキクォートは現在 、それをアリストテレスに帰属させていますが、証拠を裏付けるものではありません。）その本質は、プロジェクトをゼロから開始することは非常に困難な場合があることです。 しかし、いくつかの簡単な初期ステップがあり、その実装が部分的に完成したプロジェクトの外観につながる場合、「慣性によって」作業を続けることがはるかに簡単になります-このプロジェクトがすでに開始されただけでなく、さらに準備ができているように簡単です半分より。 また、最初のステップがどうあるべきかを事前によく知っている場合、それを行うことで間違いを犯すことは困難です。



オープンソースのNode.js用に12個以上のモジュールを作成し、npmパッケージとして公開する機会がありました。 より多くのモジュールを作成すればするほど、それらを作成するための最初のステップは同じであり、同じ順序で実行できることさえも（試行錯誤を含む）気づきました。 今日、Nodeエンジン用のJavaScriptコードを記述するプログラマーの作業に役立つことを期待して、この順序を公開します。



これらの各ステップは非常にシンプルで論理的です。

ステップ1. npmパッケージ名とリポジトリを作成する

名前がなければ、何も機能しません。 プロジェクトの名前がないと、githubのリポジトリまたはnpmパッケージを作成できません。



npmパッケージ名が事前に取得されていないことを確認してください。 （例は次のとおりです。秋にパッケージに「autumn」 または「fall 」という名前を付けることにした場合は、 https：//www.npmjs.org/package/autumn および https://www.npmjs.org/package/fallに アクセス して ください。これらの名前のnpmパッケージが既に存在することを労働者が確信させます。）



npmパッケージの名前が単純な単語またはよく知られた専門用語である場合、リポジトリの名前を取得するために「node-」プレフィックスを追加することを検討してください。 （たとえば、 sqlite3パッケージのコードはnode-sqlite3リポジトリに保存され、 openパッケージのコードはnode-openリポジトリに保存されます。）この追加は、他のプログラミング言語で同じ名前のプロジェクトに取り組むプログラマーの便宜のために行われます。 （たとえば、 誰かがすでにRust、Ruby、またはPythonで「open」と呼ばれるプロジェクトを持っている場合、名前の競合の結果を経験するのではなく、彼とノードオープンリポジトリが選択されていないフォークを行うことができます。）



npmパッケージには短い名前と長い名前がありますか？ 短い場合は手動で入力する方が簡単です（たとえば、 「 npm install 」の後のコマンドラインで）、長い場合はコピーされます（このアクションはより正確ですが、時間がかかり、利便性が低いと認識されます）。 また、サイトnodei.coは、npmパッケージのダウンロードに関する統計情報を含むヒストグラムを作成します。その幅は、パッケージ名の長さによって異なります（名前全体がヒストグラムに収まるように）。 以下に2つの例を示します。











名前が長すぎるモジュールの場合、そのようなヒストグラムの幅が大きくなると、モジュールに関する要約情報の準備を開始するときに、他の画像の右または左ではなく、別の行に統計を配置する必要があります。 -GithubのREADMEと同じくらい簡単です。

ステップ2.簡単な説明の作成

短い説明は、Githubでプロジェクトを作成するとき、およびその後（たとえば、 package.jsonファイルの説明フィールドに入力するとき）に役立ちます。



モジュールの機能を説明する短い文章を1つだけ書くのが最善です。 これにより、検索性が向上し、多くのサイトのパッケージまたはリポジトリの名前にハイパーリンクが付きます。 説明を長くしすぎると、 Twitter （および説明の長さをトリミングする他のサイト）のカードに収まりません。 さらに、たとえそれが適合したとしても、リストを流readingに読んでいる間、一般の人々はそれを最後まで読み終えることはありません。

ステップ3.自動的に読み込まれるREADMEファイルを使用してGithubリポジトリを作成します。

通常、Nodeモジュールリポジトリはgithubで作成されます。 私はこの規則の例外に遭遇しましたが、めったにありません。 したがって、ここではGithubとGitの使用に基づいてすべての手順を説明し、他のDVCSユーザーや他のオープンソースホスティングプロバイダーの読者に、これらの手順を自分自身に適合させる機会を提供します。これは難しいビジネスではありません。



https://github.com/newページで、リポジトリの名前と説明を記入することを提案します（前の2つの手順で両方を考え出すことができます）。また、 READMEファイル（プロジェクトの説明）、 ライセンス テキスト （コードがどれだけ開いているか） 、. gitignoreファイル（不要な一時ファイル、補助ファイル、ジャンクファイルをリポジトリにアップロードしないようにするため）。



Githubリポジトリに最初から少なくとも1つのファイルがある場合、リポジトリを複製することができます（たとえば、 「 git clone 」コマンドを使用）-ローカルリポジトリを初期化するよりも高速で簡単（約1.5または2回）です（たとえば、 「 git init 」コマンドを使用して、設定に手を入れて、githubリポジトリのアドレスをorigin として登録します。



ただし、Githubによって自動グレートされたライセンスファイルは、多くの場合、それ自体で編集する必要があり（たとえば、Githubログインを使用する代わりに、フルネームまたは組織名を示します）、どのファイルのアイデアに従って、自動生成された.gitignoreに何かを追加することもできますリポジトリは必要ありません。 したがって、人生で最初のNodeモジュールを作成しない場合は、READMEファイルの自動作成のみに限定し 、以前のモジュールの1つからライセンスと .gitignore既製をコピーすることをお 勧めします。 （ゼロからではなく、Github 自動生成の結果から）それらを再度行うことは 、 ムダ （無駄、余分な作業）であり、編集の履歴を乱雑にする無駄です。



Githubでリポジトリを作成した後、リポジトリ設定に必要なすべての変更を忘れずに行ってください。 たとえば、時間がほとんどないため、Wikiを監視する時間がない場合は、リポジトリでWikiサポートを無効にできます。 また、たとえば、他のリポジトリだけでなく、すべてのリポジトリだけでなく、スター付きリスト（星でマークされたリポジトリのリスト）の表示に慣れている場合は、最初に作成したリポジトリをすぐに新しく作成したリポジトリに配置できます。

ステップ4.ライセンス付きのテキストファイルを追加する

このステップを遅らせないことをお勧めします。以降のすべての編集がどのライセンスに適用されるのかを早めに明らかにするのが良いでしょう。



前のステップで述べたように、人生の最初のNodeモジュールを作成していない場合は、別のモジュールからLICENSE ファイルをコピーし、必要に応じてテキストの年を修正し、コミットできます。



オープンソースコードを配布するライセンスを初めて決定する場合は、コミュニティの例に従うことができます（Node.jsコミュニティでは、私の知る限り、MITライセンスが最も人気がありますが、このルールには例外があります） ）、またはchoosealicense.com 、またはその両方を参照してください。

ステップ5. .gitignore および .npmignoreファイルを追加する 。

ご存じのとおり、 .gitignoreファイルには、Gitリポジトリにあるべきではないファイルとディレクトリの名前がリストされています。 これらには、原則として、プロジェクトのアーカイブと配布、ログ、データベース、オペレーティングシステムの補助ファイル（たとえば、特定のサブディレクトリに含まれる画像のサムネイルのリポジトリ）が含まれます。



1つまたは複数のNodeモジュールが依存関係として使用されるプロジェクトを開発する場合、バージョンとnpmパッケージのコンテンツとの対応は明確なので、 node_modulesディレクトリ名を.gitignoreファイルに追加することは非常に適切です。したがって、Gitリポジトリにファイルのみを保存するだけで十分ですpackage.json （依存関係の名前とバージョンをリストします）が、必要なモジュール自体はリストしません。



（私の視野を広げるために、Mikeal Rogersは完全に反対の勧告を作成し 、積極的に推進したことに言及します。しかし、これは2014年にnpmパッケージのバージョンとコンテンツの対応が明確になる前に起こりました）。



npm-debug.logレポートの名前を.gitignoreファイルに追加すると便利です。このファイルは、 npmパッケージの操作中にエラーが発生した場合に表示されます。



その結果、 .gitignoreファイルは 何らかの形式を取ります。





.npmignoreファイルは.gitignoreファイルにほぼ似ていますが 、モジュールのnpmパッケージに含めるべきではないファイルとサブディレクトリの名前をリストします。



.gitignoreの内容全体を.npmignoreにコピーしてから、 テストサブディレクトリの名前またはモジュールのテストを保存する他の場所を追加することをお勧めします。 テストは開発に非常に役立つため、 Gitリポジトリでも非常に適切ですが、テストのダウンロードと保存はモジュールのエンドユーザーにとって余分な負担になります。つまり、 npmパッケージの大部分の消費者はこれらで構成されます。



原則として、新しいNodeモジュールで作業を開始するとき、 .gitignore および.npmignoreファイルを以前のモジュールから変更せずにコピーできます（人生で最初のNodeモジュールを作成している場合を除く）。 まれに修正する必要がありますが、そのような場合が発生することを知っておく必要があります。 （特に、 いずれかのモジュールがZIPアーカイブを処理する場合、少なくとも1つ以上のテストケースをリポジトリに配置するために、 .gitignoreファイルから「 * .zip 」行を削除する必要があります。そのようなニーズが生じました。たとえば、 Fidonetのnodelistを読み取るためのモジュールを開発するとき。

ステップ6. README.mdのモジュールの説明、ライセンスおよび未完成の開発についての説明。

3番目のステップで、モジュールの名前と簡単な説明のみで構成されるREADMEファイルが自動的に作成されたことを思い出します。



これで、この説明はプロジェクトの目標と目的について話すことでいくらか補充できます。 さらに、説明の別のサブセクションで、ライセンスの種類（たとえば、MITまたはBSD）と、ライセンスの全文を含むファイルの名前（通常はLICENSE ）に言及することが適切です。



読者がこの段階でモジュールの機能を実際に知っているという試みが失望を引き起こさないように（または、さらに良いことには、そのような試みがこれまでのところまったく発生しないように）、モジュールの開発が不完全であるだけでなく、初期段階。



このような補充の後、READMEファイルはnpmパッケージの初期バージョンの初期記述として適しています。



ただし、READMEで予定されているパッケージ名について言及している場合、このステップの結果をリポジトリに急いで投稿しないでください（たとえば、 gitコマンド commitを使用 ）。さらに、githubでそれらを公開することを急がないでください（たとえば、 gitコマンド push ） 。 実際には、計画された名前のパッケージの最初の登録（つまり、次のステップで処理します）が失敗した場合、READMEでは別の名前を登録する必要があります（これにより、編集履歴の目詰まりと消去の間の不快な選択につながらない方が良いでしょう） ）; Githubでの公開（npmでの公開に先行する場合）は一部のサイバースクワッター（あなたの前にパッケージ名を賭けたい）を警告することもできますが、普通のユーザー（コマンド「npm install package-name」なぜそれが期待どおりに機能しないのか疑問に思います）。



一般に、このステップでは、READMEでパッケージ名を計画するのは早すぎると考えることをお勧めします。

手順7. package.jsonを作成し、初期バージョンのnpmパッケージを登録します。

このステップの最終的な目標は、以前に考えられた名前でnpmパッケージを登録して、その名前を杭打ちすることです。



package.jsonファイルを作成し、その中のオブジェクトのいくつかのフィールドに入力することにより、このステップを開始する必要があります。 この場合、 JSON形式とnpm Webサイトで提供されるフィールドの意味の説明を同時に観察する必要があります。



モジュールについて質問する「 npm init 」コマンドがあり、回答に従ってpackage.jsonを自分で入力します。 ただし、私はpackage.jsonをテキストエディターで入力することを好みます-これにより、すべてのJSONコードを（質問で希釈されていない）最も純粋な形式で確認でき、さらに、必要に応じて何かを修正または変更するための簡単な機会が得られます。



実際、 npmサイトのドキュメントは誰にとっても十分なはずです。 しかし、私はそれを我慢せず、Habrahabrでは、 package.jsonに配置されている主要なフィールドの意味について簡単に触れます。



「 name 」フィールドの値は、目的のnpmパッケージ名を示します。 もっと早い段階で（最初のステップで）考えることができます。



「 バージョン 」フィールドの値は、 セマンティックバージョニング標準に従ってパッケージのバージョンを示します。 初期バージョンを登録するには、 " " 0.0.1 " "をお勧めします。



「 説明 」フィールドの値は、パッケージの簡単な説明を示します。 あなたはもっと早く（第2段階で）考えることができます。



「 キーワード 」フィールドの値は、npmサイトでの検索でパッケージを見つけるためのキーワードの配列を示します。 Habrahabrのブログ投稿のテキストの下にラベルをリストしたことがある人なら誰でも、このタスクに簡単に対処できます。



「 license 」フィールドの値は、 SPDX ID標準に準拠する識別子文字列を示し、以前にコード用に選択したライセンス（4番目のステップ）を意味します。



「 author 」フィールドの値は、パッケージの作成者名（および場合によっては連絡先情報）を含む文字列（またはオブジェクト）を示します。 そこに自分自身を示します。



「 リポジトリ 」フィールドの値は、 リポジトリのタイプとアドレスを含むオブジェクトを示します。



「 main 」フィールドの値は、モジュールコードのメインファイルへのパスを示します（これは、 moduleNameの代わりにモジュールの名前を指定する場合、Node関数「 require（ moduleName ） 」から呼び出されるファイルと同じです）。



モジュールがコマンドラインユーティリティとして使用される場合、値が「 true 」のpackageGeneralプロパティ（モジュールのグローバルインストールを推奨します）および「 」のような値のプロパティ「 bin 」 がpackage.jsonのそのようなモジュールに役立ちます。 moduleName.js " " javascript（モジュールの名前に一致するコマンドによって起動されるもの）へのパスを含む。 「 ＃！/ Usr / bin / env node 」という行は、npmが（javascriptのインストールとそれに続く操作がWindowsで実行される場合でも）そこを参照するため、そのようなjavascriptの最初の行です。



このステップのモジュールコードは最も単純なものにすることができます。たとえば、 ある種の 「 hello world 」や「use strict 」などです。



コミットの説明では、「パッケージが登録されている」というフレーズ（または「パッケージが公開されている」）を入れて、 「 npm publish 」コマンドが成功した場合にのみコミットします。 したがって、コミットは時期尚早ではありません（ 「 npm publish 」コマンドを発行すると、1つ以上の単純なエラーが明らかになることがありますが、その修正は編集の履歴を無駄にするだけです）。

ステップ8. README.mdのインストールの説明

このステップでは、README.mdファイルに、将来のユーザーに2つのコマンドの意味を伝える説明を入れることが適切です。

• npm installパッケージ名は、npmリポジトリから npmパッケージをインストールするコマンドです。
  
  
• npm install https://github.com/User name / Repository name / tarball / master - githubリポジトリの masterブランチからモジュールをインストールするコマンド。

将来のユーザーに一方のチームと他方のチームの結果の違いを説明することも役立ちます-たとえば、npmではなくGithubのみにテストを保存する（ npmパッケージのボリュームを増加させないようにする）ために先に（5番目のステップで）行われた決定について伝えるために



また、README.mdファイルの最新バージョンはGithubにのみ存在することもわかります（コードの変更後だけでなく、READMEの変更後もnpmパッケージの次の新しいバージョンを作成および公開する予定がない場合）。



同じステップで、 nodei.coの Webサイトで、依存関係の数とモジュール設定を示す情報統計カウンターとヒストグラムの適切なコードを取得し、README.mdファイルに配置することもできます。

ステップ9.メインモジュールコードの作業の開始

この段階では、モジュールの基礎（つまり、 ある種の 「 hello world 」または「use strict」 ）がゆっくりと合理的な何かを行うコードに変わりつつあるため、1つ以上の関数（またはオブジェクトのメソッド、またはユーティリティコマンド）。



ソースコードのこれらすべての機能は、ビルドするときにREADME.mdで慎重に文書化して、コード自体がオープンソースコードの唯一の文書にならないようにする必要があります。



さらに、ソースコードがこの段階に達するとすぐに、コードの正確性とその動作を検証するテストでそれをカバーするとすぐに便利です。 これが次のステップです。

ステップ10.テストを促進し、説明します。

このステップでは、README.mdに、ソースコードの正しいスペル（たとえばJSHint）とその動作（たとえば、Mocha）をインストールする方法とテストする手段の使用方法に関する明確な情報を入力する必要があります。



この時点で、テストツールの構成ファイル（たとえば、 JSHintの.jshintrc）もリポジトリに追加されます。



scripts.testフィールドは、 package.jsonファイル内のオブジェクトに入力されます（2つまたは3つのテストツールがある場合、 scripts.pretest およびscripts.posttestフィールドも 入力されます ）。



例：

 "scripts": { "pretest": "jshint .js test/", "test": "mocha --reporter spec --timeout 60s" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このステップから開始して、各コミットの前に、 npm testコマンドがエラーなしでパスすることを確認することをお勧めします。 （このコマンドをより意味のあるものにするには、Mochaを使用するときに、少なくとも1つのテストを記述し、 test /サブディレクトリに配置する必要があります。）

ステップ11. Travis CIの構成

Travis CIは、無料のオープンソーステストサービスを提供するサービスです。コミットするたびに、Githubからコードを自動的にダウンロードし、さまざまな環境でテストを実行して、コードが正常に機能するかどうかを確認できます。



Travis CIを最初に使用する準備、つまりドキュメントを読んで登録することをお勧めします。



新しいjavascriptモジュールの接続ははるかに簡単で、2つの簡単な手順で構成されています。



まず、ユーザープロファイルのhttps://travis-ci.org/profile/にアクセスします。 スイッチが表示されます。各スイッチは、githubのリポジトリの1つに対応しています。 次のようになります。







新しいモジュールに対応するスイッチをオンの位置に引く必要があります。



次に、その直後に、.travis.ymlファイルをリポジトリのルートにコミットします。 このファイルには、テストの実行に必要な環境が記述されています。 これについてはTravisのドキュメントで詳しく読むことができますが、通常の内容は非常に簡単で、次のようになります。

 language: node_js node_js: - "0.10" - "0.12" - iojs before_install: - "npm install -g npm" - "npm config set spin false" before_script: - "npm install jshint" - "npm install mocha"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「 言語 」セクションには、Nodeの「言語」（より正確にはエンジン）の表示が表示され、 「 node_js 」セクションには、モジュールがテストされるバージョンのリストが表示されます。



before_installセクションには、 npmを最新の安定バージョンに更新するコマンドと、回転カーソルのアニメーションを無効にするコマンドが含まれています（Travis CIログにはまだ表示されないため、時間を無駄にすることはありません）。



before_scriptセクションには、テストツール（この例ではJSHintとMocha）をインストールするコマンドが含まれています。

ステップ12. Travis CIインジケーターを README.mdに追加し ます 。

Travis CI は、画像の URLを提供します。これは、GithubのREADMEに1回配置され、その後毎回、最後のコミットの結果がTravis CIで正常にテストされたかどうかを確認できます。



サーバーshields.ioは、この画像のわずかに異なる形状を取得する機会を提供します-たとえば、ボリュームの変更、エッジの丸み、または碑文の一部。

メソッドの一般化

これで、Node.js用のモジュールを開発するための簡単な初期ステップのリストが終わりました。



明らかに、そのような方法（つまり、事前に準備された手順の再現から開始することで最初の衝動を与える機会）がNodeのモジュールの開発に適していることを願っています。



例を挙げましょう。 開発者の麻痺に関する記事（ PerseptronYarが翻訳）では、Habrahabrで、作業を開始する現代のすべてのサイトビルダーは、 ブリダンロバのように、ほぼ同等のアピールの異なる可能性の間で明白な選択をする緊急の必要性にすぐに直面するという話を見ることができます：

2014年に基本的なWebサイトを開始します。1.ノードのインストール2. Bowerのインストール3. CSSフレームワークの選択4.レスポンシブアプローチの選択... 47. HTMLの記述

-I Am Devloper（@iamdevloper） 2014年10月2日

ただし、そのような選択を一度だけ行うことができず、将来的に単にそれに固執することができれば、将来の人生を大幅に簡素化できます。 これを行うには、そのような各ステップで行われた選択を記述して修正し、完成したフォームにこれらのすべてのステップを書き留めて（たとえば、「CSSフレームワークを選択」ではなく、Bootstrapを選択した場合は「Bootstrapをインストール」）、それに従ってください各プロジェクトの開始時に、プロジェクトの合間にのみ新しい何かを意識的に試す理由がなかった場合（たとえば、読者が新しいブラウザに徐々に移行するときに、最新のJavaScript機能を優先してUnderscore.jsを拒否できます）そのようなカート ozhnost）。