JSConf.jp 2023

tasshi

https://jsconf.jp/2023/

セッションURL

Twitter

#jsconfjp: https://twitter.com/hashtag/jsconfjp
#jsconfjp_a: https://twitter.com/hashtag/jsconfjp_a
#jsconfjp_b: https://twitter.com/hashtag/jsconfjp_b
#jsconfjp_c: https://twitter.com/hashtag/jsconfjp_c
#jsconfjp_d: https://twitter.com/hashtag/jsconfjp_d

スライド・リンクまとめ

とても助かる

tasshi

THERE AND BACK AGAIN: A PROPOSAL'S TALE

ESの仕様策定とか内部実装とかの話

tasshi

DEEP DIVE INTO BIOME

Biomeコアコミッター、@nissy_devさんのセッション

Governaceが作られてるの良さそう
Batteries Includedってどういうニュアンス？
速い、ゼロコンフィグ、TS/JSX標準サポートはこれから作られるツールはもうそれが当たり前みたいになってきそう
Error residence (エラーが発生してもパーサが中断しない)
- Green Red tree (lossless syntax tree)
- Rowanというrust-analyzerで使われている構文木ライブラリがある
Custom ruleとかはサポートする？
- 元のフィロソフィーではやらないけど、メンテナも増えて価値観の変化もある
- 基本的にはWASMベースになる
https://github.com/oxc-project/oxc について

tasshi

BUILD AND PUBLISH IN 2023
https://jsconf.jp/2023/talk/mizchi-1/

バンドラなどの話
Closure Complier
Browserify
Webpack
Rollup
Vite
Turborepo
Isomorphicは今はもう言わない

常に崩壊するZero-Config
本質的には前世代のベストプラクティス集
本当にZero-Configだけではトレンドからは一歩遅れる

tasshi

TYPESCRIPTで型定義を信頼しすぎず「信頼境界線」を設置した話

Type Safe
fetchの返り値Promise<T>が信用できるか
クライアントとバックエンドで互換性がなくなる場合がある
検証をしないと（いつか）バグが発生する
バグの発生箇所と根本原因の場所がズレる
全てを検証する場合、あらゆる場所でチェックロジックが入る=>分かりにくい&変更しにくい
値を過信しすぎてもダメ、値の検証をしすぎてもダメ
値を信頼する境界線が必要
小規模アプリ: ユーザが自ら復旧できるアプリケーション（CLIや開発者ツールなど）
- 検証→ExceptionでOK
大規模アプリ: ユーザが自ら復旧できないアプリケーション
- zod, ajv, yup, joiなどなど
- スキーマ駆動開発
型と値の信頼度の両方を高める
- 値が信頼できない場所：正常系・異常系のテスト項目を設ける
- 値が信頼できる場所：正常系を中心にテストする
- エラーの発生場所とその理由の距離を常に観測し続けること

tasshi

書いたJAVASCRIPTがそのままブラウザで動く未来へ

JavaScriptを直接書かない
TS, JSXなどで記述してJSに変換してブラウザで実行する
JSに何があれば開発でJSを使えるのか
JSのビルドステップ
- 1. TS→JS
- 1. JSX→JS
- 1. ダウンレベルコンパイル (ES→ES)
- 1. モジュールのバンドル (a.js b.js -> bundle.js)
- 1. ミニファイ
これらがなくなれば直接JSが書ける
- For 1: Type Annotations proposal (Stage 1)
  - https://github.com/tc39/proposal-type-annotations
- For 2: 今の所Proposalはない（議論はある）
- For 3: IE終わってほとんどの人がエバーグリーンブラウザを使用→ダウンレベルコンパイルなしでいけるのでは
  - eslint-plugin-es-x などで特定のESの機能を制限できる
- For 4: ダウンレベルコンパイルの観点では不要かも（大体のブラウザではESMが実行できる）
  - importのたびにfetchが発生するパフォーマンスオーバーヘッド
- For 5: Binary AST proposal (Stage 1)
  - https://github.com/tc39/proposal-binary-ast

=> 現時点ではビルドステップを取り除くのは無理

@sosukesuzuki の私見

そもそも書いた生JSをブラウザで動かす必要はなくなってきている
OpenCollectiveなどを通してビルドツールチェーンはサステナブルになってきている
とはいえ、勿体無い

tasshi

INTLの今までとこれから

Intl
ECMA262(いわゆるES)
IntlはECMA402(拡張仕様)
Intl.NumberFormat
Intl.DateTimeFormat
Editionを経るごとに機能が増えてる
Segmentor以外は大体ブラウザ側もサポートしてる
Intlは他標準仕様を参照する部分が多い
Unicode, IETF, IANA, ISOなど
Temporalはどうなる？→Temporal側でIntl準拠が進んでいる

tasshi

バッテリーインクル－デッド (battery included) とは

転じて、ソフトウェアやプログラミング言語、フレームワークのうち、インストールすればすぐに使えるものを指して「バッテリーインクル－デッドだ」と言ったりする。

tasshi

同僚と話した利用不可能な組み込みモジュールやDOMへのアクセスの検知方法

基本的にはno-undef系のエラーはTypeScriptに任せたい。
typescript-eslintの方針としてもそう。

Node.js向けビルドについてはlib: domを外すだけ

ブラウザ向けビルドはexcludeTypesがないので厳しい。
typesを使うとパッケージになっていないd.tsファイルの自動読み込みができなくなる。
(typesがパッケージ名しか受け付けないため)

ESLintプラグインやらESLint ruleを使う or 書く？

バンドルを走らせても検出はできる。

tasshi

falcyを禁止したい。

ESLintのルールがある (strict-boolean-expressions)

https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/strict-boolean-expressions.md

ただし、内部でtscにアクセスする関係上非常に重くなる。
型解決が必要なものは全てtscに律速される問題。

tsc互換ツールとかの開発はどう？
stcが開発されているが追いついてなさそう。

https://github.com/dudykr/stc

tasshi

mizchiさんのスライドについて、後から質問
（端折ってるので間違ってたらごめんなさい）

Q. Isomorphicって最近は言わないというのをもう少し詳しく（Universalに変わった？）
A. Isomorphic → Universal ときて、今はそれが普通になったというかわざわざ言わなくなった

Q. 自分のライブラリはNode.jsの依存とブラウザの依存をDIしてどちらでも使えるようにしている。
A. それはIsomorphicだと思う。（おそらくUniversalはWeb標準のAPIを使って書かれている）
ただ、やはりそれをライブラリのユーザに明示することによるユーザへの恩恵は薄くなっていると思う。