tyankatsu’s blog

カレーと炭酸が苦手なほうれん草好きマンの技術ブログとか

「npmパッケージ製作に関するあれこれ」の補足

技術記事

俺の話を聞け！！LT大会 #12でLTしてきました。 スライドはこちらになります。npmパッケージ製作に関するあれこれ - Speaker Deck

いろいろ端折った部分があったので、本記事で補足させていただきます。

npmパッケージ開発に関してテーマにした理由

npmパッケージの公開方法のtipsの記事がそんなにヒットしなかったので、だったら自分で記事にしようと思った次第です。

cz-format-extensionとは

commitizenのルールをユーザーが簡単に拡張できるようにしようという目的で作成中のパッケージです。
似たパッケージにcz-customizableがあります。
これはこれでいいのですが、

  • inquirerのバージョンが古すぎる
  • configの書き方が微妙
  • 選択肢はカスタマイズできても、出力されるフォーマットはいじれない
  • configのフィールドを分けないといけないのが気持ち悪い

という不満があり、現在僕と、前職で一緒だったフロントエンドエンジニアの方と作成中です。（誰か手伝って🙏）

ブラックリストとホワイトリスト

.npmignoreとpackage.jsonのfilesフィールドの併用

詳しくはこちらに書いてありますので、参照してください。
細かすぎて伝わらない package.json 小ネタ三選 - t-wadaのブログ

npm publishの罠

以下のように npm publish をnpm scriptsとして設定するとエラーが吐かれます。

{
  "scripts": {
    "hoge": "npm publish"
  }
}

// yarn hoge

npm notice
...
npm ERR! code ENEEDAUTH
npm ERR! need auth auth required for publishing
npm ERR! need auth You need to authorize this machine using `npm adduser`
...

ここに関しては理由がわからないです。
たぶんローカルの.npmrcに記載しているauth情報を取得できていないからだと思います。

CHANGELOG.mdを作る

CHANGELOG.mdは、そのパッケージの変更履歴をパッケージのバージョンと共に記述し、ユーザーにどんな変更があったのかを知らせるために作成します。
例えばこんな感じです。 f:id:tyankatsu:20181115231607p:plain

これをイチから作るのも面倒なので、僕はgenerate-changelogを使っています。
これは、ルールに従ったコミットコメントを書くと、整形されてCHANGELOG.mdが生成されるというものです。

例えば以下のようなコミットコメントを作成します。

feat: :tada: generate-changelog追加

すると、 f:id:tyankatsu:20181115231641p:plain このように自動的に New Featuresの項目としてコミットコメントが追記されます。末尾のリンクはオプション設定でつけられますが、該当コミット内容詳細に飛びます。

ユーザーに、今回のバージョンアップはこのようなことをやったよということを知らせることができるので、入れておいたほうが良いと僕は思ってます。

CONTRIBUTING.mdを作る

いろいろな人に関わってもらえるようになると、issueの立て方やPRsの作り方、コミットコメントのルールなどを作って、一貫性を持たせて作業してほしくなります。
そういうときにはCONTRIBUTING.mdを生成してその中にお約束ごとを記述しておきます。こういうふうに書くといいらしいです
GitHubだと、プロジェクト直下にこのファイルを置くと、issueをたてるときやPRsを作る時にリンクが出てきます。
秩序が保たれるようにルールを決めておきましょう。

TemplateでissueとPRをきれいに出せるようにする

GitHubの話になりますが、issueとPRsのテンプレートを作成することができます。GitHubのIssue・Pull Requestのテンプレート機能を使おう - Qiita

issueを作るときはこんな画面でどのテンプレートを使うか選択可能です。 f:id:tyankatsu:20181115231658p:plain

PRsは最初から中身が入った状態でPRsが作られます。

travisでnpmにパッケージ公開してもらう

自分でnpm publishと打ち込むのもいいですが、なんせ面倒です。
なので、僕はtravisにpublishしてもらうついでに、babelでのbuildもしてもらいます。
バージョンタグを打ったらtravisが走るように設定してます。

language: node_js
node_js:
- 10

dist: trusty
sudo: false
cache: yarn

branches:
  only:
  - "/^v?[0-9\\.]+/"

script:
- yarn build

deploy:
  provider: npm
  email: $NPM_EMAIL
  api_key: $NPM_TOKEN
  on:
    tags: true
  skip_cleanup: true

{
  "scripts": {
    "build": "babel src --out-dir lib"
  },
}

travisの環境変数にdeployに必要なemail、authTokenを入れます。
情報はローカルの.npmrcに書いてあるので、コピペします。

init.author.name=name
init.author.email=email //ここ必要
init.author.url=url
//registry.npmjs.org/:_authToken=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx //ここ必要

なお、環境変数はtravisのログに表示・非表示の切り替えができます（デフォルトは非表示）が、表示する必要がないですし、セキュリティの面も考えて、ここは非表示にしておきましょう。

travisでデプロイ時のnpmの二段階認証の罠

こちらの記事が参考になったので、参照してください。
Automated npm releases with Travis CI

npm運営に相談

公開したくないパッケージを公開してしまって、非公開にしたい場合、24時間以内であれば、npm unpublishで消せます。（一回消したパッケージはその後24時間、同じ名前で公開することが不可能になります） npm-unpublish
しかし、やらかしてしまった場合は、support@npmjs.comでメールを送ることでなんとかしてもらえます。頑張って英語でメールしましょう。大体悟ってくれます。

最後に

そんなにハードルは高くないので、まずはscopeしたパッケージでも作ってみてはどうでしょうか？？