かなり後悔してる。とりあえず現時点で失敗したと思った点まとめてます。今後npmでライブラリ公開したいという人が同じ轍踏まないことを願います。
npm versionコマンドで失敗しないためのポイントもまとめました
一度公開するとバージョンを上げない限り更新できない
例えば0.0.1を公開した直後致命的なエラーを発見したとします(実際にあった)。それを直し、npmのパッケージの方も直すにはバージョンを0.0.2に上げなければなりません。0.0.1バージョンとして更新できません。
これだけならまだ良いのですが、0.0.1は依然としてダウンロード可能です(npm install hoge@0.0.1)。つまりゴミバージョンが残ります。永久に。
publishする時は慎重になりましょう。
テストを書いてない & TravisCIを使ってなかった
TravisCIというのはよく見かける緑色の細長いバッヂです。↓の画像がそれです。ライブラリ作ったからには付けたいですよね。
まあ貼りたくなる云々はさておき、テストを書いておくことでpublishした後で修正を加えたくなる、ということが減ります。エラーが出てないという保証はpublishする時に安心できます。無駄なバージョンを増やすことも回避できるのでテストを書いてない人は書くことをオススメします。
npm install をした時の挙動確認はpublishなしでできる
npm linkというコマンドを使うことでnpm installでどのようにインストールされるのかローカル環境で試すことができます。初心者なのにこれをせずに公開すると確実に0.0.1がゴミバージョンになります。気をつけましょう。
.npmignoreを使いこなせない
.npmignore結構大事です。いらないものはきちんと登録しておきましょう。僕はこれを設定し忘れて、設定するためだけに0.0.2公開しました。悔しかったです…
僕の書いた.npmignoreはこんな感じです。
*.html *.png gulpfile.js src/ test/
テスト用、開発用のコードやロゴ画像などを取り除いてます。
より高度なことをしたい時はpackage.jsonのscriptsのpreinstallを使います。僕はまだ使ってません。AngularJSなんかではこっちの方法を取っているようです。
ちなみにnpm linkはリンク貼るだけで、.npmignoreがどう適用されるのかまでは確認できません。
リポジトリ名に大文字が混ざっている
これ本当に後悔したので、npmとは直接関係はないのですが入れさせてください。
npmでライブラリ公開したらGitHub Pages使ってwikiというかdocumentというかを作りたくなりますよね。その時、リポジトリ名でURL作るのですが、大文字小文字が区別されます。
たとえば HogeJS というライブラリを作ると http://username.github.io/HogeJS でしかアクセスできなくなります。
一応後から変更はできるのですが、SEOなんかを考えるとよろしくありません。また、Twitterのツイートは変更できないので後からリポジトリ名変えてURL変更するとそのツイートのリンクが切れます。
ライセンスを貼っていなかった
ライセンスは書きましょう。MITならLICENCE.txtを書くだけですし。ライセンスは.npmignoreで除かないようにしましょう。
README.mdのマークダウンに気をつけなければならない
GitHubではきちんと表示されていてもhttp://www.npm.com では崩れていたりします。
h1(# heading)がページで2つ以上出ると2つ目以降は見出しにならないようです。きちんと2つ目以降はh2以下に設定しましょう。
…と書きましたが実はちょっとわかりません。実は今まで#の直後にスペースを挟んでいませんでした。今回修正した時、スペースを入れてh2以下に設定を同時にしました。だから、スペースを入れたことで表示が直ったのか、h2以下に設定したから直ったのかわかりません。
とりあえずどちらもやれば表示は直ります。
終わりに
npmでライブラリ公開することはこんなに罠があるのにネットの記事では全く書いてなかったので自分はこんなにも地雷を踏む羽目になりました。ライブラリ公開してる人はみんなこれらを回避したのですかね。不思議でなりません。
なんかまだ忘れてる気がするので多分そのうち追記します。