この記事で分かる事
表題の通りです。
記事の作成方針
既にネット上には良質な情報がたくさん上がっていますので、積極的に他記事へのリンクを貼っています。
この記事で新たに分かる事はあまりないと思いますが、体系的にまとまっている記事が少なかったので、この記事が他の良質な情報へのindex的な役割を果たすと良いと思っています。
この記事の公開後、有益な情報を見つけた場合はこの記事に追記を行っていきます。
開発〜公開までの流れ
初めてのnpm パッケージ公開 という記事が非常によくまとまっていて良いと思います。
ここを見れば基本的なコードの書き方や公開の流れは掴めると思います。
私は最近ではTypeScriptでのコーディングがメインになっているので公開したpackageはTypeScriptでも利用出来るようにしたいので、npm package自体もTypeScriptで開発しています。
その際は下記の記事も参考になります。
npm や package.json の仕様を把握する
多少間違った記述があっても動作しますが、packageを公開するのであれば npm 自体の仕様やpackage.json の書き方をある程度知っておく必要があります。
公式サイトを見るのが最も確実です。
package.json の書き方に関しては日本語翻訳版もあります。
Scoped Packagesについて
公式ドキュメント にも記載がありますが、基本的にpackage名が被ると公開出来ないので、Scoped Packages（package名にユーザー名が含まれる手法）を使う事をオススメします。
一点注意点があります。
Scoped Packagesはpublicなpackageでないと利用出来ない点です。（課金すればprivateでも利用可能）
その為、package公開時には npm publish --access=public を明示的に実行する必要があります。
ローカルでの動作確認について
手前味噌ですが 自作したnpm packageをローカルでテストする方法 という記事を書きました。
この記事にも書いてるのですが、基本的には npm link を使うのが最も簡単です。
継続的インテグレーション
バグの発生確率を少しでも減らす為にもCIツールによる継続的インテグレーションを設定しておく事をオススメします。
個人的にはOSSであれば無料で利用出来る Travis CI の利用をオススメします。
（参考）GitHubと連携できる継続的インテグレーションツール「Travis CI」入門
またカバレッジ結果の集計も行いたいので Coveralls も利用すると良いでしょう。
以下の記事が参考になります。
またテストを通過していないPRがマージされる事を防ぐ為にも、テストを通過していないPRはマージ出来ないように設定しておく事をオススメします。
（参考）GitHub のブランチ保護を使用してリスキーなマージを防止する
READMEにBadgeを貼る
OSSのライブラリ等でよく見る下記のようなBadgeです。
最低でもpackage version、build、coverage、Licenseくらいは貼っておくと良いでしょう。
Travis CI と Coveralls を設定すれば build、coverage のBadgeは生成出来ます。