Node.jsで例外処理によるプログラムの終了を回避する

Node.jsでは例外処理が発生するとデフォルトでは標準エラー出力にスタックトレースが出力され、プログラムが停止してしまいます。

Node.jsは１つでもエラーが発生してしまうと停止してしまいますので、予期せぬエラーにも対応できるようにしておくのが望ましいです。

そこでprocessオブジェクトのuncaughtExceptionイベントを登録すると、例外処理でエラーが発生した場合でもプログラムが停止せず回避することができます。

process.on('uncaughtException', (err) => {
  console.error(err);
});

補足

uncaughtExceptionでキャッチしたエラー内容ではどのリクエストのエラーかはわからないので、しっかりエラーが起こりそうな箇所にはエラーハンドリングを記述しておくことが望ましいと思います。

githubのプルリクエストのテンプレート設定

githubでプルリクエストを送る時にどのような変更をしたのかの説明を記述すると思います。

そこでプルリクエストをするたびに毎回記述するのはめんどくさいですよね。

そこでリボジトリ直下に.githubフォルダを作りその中にPULL_REQUEST_TEMPLATE.mdを設定してあげるだけで、毎回記述する手間が省くことができます。

複数人で開発している場合でも、テンプレートを使うようにすれば統一され見やすくなると思います。

例（自サービスで使っているテンプレートの中身）

## 概要

- どこをどのように何のために変更したか

## チェック

- [ ] コミットは適切にまとめられているか (レビュー後でもOK)
- [ ]  この変更にともなうドキュメントの更新はされているか
- [ ] この変更にともなう必要なテストは書かれているか
- [ ] マイルストーンは設定されているか (ない場合は作成)
- [ ] レビュワーのアサインはされているか

このようにプルリクエスト時に記述された状態になってくれます。便利ですね！

git rebaseコマンドを使うようになって

今までgitでのコミットログをまとめる事をやっていなかったため、rebaseコマンドを使ってきませんでした。

最近使うようになったので書き溜めておきます。

git rebase -i HEAD~~

~ の数でどこまでのコミットを扱うかの範囲指定します。

上記のコマンドだとHEAD から１つ前のコミットログまで指定していることになります。

そしてgit rebase -i HEAD~~を打つと

例

pick 9a54fd4 commitの説明を追加
pick 0d4a808 pullの説明を追加

# Rebase 326fc9f..0d4a808 onto d286baa
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

上記のように、２つのコミットログが表示されます。

例えば pick 0d4a808 pullの説明を追加をfixup 0d4a808 pullの説明を追加と書き換えると

pick 0d4a808 pullの説明を追加の内容がpick 9a54fd4 commitの説明を追加に取り込まれ１つのコミットとして扱われるようになり、コミットログがpick 9a54fd4 commitの説明を追加だけになります。

よく使いそうなコマンドの説明

(p)pick: コミットをそのまま残す。
(r)reword: コミットメッセージを変更。
(e)edit: コミット自体の内容を編集。
(s)squash: 直前のpickを指定したコミットに統合しメッセージも統合。
(f)fixup :直前のpickを指定したコミットに統合しメッセージは破棄。

pick reword edut squash fixup それぞれ頭文字だけで書くことも可能です。

CSSでカラー等を変数で管理する

:rootに定義する

:root {
  --theme-color: #FFF
}

というように :root 擬似クラスに --theme-color という変数名で #FFF が定義する事ができます。

あとはここで定義された変数は

.text {
  color: var(--thema-color);
}

として var(--theme-color) として使用する事ができます。

変数でよく使う色だったり文字サイズだったりを変数として定義していればCSSの管理は楽になるのではないでしょうか。

npm installでのmodulesのバージョン指定でのハマり

npm install コマンドを叩いて package.json で管理されている modules 達をインストールします。

typescript を使っているのですが、バージョン2.4~ に上げてしまうとrxjs との互換性がまだできていなくエラーになってしまいます。

ローカル環境での typescript は 2.3.4 で使っているのですが、CircleCi上で npm install された時に 2.4.1 になってしまっていてエラーがどしゃーっと出てしまっていました。

ずっとなんでだろうと思っていたのですが、package.jsonでのバージョン固定をしていなかったのが原因でした。

typescript : ^2.3.4

となっていました。

^2.3.4 の 前に付いている ^。キャレット表記というらしいです。

一番左側にある、ゼロでないバージョニングは変えない (それ以下があがることは許容)

例えば

^1.2.3 = 1.2.3 <= version < 2.0.0
^0.2.3 = 0.2.3 <= version < 0.3.0
^0.0.3 = 0.0.3 <= version < 0.0.4

となってしまうので、 2.4.1 にバージョンが上がってしまっていたのでした。

対応としては ^ を外してしまうか shrinkwrap を使って、npm-shrinkwrap.json で記述されるバージョンで管理する方法があるみたいです。

補足

npm-shrinkwrapはnpm@5になってから package-lock.jsonが生成されるようになり、不要となります。

環境変数にBasic認証の設定する

Node.jsの開発環境によってBasic認証を設定する場合があると思います。

例えばAPIにBasic認証を設定する時に、javascriptで定数にそのまま入れてしまうと、コードにそのまま吐き出されてしまうのでバレてしまい、Basic認証をしている意味がありません。

そこでアイパスを環境変数に設定し、それを参照するようにします。

env コマンドで現在の環境変数が表示されます。

export ID=test

上記のようにコマンドを叩くと ID=test と設定され

process.env.ID を参照すると test が取得できます。

unset ID コマンドを叩くと ID=test は消去されます。

この環境変数を参照するようにアプリ側で実装すれば、javascriptのコードにも変数名が入ってくるだけなのでバレることもないでしょう。

SPAでhistory backでのスクロール位置

SPAを実装したことのある人なら誰もが一度はつまづく画面遷移時のスクロールポジション。

自分も「このタイミングでこの位置にいてほしいのに。。。」と思う事が多々ありました。

特にブラウザバック時にいたスクロールポジションを保持している時の対応。

ポジション移動のタイミングが早くて、見た目が変になるという案件にぶつかりました。

いっその事全部自分で管理できたら嬉しいのですが。。。

そこで役に立ちそうなのが scrollRestoration。

Historyインターフェースに追加されました。

history.scrollRestoration = auto

これがデフォルトの設定です。

history.scrollRestoration = manual

としてあげると、スクロールポジションの復元がされなくなります。

ただ、まだ新しい技術なので対応していないブラウザがまだまだあります。

developer.mozilla.org

使いどころには注意しましょう。