この記事は…
- Node.js で、関数などを非推奨（deprecated）にする方法がわかります
- コメント・コードそれぞれで非推奨化するメリットについて整理できます
deprecated、きちんとやってますか？
長期的に開発をやってると、どうしてもでてきますよね。
もう使わないでほしい関数、機能…
コードがパブリックなライブラリであれば当然！
使ってほしくないから消すね！で即削除されてしまうと、
その機能を使っていたアプリは動かなくなってしまいますからね。
移行期間として deprecated 設定は必須ですが！
自社での開発だったり、数人での開発だったりすると、
「この機能はもう使わないようにしようね」
という口約束だけで済ませてたりしませんか？
うっかり使ってしまってレビューで指摘されないように、
クローズドな開発でも、使わない機能にはしっかり設定していきたいですね。
Node.js は deprecated の書き方が複数あるって、知ってました？
最近では、ほとんどの言語で設定できる、 deprecated 設定。
実は Node.js では書き方が複数あるって知ってました？
しかもそれぞれメリットが違うものですから。
どれか一個知っておけばいい、ってよりは、
どっちも知ってどっちも設定しておきたいですね。
今回は
const func1 = () => {
console.log('do something.')
};
func1();
こんな感じの記述があって、 func1 関数を deprecated にする前提で見ていきましょう。
1 つ目: コメントで書く方法
これは割とよく知られている書き方なのではないでしょうか。
/**
* @deprecated バージョン 2 からは func2 を使用してください
*/
const func1 = () => {
console.log('do something.')
};
func1();
こんな感じで、関数のすぐ上に @deprecated {コメント} のコメントを書く方法です。
コメントで書くメリット
これの良いところは、 VSCode などの IDE を使用している場合、
deprecated となっていることと、そこにつけられたコメントが
呼び出し側から参照できることでしょう。
VSCode での表示(関数にマウスオーバー)
開発者がこの関数を使用しようとした時、主要な IDE では
- 打ち消し線が表示される
- カーソルオーバーなどで詳細が表示される
ようになっているので、
「ぁ、これはもう使わないほうがいいんだ」
と気付けるようになりますね。
コメントで書くデメリット
IDE上に表示されるだけなので、
呼び出し元の表示を見ないと気が付かないってことはありそうです。
開発中に該当の関数を使おうとして…って場合であれば当然見るので OK なのですが、
既に使っている関数が後から deprecated になった、という場合は、
そのファイルを開くまでは気付けないかもしれません。
2 つ目: コードで書く方法
こっちは、コメントの方法よりもちょっとマイナーかも知れません。
const util = require('util');
const func1 = util.deprecate(() => {
console.log('do something.')
}, 'バージョン 2 からは func2 を使用してください');
func1();
util.deprecate(元の関数, メッセージ) の形式になっていますね。
この util.depricate で囲むことでも、deprecate であることを表現できます。
もしくは、
const func1 = () => {
process.emitWarning("バージョン 2 からは func2 を使用してください", {
type: "DeprecationWarning",
});
console.log('do something.')
};
func1();
こんな感じで、処理内に console.log を書くのと同じような感じで
process.emitWarning("バージョン 2 からは func2 を使用してください", {
type: "DeprecationWarning",
});
と書いても、同様に deprecation であることを
コードで書くメリット
コードで書くと、そこの内容が実行された後、
エラー出力の方に警告が表示されます。
DeprecationWarning の表示がでている
よって、使われていて、ログをきちんと見ていれば
過去の改修で使用していた関数についてもきちんとキャッチアップできる、
というのは大きなメリットになります。
emitWarning を使う方法でも同じように実行時の警告ログを出せますが、
こちらは処理されるごとにログが出ますので、うまく使い分けてくださいね。
コードで書くデメリット
コメントの逆で、IDE 上で deprecated になっていることがわからない
ということは最もデメリットとして大きいでしょう。
depricated になっているが表示上の変化はなにもない
実行してみて初めて気づく、というパターンは多そうですね。
加えて、どうしてもコードに手が入るので、
実行内容に影響がある、というのは気になるところです。
util.deprecate は元の関数を返り値として返すので、
影響はないはずなのですが、
実行時の挙動に変更点があると考えると、修正に伴ってのテストだったりとかは
しっかりしておいたほうがいいですね。
もう一つ、 deprecated になっていると分かったうえで、
修正工数が捻出できずに一旦そのまま…って時には、
実行のたびにエラーが出るのはちょっと邪魔かもしれません。
node --no-deprecation ファイル名
と、起動時に --no-deprecation を引数として指定することで表示を抑えられるので、
場合によっては本番ではこれをつけて起動する、という運用が必要になるかもしれませんね。
どっちも観点として必要なので、どっちもつけよう
開発時に気付けるってのも大事だし、
既にコードに入ってる部分についても気付けるってのも大事だと思うんですよね。
ので、どっちもつけるようにしたらいいんじゃないかなと。
大事なのは、非推奨にしたい関数について、
確実に利用率を下げて、代替案に切り替えてもらうことですからね！
Discussion