blogこの広告は、90日以上更新していないブログに表示しています。15時限目に参加したときにふと思った疑問について。installしたときに警告を出すことができた。逆に削除されたAPIを使っている場合はバージョンの上限も指定できる。非推奨ながらengineStrictフィールドを使うと警告ではなくエラーにできる。installしたユーザーに何らかの警告を知らせることはできるのだろうか?というのが今回の疑問。io.jsのissueを見てみるとまさに議論中だった。detectで対応していこう、という流れになっている(ように見える)。コード例としては、パッケージ作者が内部でGeneratorを使ったコードfoo.es6.jsを書く場合、トランスパイラでfoo.es5.jsを生成しつつ、呼び出すところfoo.jsでこう書くとのこと。detectで書かないといけないのか?MUSTはムリ。detectが任意だとしたら、そのパッケージをインストールするユーザーが動作環境を知る術が結局無いことになる。detectできる問題に限定されてる。CHANGELOGを見れば分かるように細かな差分は既に大量にあって、detectどころか、何が差分なのか把握すら難しい。Node.jsでも走らせたいコードだったら最初からio.js専用APIとか使わないのでは?互換性を目指すよりも動作環境を明示できれば十分なのでは。いうことで、この方法は破綻するのではと思った(または議論をミスリードしているか)。するか?自分の意見としては、パッケージ作者が想定している、すなわちテストしている(もっと具体的に言えば.travis.ymlで指定している)環境をenginesフィールドに書くしかないと思っている。}Node.jsもサポートしたけりゃ自前でトランスパイルなりすればいいし、したくないならiojsだけ書いとけばいい。現状npm側はnode以外は対応してないけど、ここでiojsも対応して警告を出してもらえば良い。参考に見てみたらkoaのpackage.jsonもこの書き方になってた。懸念されるディストピア当然ながら、この方法はかつてブラウザ業界が味わったUser-Agentの苦い記憶が思い出される。予想される最悪な未来として、io.jsがそこそこ流行る。書いて最新機能を使いまくる。Node.jsがV8上げて最新機能に対応してもpackage.json更新してくれない警告出るままのパッケージが多すぎる。怒ったJoyentがNode.jsのprocess.versionsを偽装してio.jsと偽るようになり、npmのチェックをすり抜けるようになる。detectしよう!という啓蒙とともにライブラリModernodeizrが開発される。これに対する反論としては、たかだか警告で動かないわけじゃないんだし良いじゃないっていうのがひとつ。一つは、仮にあるfeatureの対応がdetectできたからって、パッケージ作者が想定(テスト)してない(または多くのユーザーが使ってない)環境で動かせるぐらいNode.jsとio.jsって今後互換性が保たれるの?っていう点で現状のCHANGELOGと開発の流れを見る限り自分は懐疑的なので、実際動かないならしょうがないじゃない、と思う。いったことをissueで議論するだけの気力と英語力が無かったのでとりあえずブログに書いた。