別にしんどくないブログ

技術のことや読書メモを書いています

Node.jsへのコントリビュート解説、そしてOSSへ貢献するということ

https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fstatic.webpunks.co%2Fuploads%2F2016%2F08%2Fnodejs-modules-webentwicklung-webdevelopment-webpunks.jpg&f=1&nofb=1

この記事は Node.js Advent Calendar 2019 - Qiita の2日目の記事です。遅くなってしまいました。

Node.js本体へのコントリビュート解説記事です。この記事は不足している情報や更新があれば、モチベーションが続く限り更新していきたいと思っています。

JSConf JPのスタッフの打ち上げのときに日本人のNode.jsへのコミットしている人が少ないという話がでました。

Node.jsに限らずOSSへのコミット経験があるという人は私の周りには少ないです。

もちろんOSSにコミットしているから良い悪いという話ではなく、Node.jsやOSSにコミットしてみたいと相談いただくことが時々あるので僕の経験でよければ伝えたいと思いました。

私の経験からNode.jsへのコントリビュート方法の解説とOSSへの貢献を通じて得たものについて書き残しておきたいと思います。

言葉の定義として、コードやドキュメントにコミットするだけでなく、「Issueを作る」「Pull Requestを送る」をまとめてコントリビュートと呼ぶことにします。

Node.jsのコントリビュートについてはGitHubのNode.jsのリポジトリに書かれています。

github.com

また、 大津さん(@jovi0608)が2016年のCode And Learn用に翻訳を公開してくれています。

github.com

今回はこのドキュメントをもとに私の経験や補足を合わせて解説します。

また、Node.jsのコラボレーターになったときに書いた記事もご興味あればご一読ください。

shisama.hatenablog.com

目次

解説をする前に

Node.jsにはmasterブランチへのwriteの権利を持っていてコードレビューを行ったりCIを実行する人々が世界中にいます。彼らのことをコラボレーターと呼びます。

さらにコラボレーターの中から数名が仕様を決めるTechnical Steering Committee(通称TSC)がいます。

彼らだけがNode.jsの開発をしているわけではありません。定常的にコミットはしなくてもコードやドキュメントの修正を行ってくれたりIssueを作って議論してくれるコントリビューターがいるからこそNode.jsはこれまで生存してきました。

Node.jsに限らずOSSはそういった人々に支えられています。

なので、基本的にコラボレーターはコントリビューターに対して感謝の気持ちを持っています。できるだけ気持ちよく開発できるように心がけている人が多いと感じます。

なので、恐れずにチャレンジしてほしいと思います。

Node.jsへのコントリビュート解説

Code of Conductを読む

Code of Conductとは行動規範です。
OSSは様々なバックグラウンドを持った人が関わっています。Node.jsも例外ではありません。
そのためOSSではCode of Conductを守ることは最も大切なことと言っても過言ではありません。

必ず読みましょう。

node/coc.md at master · nodejs/node · GitHub

過去にCode of Conductを違反したことがきっかけでコアメンバーの除名処分が議論されたこともありました。

yosuke-furukawa.hatenablog.com

Issueを作る

Issueによるバグ報告や質問やフィードバックや機能要望はとても大切なコントリビュートの一つの形です。

Node.jsに関するIssueには2種類あると考えています。
1つ目がNode.jsを使った開発に関する質問、2つ目がNode.jsコアに関する質問やバグ報告や機能要望などです。 細分化するともっとあるかもしれませんが、大きく分けるとこの2つだと考えています。

どちらのIssueにしても直面した問題や質問に関してできるだけ詳しく書くことが解決への一番の近道だと思います。

Node.jsを使った開発に関するIssue

Node.jsを使った開発に関する質問は、nodejs/helpにIssueを作るとよいでしょう。 nodejs/nodeの方にIssueを作ったからといって怒られたりすることはないと思いますが、nodejs/helpの方に書くように促されることはあるかもしれません。

Issueテンプレートが用意されているので、Issueを作ろうとすると以下のように本文にテンプレートが最初から書かれています。

f:id:Shisama:20191203220453p:plain
https://github.com/nodejs/help/issues/new

以下のようにNode.jsのバージョン、動かしたOSのバージョン、スコープ、関係のあるパッケージ(なければ省略)を書いてください。

  • Node.js Version: 12.2.0
  • OS: macOS 10.13.6
  • Scope (install, code, runtime, meta, other?): install
  • Module (and version) (if relevant): jest

Node.jsコアに関するIssue

Node.jsコアに関する質問やバグ報告や機能要望などは、nodejs/nodeにIssueを作るとよいでしょう。
コアというのはNode.js本体のことを指します。 例えば、Node.jsでファイルシステムを操作するfsにバグがあったり、機能追加の要望を出したい、という場合です。

nodejs/nodeのNew Issueボタンを押すと以下のような選択画面が表示されます。

f:id:Shisama:20191203224941p:plain
https://github.com/nodejs/node/issues/new/choose

この画面では以下の選択肢があります。

  • Bug report: バグ報告
  • Feature request: 機能要望
  • Report a security vulnerability: 脆弱性報告。セキュリティポリシーへのリンクになっています。
  • ⁉️ Need help with Node.js?: Node.jsに関する質問。先に紹介したnodejs/helpへのリンクになっています。
  • 🌐 Found a problem with nodejs.org?: Node.js公式ウェブサイト nodejs.org に関する問題報告です。nodejs/nodejs.orgのissue作成画面へのリンクになっています。

ここでは上記のBug reportについて説明をします。
Bug reportを選択すると以下のようにIssueテンプレートが書かれた画面が表示されます。

f:id:Shisama:20191203225712p:plain
https://github.com/nodejs/node/issues/new?template=1-bug-report.md

そこに以下のようなバージョン情報とモジュール名を記載します。

  • Version: 13.1.0
  • Platform: macOS 10.14.6
  • Subsystem: fs

Subsystemについて

このSubsystemには以下の中からリポジトリ内のどこに問題があったかを書きます。

  • lib/*.js (assert, buffer, etc.)
  • build
  • doc
  • lib / src
  • test
  • tools

lib/*.jsassertfsstream...などNode.jsコアが提供しているモジュールを書いてください。

Subsystemについて難しい場合は、以下を基準にしてください。

  • コードに関すること: lib / src
  • Node.jsコアのビルドに関すること: build
  • nodejs.org/api などドキュメントに関すること: doc
  • nodejs/node内で実行するNode.jsコアのテストに関すること: test
  • nodejs/node内で使っているツールに関すること(e.g. eslint): tools

また、IssueやPull RequestのタイトルにもこのSubsystemを用います。

例えば fs: fsPromises.lchmod throws AssertionError on Ubuntuといった感じのタイトルにすると良いでしょう。

Issueの場合、必ずしもSubsystemの記載が必要とは思いません。そこで挫折してIssueを送らないのであれば、書かずに送ってしまってもいいと個人的には思います。

前述のとおり本文をしっかり書いて伝わりやすくすることが大切だと思います。

また、コードやエラーの内容を載せると伝わりやすいです。私が書いたIssueで宜しければ以下を参考にしてみてください。

github.com

Pull Requestを送る

Pull Requestを送ることはIssueを作ることに比べるとやはり敷居が少し高くなります。 コマンドによる操作やGitの操作に不慣れだと難しいかもしれません。

しかし、送ってマージされてもされなくても学びがあったり感謝されることが多いです。多くの場合、コラボレーターから感謝されるでしょう。

この章ではPull Requestを送るときのルールや気をつけること、どのようなPull Requestから始めるのがよいか説明したいと思います。

Pull Requestを送るまで

手順が多いのでおおまかな流れを先に説明しておきます。

  1. nodejs/nodeをForkしてgit cloneする
  2. nodejs/nodegit remoteで追加する
  3. nodejs/nodeのビルド環境を構築する
  4. ブランチを作成する
  5. コードやドキュメントを修正する
  6. ビルドして動作確認を行う
  7. テストやLintを実行する
  8. ForkしたリポジトリにPushする
  9. nodejs/nodeのmasterブランチに対してPull Requestを作成する

一つずつ説明します。

nodejs/nodeをForkしてgit cloneする

Node.jsのリポジトリに直接ブランチを作らずにForkしてPull Requestを送ります。
nodejs/nodeリポジトリの右上に表示されているForkボタンを押してForkしてください。

その後、Forkしたリポジトリをローカルの任意の場所にgit cloneしてください。

nodejs/nodeをgit remoteで追加する

前述でgit cloneした後にgit remoteを実行すると以下のようにoriginのみが表示されると思います。

f:id:Shisama:20191204021707p:plain
git remote

しかし、nodejs/nodeとコンフリクトが起きるかもしれないので、Pull Requestを送る前にnodejs/nodeのmasterにrebaseしましょう。そのためにupstreamとしてremoteに追加しておきましょう。

$ git remote add upstream git@github.com:nodejs/node.git

Node.js のビルド環境を構築する

Node.jsの大部分はC++JavaScriptによって書かれています。ビルドツールにはPythonが使われています。

以下に記載があります。

node/BUILDING.md at master · nodejs/node · GitHub

OSによって異なります。

macOSの場合

以下が必要になります。

  • Xcode Command Line Tools >= 10 for macOS
  • Python 2.7
    • Python 3.x系はまだ実験的に導入している段階です。2.x系のサポート終了も近く現在3.x系への移行が進められています。

Xcode Command Line Toolsを使うにはXcodeをインストールし、xcode-select --installを実行する必要があります。

ビルドの確認はgit cloneしたnodeディレクトリ内に移動して以下を実行します。

$ ./configure
$ make -j4

makeコマンドの-jオプションは並列処理するジョブを設定することができます。-j4は4並列で処理するように設定しています。並列処理することでビルド時間の短縮に繋がります。

この数値はCPUの数やCPUの数×2など諸説あったり環境によって違ったりするので、値を変更して試してみてください。

./node -vを実行し、Node.jsのバージョンが表示されれば環境構築は完了です。

macOSをお使いで途中でエラーが発生した場合は以下のコマンドを実行してみてください。

$ sudo ./tools/macos-firewall.sh

Windowsの場合

公式には色々と書かれていますが、実は一発で構築してくれるnpmパッケージが存在します。

github.com

Node.jsがインストールされていてnpmが実行できるのであれば以下のコマンドを実行してみてください。

$ npm install --global windows-build-tools

このnpmパッケージを使うことでVisual C++やPython2.7が勝手にインストールされます。既にインストールされている場合はスキップします。

ビルドの確認はgit cloneしたnodeディレクトリ内で以下を実行します。

> .\vcbuild

./node -vを実行し、Node.jsのバージョンが表示されれば環境構築は完了です。

ブランチを作成する

Pull Requestを送るためにブランチを切りましょう。

ブランチ名に関しては特にルールはありません。わかりやすい名前にしてください。

またupstreamのトラッキングが必要な場合は以下のように-tオプションを付けてブランチを作成してください。

$ git checkout -b my-branch -t upstream/master

コードやドキュメントを修正する

ディレクトリ構成

先に簡単に説明しておきます。

node
├── .github
├── benchmark
├── deps
├── doc
├── lib
├── out
├── src
├── test
└── tools
  • .github: IssueやPull Requestのテンプレートなどが置かれています。
  • benchmark: ベンチマークを測るためのコードが置かれています。パフォーマンスに影響が出そうな修正を行うときはここにもコードを追加する必要があります。
  • doc: ドキュメントが置かれています。Markdownで書かれています。https://nodejs.org/api のドキュメントもここで管理されており、doc/apiの中に全部置かれています。
  • deps: Node.jsが依存している他のOSSなどが置かれています。JSエンジンのV8やイベントループ処理をするlibuvもここに置かれています。それらのバージョンアップするときはここに取り込みます。
  • lib: JavaScriptのコードが置かれています。主にfsstreamなどのAPIの入り口はここに書かれます。最近はなるべくC++に処理を書かずにJavaScriptに処理を書いていこうという方針が取られています。機能追加をしたいときはまずはここにJavaScriptで実装してPull Requestを送ると良いでしょう。
  • out: これはビルド結果が出力されるディレクトリです。C++コンパイル後のモジュールやRelease用のnodeのバイナリが出力されたりします。
  • src: C++のコードが置かれています。主にV8の機能やlibuvの機能を使うコードが置かれています。また、JavaScriptではパフォーマンス上問題があるものもC++で書かれることがあります。nodeの起動エントリポイントはmain.ccというところにあります。
  • test: テストコードが書かれています。主にNode.jsが提供しているAPIのテストが書かれています。並列実行できるようにparallelディレクトリに書くことが多いですが、直列実行が必要な場合はsequentialディレクトリに書く必要があったりネットワークが必要であればinternetディレクトリに書く必要があったりします。基本的にlibsrcを修正するときはtestの修正も必要です。
  • tools: nodeの開発に使うツールが置かれています。eslintやテスト用のPythonスクリプトなどがここに置かれています。

主にdoclibsrctestを修正することが多いと思います。
deps内のV8やlibuvやOpenSSLのバージョンアップに関しては詳しいメンバーに任せた方がいいかと思います。

コードスタイル

Lintがあるので、基本的に修正してコミットする前はLintを実行するようにしましょう。

$ make lint

また、.editorconfigリポジトリ内に含まれているので、お使いのエディタのプラグインなどを使ってフォーマットかかるようにしてもいいと思います。

詳しくは以下にまとまっています。

node/STYLE_GUIDE.md at master · nodejs/node · GitHub

node/CPP_STYLE_GUIDE.md at master · nodejs/node · GitHub

コードやドキュメントを修正する

バグ修正や機能追加など明確に課題がありlibsrcを修正する必要がある場合は、もちろんlibsrcのコードを修正してコミットするのが良いでしょう。

libsrcを修正したときはtestにテストコードを追加してください。

しかし、明確なバグや機能追加に関しては特にないけど「Node.jsへのコミットがしてみたい」という方には以下の「テスト」「good first issue」「ドキュメント」へのコミットをオススメします。

テスト

Node.jsのテストはカバレッジが公開されています。まだ網羅されていないモジュールのテストがあればカバーするテストコードを追加するのがわかりやすいと思います。

coverage.nodejs.org

テストを書くことで、libsrcの構成についても徐々に把握していくことができると思います。
コードリーディングを通して知らないAPIを知ることもでき、テストといえど学ぶことが多いです。

id:yosuke_furukawa に勧めていただきfsのPromiseのAPIのテストのカバレッジを増やしていくところから始めました。

github.com

上記のPull Requestのように初めてのコミットではCongratulations @shisama on your first commit in Node.js core! 🎉 🎉 🎉のようにコメントがもらえることが多く、Node.jsのメンバーの人の良さが伝わります。

テストを増やしていくことはとても大切なことです。

以下のようにテストのカバレッジが低いとIssue管理されます。

github.com

good first issue

多くのOSSのIssueにはgood first issueというラベルが用意されていると思います。

nodejs/nodeのgood first issueのラベルが付いたIssue一覧: Issues · nodejs/node · GitHub

このgood first issueというのは初めてコミットする人にオススメのIssueということがわかるように付けられるラベルです。このラベルのIssueを見つけた場合はチャレンジしてみるとよいでしょう。

ドキュメント

APIのドキュメント内でtypoを見つけたり、サンプルコードの不備を見つけたときはdocにコミットしてみるのも良いと思います。

github.com

Lintを実行する

環境に合わせて以下のコマンドからLintを実行してください。markdownC++JavaScriptの静的解析が走りコードスタイルのチェックなどを行います。

macOS/Unixの場合

$ make lint

Windowsの場合

> vcbuild.bat lint

テストを実行する

環境に合わせて以下のコマンドからテストを実行してください

macOS/Unixの場合

$ ./configure && make -j4 test

Windowsの場合

> vcbuild test

さらに詳しくは以下のテストガイドラインをお読みください。

node/writing-tests.md at master · nodejs/node · GitHub

テストカバレッジを取る

テストのカバレッジを取得したい場合は以下のコマンドにてテストを実行します。

$ ./configure --coverage
$ make coverage

テストが完了すると以下のファイルをブラウザで確認してください。

カバレッジlibsrcで分かれています。

  • lib(JavaScript): coverage/index.html
  • src(C++): coverage/cxxcoverage.html

ビルドして動作確認を行う

macOS/Unixの場合

nodejs/nodeのビルドには前述のとおりmakeコマンドを用います。

$ ./configure
$ make -j4

-jオプションについても前述のとおり、お使いのCPUの数に合わせて適宜変更してください。

Windowsの場合

> .\vcbuild

ビルドが成功するとnodeディレクトリの直下から./nodeを実行してNode.jsのREPLが起動することを確認してください。

その後修正した内容に応じて動作確認を行ってください。

コミットする

修正したファイルをgit addしてgit commitするだけです。

$ git add my/changed/files
$ git commit

このときにコミットメッセージに注意してください。

コミットメッセージ

Node.jsではコミットメッセージにルールがあります。

  • 1行目はsubsystem名: 修正内容の概要を書かなければいけません。
  • 2行目は空白の改行にしてください
  • 3行目以降はコミットに関する詳細を書いてください。1行目だけで伝わる場合は3行目以降は不要です。
    • この3行目以降に関連するIssueやPull Requestなどのリンクを貼ってください
      • コミットにより閉じれるIssueがある場合はFixes: https://github.com/nodejs/node/issues/1337のようにFixes:から始めて書いてください
      • 関連する参考リンクはRefs: https://github.com/nodejs/node/pull/3615のようにRefs:から始めて書いてください

まとめると以下のように形になります。

subsystem: explain the commit in one line

The body of the commit message should be one or more paragraphs, explaining
things in more detail. Please word-wrap to keep columns to 72 characters or
less.

Fixes: https://github.com/nodejs/node/issues/1337
Refs: https://eslint.org/docs/rules/space-in-parens.html

ルールに沿わなかったからといって問題にはならないですしコラボレーターが優しく教えてくれると思います。なので、気負わずPull Requestを出してください。

Rebaseする

Pushする前にgit remote addしたupstream/mastergit rebaseしてください。

$ git fetch upstream
$ git rebase upstream/master

git rebaseすることでnodejs/nodeの最新の状態を取り込むことができます。

ForkしたリポジトリにPushする

Forkした自分のnodeリポジトリにPushする前に念の為git remoteで確認してください。

私の場合はFork先がshisama/nodeのため、以下の結果になります。

$ git remote -v

origin  git@github.com:shisama/node.git (fetch)
origin  git@github.com:shisama/node.git (push)
upstream    git@github.com:nodejs/node.git (fetch)
upstream    git@github.com:nodejs/node.git (push)

originリポジトリが自分がForkしたリポジトリになっていることを確認したら、originにPushしてください。

以下はfix-foo-barブランチをpushする例です。

$ git push origin fix-foo-bar

Pull Requestを作成

nodejs/nodeをブラウザで開くと、右上に以下のボタンが表示されていると思います。

f:id:Shisama:20191204200008p:plain

以下のボタンを押してください。 f:id:Shisama:20191204200203p:plain

すると、以下の画面が表示されます。

f:id:Shisama:20191204200327p:plain

本文には以下のテンプレート文章が入力されています。

<!--
Thank you for your pull request. Please provide a description above and review
the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md
-->

##### Checklist
<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

- [ ] `make -j4 test` (UNIX), or `vcbuild test` (Windows) passes
- [ ] tests and/or benchmarks are included
- [ ] documentation is changed or added
- [ ] commit message follows [commit guidelines](https://github.com/nodejs/node/blob/master/doc/guides/contributing/pull-requests.md#commit-message-guidelines)

<!--
Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.
-->

<!-- -->で囲まれている部分は変更する必要はありません。

この中で重要なのはチェックリストです。

確認した事項にチェックを入れていってください。

  • [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [ ] tests and/or benchmarks are included
  • [ ] documentation is changed or added
  • [ ] commit message follows commit guidelines

日本語に訳すと、

  • [ ] make -j4 test (UNIX) または vcbuild test (Windows) が通ること
  • [ ] テスト(test)やベンチマーク(benchmarks)が含まれていること
  • [ ] ドキュメントが変更、追記されていること
  • [ ] コミットメッセージが ガイドラインに従っていること

コミット内容によっては全てチェックする必要はありません。

例えば、テストを追加しただけの場合はドキュメントの変更などは無いのでdocumentation is changed or addedにはチェックを付ける必要はありません。

また、本文に追加情報が必要な場合は書いてください。

ここまできたらCreate pull requestボタンを押してPull Requestを送ってください。

コードレビュー

Pull Requestを送るとNode.jsのコラボレーターのメンバーがコードレビューしてくれます。

もし、なかなかコードレビューしてくれなければ @nodejs/collaboratorsとコメントしてコラボレーターにメンションしてください。

コードレビューで指摘があった場合は適宜修正したり議論してください。

CI

コードレビューで承認され始めるとコラボレーターがCIを実行してくれます。このCIはJenkinsで動いています。

Node.jsは様々な環境で動作しなければいけないため、数種類のOSやCPUアーキテクチャによるCIジョブが動きます。

f:id:Shisama:20191204201954p:plain

これら全てが通らない場合は何が原因かCIの結果を見て解決させましょう。

また、破壊的変更とみなされる修正の場合、代表的なnpmパッケージで正常動作するかテストが行われます。それによりnpmのエコシステムに影響が無いことを担保しようとしています。

例えばreacteslintなど100種類以上のパッケージでテストが行われます。

それがCITGMです。

github.com

CITGMでどのパッケージをテストしているかは citgm/lookup.json をご確認ください。

Landed 🎉

コラボレーターが承認してCIが通ればauthor readyというラベルが貼られます。このラベルが貼られたあと48時間の間に他のコラボレーターから反対意見などが出なければコラボレーターがmasterにマージしてくれます。

f:id:Shisama:20191204202342p:plain

これで初めてのNode.jsへのコミットが完了です🎉🎉🎉

英語について

ここまで触れてきていませんでしたが、OSSの世界ではコミュニケーションはすべて英語で行われます。

ただ、Google翻訳を使って読み書きすれば全く問題なくコミュニケーションはとれるので気負わずにコミュニケーションをとってほしいと思います。

Node.js コア以外へのコントリビュート

Node.js コア以外にもNode.jsへのコントリビュート方法はいっぱいあります。

例えば、ブログや勉強会で発信することもコントリビュートの一つだと思いますし、ドキュメントの翻訳をしたりOSSのコントリビュートのサポートをするのも立派なコントリビュートだと思います。

発信したり行動することで批判があるかもしれませんが、もっと良いこともたくさんあるので気負わずに行っていただけたら良いなと個人的には考えています。

はじめてのOSSへの貢献

ここからは私個人の話になります。技術的な話は出てきません。

この章は私がOSSへ貢献をしたことによる変化や影響に関する話です。

Node.jsにコミットする前からOSSへのコントリビュートの経験はありました。
はじめてOSSに貢献したのは、Key-ValueストレージのLevelDBをNode.jsで使うことができるようにするlevelupのハンズオンlevelmeupの翻訳でした。
このlevelmeupNodeSchoolのworkshopの一つです。
翻訳のOSSへの立派なコントリビュート方法の一つです。 この経験は @leichtgewicht@kamiyam が行っていたNodeSchool Osaka のイベント内で教えてもらいながら始めたのがきっかけでした。
そのあと、彼らの支援で関西Node学園というコミュニティを立ち上げることができ、東京Node学園祭やJSConf JPのカンファレンススタッフを経験することができました。
OSSへの貢献やコミュニティへの参加が人生に大きく影響しました。

同じようにコミュニティの輪を広げたりその人の助けになれれば良いと思うので、Node.jsや他のOSSへのコントリビュートについて質問などは可能な限り答えたいと思っています。Twitter - @shisama_宛やこのブログへのコメントなどで気兼ねなく質問してください。

また、jsconfjpのslackには日本のNode.jsの一線で活躍されている人がいるのでそこで質問するのもいいでしょう。私も相談していました。

t.co

OSSに貢献するということ

OSSに貢献するということで人との関わりが生まれます。

それは、インターネット上だけかもしれません。しかし、OSSに携わるということはまだ会ったことない人とのコミュニケーションが発生します。
そこからもしかすると新しい良い出会いがあるかもしれません。

また、同じようにOSSに貢献している人同士がインターネット上や勉強会などで偶然出会って繋がりあうこともあるかもしれません。

私自身、Node.jsにコントリビュートしなければ出会えなかった人もいたと感じます。
特にNodeSchool Osakaのメンバーや関西でのコミュニティで出会った人たちや、海外の偉大なエンジニア、JSConf JPのメンバーとの出会いは人生におけるかけがえのない財産だと感じています。

OSS貢献を通じて読者の方の人との繋がりが生まれたり人生が良い方向に向くことを願っています。この記事がその一助になれば幸いです。

長い記事でしたが、最後までお読みいただきありがとうございました。不備や質問はTwitter - @shisama_やコメント欄でお願いします。

2019年、2020年のJavaScript

この記事は JavaScript Advent Calendar 2019 - Qiita の初日の記事です。

2019年を締めくくるアドベントカレンダーの初日ということで、今年のJavaScriptを簡単に振り返りたいと思います。2020年のJavaScriptについても予習しましょう。
2019年、2020年が何を指しているかは後述します。
カテゴリが「プログラミング言語」なので、React、Vue、AngularやNode.jsなどJavaScriptを使った技術ではなく、JavaScriptの言語機能にフォーカスしたいと思います。

はじめに

※この章はJavaScriptの初歩的な内容になっています。JavaScript機能に関する内容だけ知りたい方は読み飛ばしていただいても大丈夫です。

JavaScriptには実行環境(JavaScriptエンジン)が複数あります。

上記のように実行環境は様々あり、開発している方々も違います。そのため、実行環境間で差異が発生することもあります。
そのため、JavaScriptにはTC39という標準化団体のような組織がありECMAScriptの仕様を作っています。JavaScriptはこのECMAScriptECMA-262に準拠しています。

このECMAScriptは毎年アップデートされ、ECMAScript 2019やECMAScript 2020など年がついたネーミングがされています。ES2019やES2020と省略して使われることが多いです。
ES2019は今年6月にpublishされました。

f:id:Shisama:20191128041317p:plain
ES2019

ECMAScriptの仕様に追加されるには5段階のステージングがあり、Stage 4になったものが仕様に追加されます。

それぞれのステージングに上がる条件など、詳しくはこちらをご確認ください。

ES2016以降のどの機能はどの実行環境で使用可能かを有志の方が一覧化してくれています。この一覧を見れば何の機能が何のバージョンの何のブラウザで使用可能か確認することができます。

kangax.github.io

今回はES2019で追加された機能やES2020に追加される機能について紹介します。

ES2019

Optional catch binding

try...catch - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 58 66 11.1 10

例外をキャッチするために書くtry-catchですが、従来では必ずcatch節に例外を識別するオブジェクトを指定しなければいけませんでしたが、必ずしも例外オブジェクトが必要ではありません。このOptional catch bindingにより指定しなくても良くなりました。

gist.github.com

JSON superset

JSON - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 62 66 Yes 10

JSONECMAScriptのサブセットにする提案です。

JSON文字列にはエスケープされていないU+2028(行区切り文字)やU+2029(段落区切り文字)を含むことができますが、JavaScriptでは文字列中にこれらを含むことができませんでした。以下はNode.js v8.16.2で確認しました。

gist.github.com

しかし、この仕様が追加されることでJavaScriptでもU+2028U+2029を含む文字列でもOKになりました。以下はNode.js v10.17.0で確認しました。

gist.github.com

Symbol.prototype.description

Symbol.prototype.description - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 63 70 12.1 11.0

Symbolの引数に指定した値を参照することができます。descriptionプロパティは読み取り専用です。

Object.fromEntries

Object.fromEntries() - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 63 73 12.1 12.0

key, valueのペアの配列をオブジェクトに変換します。

Well-formed JSON.stringify

JSON.stringify() - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 64 72 12.1 No

不正なサロゲートペアがエスケープされた文字列として出力されるようになります。

以前までは

JSON.stringify("\uD800");
// --> '"�"'

だったのが

JSON.stringify("\uD800");
// --> '"\ud800"'

になります。

String.prototype.{trimStart,trimEnd}

Array.prototype.{flat,flatMap}

Array#flat

Array.prototype.flat() - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 62 69 12 11.0

ネストされた配列をフラットにします。以下MDNから引用です。

Array#flatMap

Array.prototype.flatMap() - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 62 69 12 11.0

配列の値をmap関数でマッピングし、結果の配列をフラット化します。以下MDNから引用です。

ES2020

ES2020はまだ仕様が確定していません。しかし、いくつかの機能は既にStage 4となっているためES2020に含まれることが確定しています。この記事では2019/12/01時点でStage 4になっているES2020の機能を紹介します。

String.prototype.matchAll

String.prototype.matchAll() - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 63 73 No 12.0

String.prototype.matchAllは指定した正規表現のキャプチャに該当するものを文字列の配列として取得できる機能です。
また、matchAllの戻り値はiteratorオブジェクトです。
そのため、値の取り出しにはfor-of構文で取り出したりnext()関数を使ったりArrayに一度変換する必要があります。 JavaScriptiteratorに関して詳細はこちらを御覧ください。

gist.github.com

import()

import - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 67 63 11.1 Experimental

import()はDynamic importと呼ばれるモジュールを動的に読み込む関数です。 非同期で実行されPromiseでラップされたモジュールが返ってきます。
使い所としては処理によって読み込むモジュールを変更したり、非同期でモジュールを読み込む場面でしょう。
Node.jsでは--experimental-modulesというフラグを付けて実行する必要がありましたが13.2からはこのフラグは不要になりました。ただしまだexperimentalな機能です。

gist.github.com

BigInt

BigInt - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 68 67 No 10.4

JavaScriptのNumber型は53bitまでしか扱えません。そのため2 ** 53 = 9007199254740992が限界値です。これ以上足しても9007199254740992になります。
9007199254740992を超える数値を扱うためにBigIntが提案されました。構文は1nのように数値のあとにnを付けます。 またBigIntはBigIntとしか演算ができません。1n + 1はTypeErrorになります。
BigIntは任意精度の整数です。任意精度な浮動小数点数についてはStage 0のdecimalとして提案されようとしています。

gist.github.com

Promise.allSettled

Promise.allSettled() - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 71 76 13 12.9

Promise.allSettledは複数のPromiseな非同期の処理を並列に実行する関数です。すべて完了した状態になったときに、Promiseの結果をオブジェクトの配列を返します。
引数にはPromiseオブジェクトの配列を渡します。 戻り値はiterableなオブジェクトです。

gist.github.com

従来からPromise.allというものがありました。これも同様に複数のPromiseを並列実行します。すべての処理が成功しresolveされれば良いのですが、どれか一つでも失敗してrejectされたときにどこまで実行されたのかはわかりません。
そこで提案されたのがPromise.allSettledです。とにかくすべて完了させて、成功/失敗かは完了後に判定できるようにオブジェクトに内包して返してあげようというものです。
このためreject(失敗)したものがどのPromiseか判定でき、必要に応じてリトライなどの処理が行えます。

globalThis

globalThis - JavaScript | MDN

Edge Edge Firefox Firefox Chrome Chrome Safari Safari f:id:Shisama:20191128111950p:plain Node.js
No 65 71 12.1 12.0

globalThisは環境を超えてグローバルオブジェクトにアクセスするためのオブジェクトです。
これまでブラウザではwindow、Node.jsではglobalがグローバルオブジェクトとして使われていました。
もちろんこれらは今まで通り各環境で使えますが、どちらでもアクセス可能なオブジェクトとしてglobalThisが追加されました。
globalThisを使うことで以下のような使い分けをする必要がなくなりました。

最後に

こう見ると2019年もJavaScriptに様々な機能が追加されました。2020年も様々な機能が追加されると思います。
現在のECMA-262のmasterブランチはES2020がターゲットになっており、https://tc39.es/ecma262/ は更新されています。
もし気になる機能でES2020として追加が確定になるかはECMA-262proposalのFinishedを見ると良いかと思います。
他にも様々な機能が提案されているので、興味があればtc39/proposalsのリポジトリを御覧ください。 また、TC39は定期的にミーティングを行っており仕様の提案について話し合っています。アジェンダミーティングノートが公開されているので興味があれば御覧ください。

以上、最後までお読みいただきありがとうございました。不備や質問はTwitter - @shisama_やコメントで受け付けています。気兼ねなくメンションください。

謝辞

このブログを公開した際、不備がありましたが以下の方々が教えてくださいました。
ありがとうございました。

W3K Web Developers Meetup #1 を開催しました。 #w3kansai

特定の言語やフレームワークなどに属さない話やWebに関する勉強会を開きたいという思いがあり、W3Kという勉強会を開催することにしました。

w3k.connpass.com

当日の様子です。

togetter.com

需要があるのかわからなかったので、最初は参加枠を15名にしていたのですが有難いことにすぐ埋まりました。そのため、参加枠を35名に増枠しての開催となりました。

キャンセルなどもありましたが、参加登録してくださっていた方の8割以上が当日来場されててドタキャンが少なく良かったと思いました。

セッション

Take rendering process to pieces for Web browser performance / @plum_shiga

レンダリングに関する話をしていただきました。
Paint処理がとにかく最強に重い!will-changeプロパティを使おうと強く主張されていて、力の入ったセッションでした。

WebUSB入門 / @aruneko99

WebUSBに関する話をしていただきました。
WebUSBはセキュリティが懸念でなかなか標準化が進んでいないイメージがあり、なかなか知見も出てきていなかったのでとても勉強になりました。

firebase を使い始めて / @koneko59

firebaseに関する話をしていただきました。

大規模データのパフォーマンス改善 / @ef_ryusx

パフォーマンス改善について話をしていただきました。
PostgreSQLのパフォーマンスを改善したことで最大約90%パフォーマンス改善したのはすごいのでぜひPostgreSQLをお使いの方はぜひ資料を御覧ください。

ビデオの字幕ってどうなってんの? / @Daikids2

web videoの字幕・キャプションを行うWebVTTについて話をしていただきました。
<track>タグやWebVTTといった馴染みのない技術を紹介されてて、見るもの聴くものが新しく勉強になりました。

Portalsを試してみた話 / @granciel_33

Portalsに関する話をしていただきました。
Google I/O '19やChrome Dev Summit '19などでも大きく紹介されていて注目度が高い技術で、まだ新しい技術なので事例や知見がまだ少なかったので大変勉強になりました。また、Portalsについてはもう少し使われ始めたら別途テーマとして勉強会を開きたいなと考えています。

最後に

初回ということで参加者が何を期待しているか、期待されていることとイベントの趣旨に大きな乖離がないか心配でしたが、概ね満足していただけたようで良かったです!これからも定期的に開催していきたいと思います。

最後までお読み頂きありがとうございました。今後ともW3Kを宜しくお願いします。

【資料公開】FRONTEND CONFERENCE 2019でXSSやセキュリティについて話します #frontkansai

2019-11-02 グランフロント大阪で行われるフロントエンドカンファレンス2019に『フロントエンドエンジニアのためのセキュリティ対策~XSS編~』というタイトルで発表します。
資料は公開しています。100ページ超えているので読むのが大変だと思います。(作るのも大変だったが・・・)
当日までに変更はあるかもしれませんが、大きくは変わらないと思います。マサカリ待ってます。

speakerdeck.com

スタッフとしても携わっているので当日はスタッフ兼登壇者ということであまり懇親会などには顔を出せないかも知れませんが、もし見かけたら気兼ねなく話しかけてください!質問やマサカリも待っています!!
発表をぜひ聞きに来てください!

2019.kfug.jp

そもそもこの話をするきっかけになったのは、Webは脆弱性と常に隣り合わせだなと日々感じることが多く、Webに関係するセキュリティ関係を調べていたところCSPやTrusted Typesなどブラウザのセキュリティ対策の機能に興味を持ち調べたためです。
CSP Lv.3はW3CのWorking Draftが出ていてTrusted TypesはChromeshipされようとしています

もし、お読み頂いている方でWebのセキュリティに興味がある方は仲良くなってください!色々教えてほしいです!

では当日お会いしましょう!お読みいただきありがとうございました。

関西Node学園 8時限目を開催しました。 #kng8

nodejs.connpass.com

サイボウズ(株)大阪オフィスにて開催しました。 Node.js v12がLTSになり、v13がリリースされたタイミングに合わせて開催しました。

当日の様子です。

togetter.com

登壇内容

Node.js v12のES Modules / @shimataro999

t.co

Node.js v12でES Modulesを使う方法や、CommonJSとES Modulesでの相互運用の話、importするファイルの拡張子の補完などについて話をしていただきました。

Node.jsではES Modulesを実験的にサポートしています。従来Node.jsはCommonJSというモジュールシステムを採用してきましたが、ここ数年Node.jsはWebの仕様に合わせていこうとしています。従来のCommonJSでのモジュール解決を破壊してしまうとnpmパッケージの多くが使えなくなる可能性があります。そのためNode.jsとしてもなかなかES ModulesをNode.jsでサポートするのに時間がかかっています。

資料中にも出てきましたが、以下の記事がNode.jsのES Modulesについて詳しく書かれています。

medium.com

Node.js v13の気になる変更点 / @shisama_

speakerdeck.com

10/22にリリースされたNode.js v13について話をしました。
内容は以下のブログに書いた内容と重複するので割愛します。

shisama.hatenablog.com

AmazonAPIGatewayのLambdaAuthorizerでJWTを検証するLambdaをServerlessFrameworkでデプロイする / @is_ryo

docs.google.com

API Gateway Authorizersで使えるLambda AuthorizerでのJWT(JSON Web Token)の検証を行う話をしていただきました。
JWKやjsonwebtokenを使ったJWTの検証、ServerlessFrameworkを使ったLambdaにAuthorizerをデプロイする方法について紹介してくれました。

serverless.com

私個人としてはこの辺はかなり弱いので、「そんなものがあるのか」と初めて知ることばかりでした。

今回紹介していただいた内容を踏まえたサンプルも用意していてもらっています。

github.com

Cloud Storage for Firebaseとセキュリティルール / @mochiya98

docs.google.com

FirebaseのCloud Storageにファイルを保存するときにメタデータに紐付かないファイルはアップロードを制限する方法について話をしていただきました。
Cloud Storageにはメタデータを付与してアップロードすることができます。しかし、クライアントが任意にメタデータを付与できてしまいます。任意ではなく、決まったメタデータ(例えば有効期限やパスワード)を必ず付与したい場合直接のファイルアップロードを禁止にします。ファイルのメタデータはFirestoreに保存しておき、アップロードはCloud FunctionsでAdminSDKから書き込みを行うことでファイルとメタデータの紐付けを担保するという方法を紹介していただきました。

Trying State Manegemant without Redux(updated) / @nkgrnkgr

speakerdeck.com

Reduxを使わずにReact HooksとContextで状態管理を行う話をしていただきました。
Reduxはコードが冗長になり、教育コストが高めということでReduxを使わずにReactだけでやってみようとしたとのことです。 ContextとuseStateを使うことでグローバルな状態管理を行うことができます。Contextを使いたいときはuseContextでContextを取り出すことができます。
また、useReducerを使うことでReduxと同じようにactionが発行するtypeによって処理を分岐させるreducer関数を書くことはできます。しかし、この場合はReduxの冗長さは解決できません。
また、Reduxはredux-thunkやredux-sagaなどのミドルウェアが便利なので使っているという方は多いのではないでしょうか。しかし、Reduxを使わないことでJSのファイルのサイズを抑えることができたり、冗長さを回避するように書くことができるメリットはあります。

asyncQuerySelector / @salamander_jp

docs.google.com

MutationObserverを使ったライブラリでターゲットのDOMが標示されるまで待つことができます。

デモページを用意してもらっています。

https://codepen.io/04/pen/ZEEKVyz?editors=1010

また、同様のことが可能なライブラリがあります。asyncQuerySelectorはこのライブラリを参考に作ったとのことです。

github.com

最後に

今回はNode.jsの発表もあり、LambdaやCloud Functions、フロントエンドの話など多彩な内容だったのが良かったと思います。
私も知らないことが多かったので勉強になりました。

今回、参加者(登壇者含む)が35名だったのに対してキャンセルが30名も発生してしまいました。プレミアムフライデーということもあってタイミングが良くなかったのかも知れません。
また、当日キャンセルせずに来られなかった方が6名ほどいました。

他の勉強会の主催者からも金曜日は避けた方がいいというアドバイスをいただいているのもあり、当日参加していただいた方々に何曜日が都合悪いかアンケートを取ってみました。 その結果、火曜と水曜がほぼ手が上がらなかったので、火曜と水曜に開催してみようかなと思いました。

関西Node学園では開場提供をしていただける方やJavaScriptやNode.jsに関わる発表をしていただける方を通年募集しています。
もし、興味がございましたらTwitterやshisama07@gmail.com宛にメールをしていただけると幸いです。

最後までお読みいただきありがとうございました。

【資料公開】関西Node学園でNode.js v13について話します

nodejs.connpass.com

10/25に行う関西Node学園 8時限目でNode.js v13の変更点について話します。
昨日のブログで紹介した内容を発表します。

shisama.hatenablog.com

資料は公開済です。質問や不備がありましたらお手数おかけしますが、Twitterブコメ等で教えていただけると助かります。

speakerdeck.com

Node.js v13の主な変更点

Node.jsのv12がLTSになり、v13がcurrentとしてリリースされました。 ダウンロードは公式ページから行えます。

nodejs.org

今回はNode.js v13の主な変更点を紹介したいと思います。
以下リリースノートにあるNotable Changesからいくつかピックアップします。

nodejs.org

assert (PR: #28263)

assert.throws()またはassert.reject()でthrowされたエラーの検証にコンストラクターが使われた場合、throwされたエラーの代わりにAssertionErrorがスローされます。

コードで見た方がいいかもしれません。

gist.github.com

build (PR: #29887)

full-icuでビルドされるようになり、i18n系の機能ですべての言語をサポートしました。

Node.jsはこれまでビルド後のバイナリサイズの増加への懸念により、--with-intl=small-icuオプションを付けてビルドしていたバイナリを配布していました。
しかし、v13からは--with-intl=full-icuでビルドしたバイナリを配布するようになりました。
懸念されていたバイナリのサイズですが、macOSだと35MBから49MBになります。

オプションによる言語サポートの違いは以下の表のとおりです。こちらからも確認できます。

https://nodejs.org/api/intl.html#intl_options_for_building_node_js

挙動の違いに関するサンプルコードは以下のとおりです。

gist.github.com

v12以下(small-icuでビルドされたバージョン)はM01と出力しますが、v13以降(full-icuでビルドされたバージョン)はeneroと出力します。

console (PR: #29251)

console.timeEnd()console.timeLog()の結果がミリ秒ではなく時分秒の単位で出力するようになりました。

単位はh(時)、min(分)、s(秒)があります。

サンプルコードは以下の通りです。

gist.github.com

v12では3001.732msと出力されていましたが、v13からは3.001sと出力されます。

deps (PR: #29694)

JavaScriptエンジンのV8のバージョンが7.8になりました。

これによりObjectの分割代入のパフォーマンス、メモリ使用量、WASMの起動時間が改善されます。
詳しくはV8のブログを読んでください。

v8.dev

http (PR: #29589)

古いHTTPパーサーが削除されました。

v12からすでにデフォルトではllhttpが使われています。

github.com

しかし、--http-parser=legacyとオプションをつけてnodeを起動すると古いパーサーを使うことも可能でした。
v13からはEnd-of-Lifeとなりました。オプション自体が削除されました。

llhttpはTypeScriptで書かれたhttpパーサーです。

github.com

古いHTTPパーサーは保守が難しく、またアーキテクチャ上パフォーマンスに問題がありました。
llhttpは保守性向上のためにTypeScriptで書かれています。それをCのコードやビットコードに変換しています。
古いHTTPパーサーに比べてパフォーマンスはかなり向上しています。

Image from Gyazo

http, http2 (PR: #27558)

デフォルトのサーバータイムアウト時間が変わりました。

これまでサーバーのタイムアウトの時間はデフォルト2分でした
リクエストが完了するまでに2分以上かかる場合、ソケットは閉じられ空のレスポンスを返していました。
そのため、画像の変換やサイズが大きいファイルのアップロードなど処理に時間がかかる場合、処理の途中でリクエストが閉じられることがありました。
これまでも--http-server-default-timeout=millisecondsオプションを使うことでユーザー側でもこの時間を変更することは可能でした。0に設定することでサーバータイムアウトを無効にすることもできました。

v13からはデフォルトで0が設定されるようになりました。つまりサーバータイムアウトが無効になりました。

ES Modules (PR: #29866)

まだWIPでリリースされていませんが、ES Modulesもv13からフラグなしで使える予定になっています。
Node.js v12にもマイナーバージョンの更新(12月か3月ごろ?)でバックポートする議論もされています。

New Release Plan · Issue #400 · nodejs/modules · GitHub

最後に

今回紹介したのは一部の機能になります。自分が気になった変更をまとめただけですので、他にもすごい変更点はあるかもしれません。

Node.js v13は2020年6月でEnd-of-Lifeになる予定です。
次のNode.js v14は例年通りだと2020年4月にリリースされ10月末にLTSになる予定です。今回紹介したv13の機能も含まれます。

https://raw.githubusercontent.com/nodejs/Release/master/schedule.svg?sanitize=true

最後までお読みいただきありがとうございました。質問や不備はTwitterブコメなどでお願いいたします。