FlowにImmutable.jsの型定義を取り込む
Immutable.jsの型定義の取り込みできた。今後は応用して他のライブラリも手動で取り込みできよう。
# .flowconfig [ignore] # .*/node_modules/* こいつが邪魔してた .*/node_modules/eslint-plugin-jsx-a11y/* .*/node_modules/react-event-listener/* .*/sass/* .*/static/* .*/bin/* .*/pkg/* .*/src/* .*/vendor/* [include] [libs] # Immutable.jsの型定義ファイル ./node_modules/immutable/dist/immutable.js.flow [lints] [options] esproposal.decorators=ignore suppress_comment= \\(.\\|\n\\)*\\flow-suppress
まず、「$ flow-typed create-stub immutable@3.8.1」ととりあえず通すために手動でつくっちゃった型スタブファイルは削除します。そして、.flowconfigのlibsに、node_modules以下にインストールされているImmutable.jsのフォルダを探して特定した.js.flow型定義ファイルを登録します。しかしignore設定でnode_modules全体を排除しているとlibsが効かない。うーん、バグとはいえないがバグっぽい動きだなあ。私の環境では、eslint-plugin-jsx-a11yとreact-event-listenerが引っかかってたのでそれだけを明示的に除外するようにしました。
.js.flow
今回みつけた型定義ファイルですが、拡張子が.js.flowとなってました。.js.flowファイルを私のnode_modules以下でfindするとfbjs・github・immutable・invariant・throatだけ、拡張子が.jsで「declare type」を含むものはなし。まだまだですな。redux-formは最新のv7でFlow対応しているけど、redux-form-material-uiがpeerDependenciesにredux-formをv6で書いているので、いずれ。
もうひといきFlowが成熟したら提供ライブラリも増え、この辺のワークは全自動に近い感じになってくるでしょうが、おそらく最低一年はかかるかな。しかし、数日前に気になる記事が…
Facebook OSSのライセンス問題
日本語抄訳：スタートアップはReactを使うべきではない (BSD + patentsライセンスを考慮して) — もし、いつか大企業に買収されたいと望むなら | To Be Decided
React・Jest・Flow・Immutable.jsと、私はFacebookのOSSをスタック一式で使ってますが、そのFacebookのライセンス戦術があからさまに攻撃的であるという内容。Facebookへの特許訴訟を要件とした反撃策なので、ほとんどのプログラマーは目先の充足を排してまで今に考えることじゃないかな。しかし業界内のOSS資本投下が可能な組織の取り組みが変わってFlowのエコシステムの成長が阻害されることがあると残念です。型定義ライブラリの充足には全体の協力が必要なので、穏便に計画を進捗させてほしい。
ところで、gitの登場でOSS利用者のメンタルが変わったと思います。gitはそれまでのFork equals Fake（OSSのコードの自家製分岐バージョンを作るのは嫌われる）というFSF的なOSS原理主義での考え方に反して、Cloneして書き換えてPull Requestを送るというForkを積極的に正統な開発作法として取り込むようになり、結果としてWebpack等のバンドルツールを正統な開発手法と認知しています。昔のままならバンドルツールはコードを書き換えるわ、削るわで、存在が怪しいものになってしまってたでしょう。とにかくgithubをザクッと検索してザクザクっとソースやドキュメントを読んでザクザクザクっとコードを取り込み時には書き換えてと、昔のタブーを忘れてカジュアルにスピード開発しています。
そしてgithubの登場でOSS提供者のメンタルも変えました。githubにフリーのアカウントを取ってプロジェクトを作ればそのままホスティングされるし、特にgoではそのままライブラリのセントラルリポジトリになっています（JavaScriptではnpmがその任を担って、githubはセントラルリポジトリとなってませんがそのうちgo getみたいになるんじゃないかな。ほとんど全部githubなんだし、記述の手間をかければやり方もすでにあるし）。このようにgithubが自分のソフトウェアをOSS化するコストを極限まで小さくしました。
食うに困らなくなった現代人は名声を求めるというのがOSSの文化背景を説明する理屈の一つとされてきましたが、フォークして書き換えてホスティング無料かつ作業も短時間となり、つまりはコストまで困らなくなると、その名声すら動機とならなくなってくることが予想されます。github登場以降のプログラマーはOSSに対してポスト名声の動機付けは特に必要としてなく、git登場以降のプログラマーとして自分の開発プロセス上の課題解決を省力化するように選択を重ねた結果、いままで以上にOSSと日々関わっていくことになったと言えそうです。自分の成果物をクラウド保存していつでも再利用できるようにするだけ、他の人が使いたければ使ってもいいよってだけ。名声の名残はプログラマーの転職時にはアカウントでの成果がレジュメの一部となるぐらい。
今回の特許訴訟に組み合わされたFacebook OSSのライセンス戦術は、副作用として大企業のOSS開発＆提供へ資本投下する動機付けを発明したかもしれないですね。ビジネスを守るために企業が大金を投じてがんばって流行るOSSを作ったり、流行ってるOSSの著作者をプロジェクトごと買って囲いこめば、世のプログラマーが極端に省力化しているのでこのパテントテクニック/スキームは野火のように広がる。昔のGPL汚染ガーとか言ってたレベルの拡大スピードではないと思います。しかし、そもそもの論点としてこのスキームは法廷的に有効なのか？誰かがReactアプリ作ってからFacebookを特許訴訟してみないことには、どうなるか正確に予想できる人はいないんじゃないかな。特許と、その特許にまったく関係ない著作物の再利用とで、緊密にリンクするって単純なことじゃないように思います。よってFacebookにとって、犬が散歩道でおしっこ撒き散らしてるぐらいにしかならないと薄々思う。
特許訴訟に有効だとしても、OSS提供企業と著作権がどうしたということになってビジネスにクリティカルな痛手を被るリスクがここまでカジュアルでスピードの速い開発環境を得ているコストと比較してどうなのか。やっぱり私の今日の結論としては、目先の充足を排してまで今に考えることじゃないかな。
Update, 9/23
React、Jest、Flow、Immutable.jsについて、Reactはv16から他も同様にMITライセンスにするという。
