npmrcのドキュメントを読みなおしていたら、.npmrcは/path/to/my/project/.npmrcのようにプロジェクト毎に配置することが出来る事に気づいて、ちょっと使ってみたら便利だった。

globalやhomeディレクトリへの設定を前提としたnpm configの記事は結構あるが、プロジェクト毎でnpm-configについて書かれている記事があんまり無かったのでまとめてみる。

npm-configの何が良いのか？ project毎に出来ると何が良いのか？

npm-configの設定をすると、色々コマンドを省略出来たりして良い事がある。
(参考:2016年版 Node.jsで幸せになれる10の習慣)

npmrcやnpm-configは、個人開発用であれば、$HOME/.npmrcへの設定だったりnpm config setでの設定で十分。
また、npm registryに登録するライブラリやオープンソース向けのプロジェクトの場合だと、プロジェクト毎の.npmrcがあるとむしろ弊害になることもありそう。

しかし、frontend向けの開発をチームで行う際では色々設定しておくのは便利に使えるものが多い。

例えば「npm shrinkwrapするときは--devつけてください」と言わなくても済むなど効果が見込める。

この記事の対象者・対象プロジェクト

npmを実行するメンバーが一定数以上いるプロジェクト
- 個人開発とかならglobalで設定しましょう
node.js、javascriptに明るくないメンバーが一定数いるプロジェクト
- みんなが詳しいチームだったら不要でしょう
npm registryに登録したり、オープンソースで運用したりする予定ではないプロジェクト
- 例：frontend開発のために、npmをパッケージマネージャとして利用しているプロジェクト
- オープンソース前提の場合は、多分無いほうが良いでしょう

npmrcの基本・記法

記法

iniファイルっぽい。こんな感じ

some-setting=value

複数値を設定する方法も紹介されている

key[] = "first value"
key[] = "second value"

故障かな？と思ったら

意図した設定されてない！となった場合は、下記のコマンドを叩くと良い

$ npm config list

これで、.nprmcのパース結果を出してくれる。globalの設定も含めてくれる。

間違った値を入れた場合はこの結果一覧には出てこなくなる。

個人的おすすめ便利設定

とりあえず個人的におすすめ設定を晒してみる。
詳細は後述

### だいたい設定しといて良さそう（スタメン）
also=dev
save-exact=true
progress=false
engine-strict=true

### 場合によっては使うことがありそう
# loglevel="error"
# if-present=true
# save-prefix="~"
# link=true

スタメン（だいたいのプロジェクトで使える系）

also=dev

devかdevelopmentを設定することで、shrinkwrap、outdated、updateコマンドを実行するときにdevを含めるようにしてくれる。
shrinkwrapなどは--devつけないと警告が辛い事がほとんどなので、devにしておくのがベターなイージ

この逆っぽいonlyというのもある。（個人的に必要になった事が無いのでそんなに調べてない）

save-exact=true

npm install、npm rm時に自動的にオプションをつけるように変更してくれる。

save-exact=trueにすると、npm install -S some-packageがnpm install -S -E some-packageと同じ動きをしてくれる。

フロントエンド向け開発だと、shrinkwrapをする場合が多いので、結局exactもしてしまって差し支えない事がそれなりにある。
そういう場合にこのオプションが便利。

progress=false

falseにするとnpm installするときに出てくるprogressバーを抑止出来る。
「progressしてるとnpm installめっちゃ遅い！」という話があったりするので、progressあんまりいらないな、と思ったら切って良い。

CI向けの高速化としても使える。

engine-strict=true

install対象のpackageのpackage.jsonのenginesを見て、Node.jsのバージョンが合致しなかった場合はnpm installを失敗扱いにしてくれる。

ちゃんとしたパッケージならそれなりのバージョン対応しているし、このへんが甘めなパッケージはenginesを設定してない可能性が高いので防御力は低いが、それでも無いよりマシぐらいな物ではあるだろう。

ベンチ入り（必要に応じて使いそう）

save関連

save-exact以外も結構色々あるので、必要に応じて使い分ける

save, save-dev

save=true
save-dev=true

「とりあえずこのプロジェクトは全部devDependencyにしときたい」という場合があればこのあたりが使えそう

ちなみに、save-dev=trueにすると、npm install -S hogeでもdevDependencyに保存されてしまう。バグなのか仕様なのかは追ってない。

save-bundle、save-optional というのもあるが、あんまり用途が思いつかない

save-prefix

save-prefix="~"

defaultでnpm installすると、^1.0.0という、バージョニングになるのを変更出来る。

参考：semantic versioning

link

link=true

npm install時の挙動をnpm install --linkにする。
結構癖があるイメージなので、ちょっと取り扱い注意かもしれない

エラー抑止・CI関連

loglevel

loglevel=error

npm実行のログレベルをいじる。デフォルトはwarn。

warnだと、依存したパッケージのエラーが出てしまってどうしようもなかったりすることがある（当然消せたほうが良いが）。
あまり綺麗な方向ではないのですごく悩ましいが、チームの考え方次第ではerrorに設定するのもアリかもしれない。

ちなみに、この設定があっても下記のようなオプションをつければログが出てくれる。

$ npm i --loglevel=warn

if-present

if-present=true

npm run sonza-sinai-commandのように、存在しないコマンドを叩いた時、デフォルトではerrorを吐くが、何も吐かなくなる。
circle-ciなどCIツールの邪魔をしないようにするなどが想定されている。（npm set if-present trueとかでも十分かもしれない）

当然だが、設定すると、エラー時に何が起きたかわからない。

color

color=false

色をオフにする。CIとかで使いたい時に使う

通信系

proxy, http-proxy

Proxyを通す必要がある場合など、プロジェクト単位で設定しておけばデザイナーなど非エンジニアの環境セットアップが少し楽になりそう。
個人的に必要に迫られたことが無いのであんまりちゃんと追ってない

補欠（おまけ。工夫次第で使えそうなもの）

別名：global向けなのでprojectスコープだと使い所が見つけづらいもの

heading

heading="some-heading"

コンソール出力の「npm」ってなっているところを変更できる。

絵文字とか使えるので、コンソールを華やかにしたいときに使える

heading="🌸"

% npm i react                                              
example-dir@1.0.0 /project/example-dir
└── react@15.3.0

🌸 WARN example-dir@1.0.0 No description
🌸 WARN example-dir1.0.0 No repository field.

editor

editor="emacs"
editor="vi"

npm edit npm config edit時に利用するエディタを$EDITORを使わせずに、強制させる。
どうしてもエディタについて喧嘩をしなければならない時の嫌がらせとして使える。

同類でshellというのもある。shellで争う場合はこちら。

※ みんな仲良くnpmを使おう

searchexclude

searchexclude=grunt

$ npm searchする際のexclude条件を指定する。
なにか強い意思で特定のプロダクト関連を検索させたくないという場合はつかえるが、そもそもnpm searchを使わないので、プロジェクト毎設定する意味は無い。（global設定だとそれなりに活きる）

project毎のnpmコマンドをいい感じにするnpmrc & config達