はてなブックマーク

ESLint コアルールの TypeScript 対応について ESLint v9.23.0 で ESLint のコアルールの TypeScript 対応が開始しました。 その後の ESLint のアップデートでもコアルールの TS 対応が進んでいます。ESLint コアの責務を増やすような機能追加は少し意外だと感じたので、その背景について調べてみました。 背景: 従来のコアルールの拡張方法の課題 ESLint のコアルールは JavaScript を想定して書かれたものであるが、TypeScript に対してもほぼ期待通り動作するルールが多い。TypeScript は JS のほぼ上位互換な言語であるため、TypeScript 用のパーサー (@typescript-eslint/parser) が吐き出す AST もほぼ上位互換であり、パーサーさえ TS 用のものを使えば多くの ESL

年明けはまず環境整備から、ということで今年は mise を導入することにした。 去年まで rtx とか rtx-cli という名前でやってた Rust 実装の asdf 代替の多用途バージョン管理ツール。この年明けに急に mise にリネームしたよ、というニュースが流れてきて、気になって見てみたら良さそうだった。 一般的な解説は "rtx" でググると日本語記事も出てくるのでそっちを見て欲しいけど、個人的な asdf に対するメリットはこのあたり。 とにかく速い asdf は Node の最新バージョンの反映が node-build 依存で、更新が数日遅れることがあった 結果的に手動で定義ファイルを更新していたが、処理速度も遅く面倒だった 参考: asdf で node-build の定義ファイルを手動更新する asdf はコマンド体系が謎だった(自分には) 例えば v20 系の最新をイン

この記事は Cybozu Frontend Advent Calendar 2023 の 24 日目の記事です。 先日リリースされた ESLint v8.56.0 でオプション reportUnusedDisableDirectives が改善された話です。 元々どういうオプションだった? // eslint-disable-line みたいなルール無効化ディレクティブを書いたけど、しばらくして何かしらのコード修正の影響でもうそのルール違反は発生しなくなって、でも無効化ディレクティブは消し忘れて無駄に残っている、みたいな状態は起こりがちです。 例えば以下のように non null assertion (!) が一時的に必要になって disable したけど、

asdf で Node.js を扱う場合、内部的には node-build によってインストール可能なバージョンとアーカイブの URL の定義ファイルが管理されている。 この定義ファイルが数日更新されないこともあり[1]、そういう場合に手動でローカルの定義ファイルを更新して新バージョンをインストールする方法を毎回忘れるのでメモに残しておく。 手順だけ書くとこれ。 DIR=/tmp/node-defs mkdir -p $DIR npx -p @nodenv/node-build-update-defs nodenv-update-version-defs -f -d $DIR NODE_BUILD_DEFINITIONS=$DIR asdf install nodejs 21.0.0 node-build-update-defs は node-build が定義ファイルを生成しているツール

ESLintの新しいFlat Configは、デフォルトではファイル名と拡張子が固定でeslint.config.jsしか使えない。eslint.config.mjsが使えない。 つまり、プロジェクトのpackage.jsonのtypeに依存して、中身がCommonJSかESMなのかが変わってしまう。 これは実際けっこう面倒になりそうで、自分で使う設定ファイルは共通で使い回すことになると思うけど、プロジェクトによってrequire()を使うCJS用とimportを使うESM用で書き分けないといけなくなる。 一応コマンドライン引数を使えば任意のファイル名を設定ファイルとして渡すことはできるけど、その場合は環境変数でFlat Configを有効化する必要もあるので、都度手で打つのは厳しい長々としたコマンドになってしまう。 ESLintチームは、これに関してかなり固い決意を持っているようなので覆

この拡張には現在 (2023年07月30日 9.19.0 時点) はまだPrettier v2が同梱されている。同梱をv3に変更するPRはまだマージされていない(と書いてたらさっきマージされた)。 ただ、この拡張は対象ワークスペースのプロジェクトのローカルにprettierがインストールされていればそっちを使ってくれるので、この拡張の変更のリリースを待たずとも、単にプロジェクトでprettierをアップデートすればVS Codeでもv3が使われて期待通り動くはず。 が、結果は予想に反して、v3で動いているはずなのにtrailingCommaがallではなく、v2相当のes5で動いてしまってた。あれ? 原因は、この拡張は拡張側でPrettierのデフォルト設定を独自に持ってしまっていて、プロジェクトに設定ファイルprettierrcが無い場合は拡張側のデフォルト設定が使われるから。Pretti

// A: そのまま残る import { Foo } from "./foo"; // B: 識別子 `Foo` が削除される import {} from "./foo"; // C: import 文ごと完全に削除される どれになるかは、以下の状態の組み合わせ依存する(他にも条件あるかも)。 そのファイルでFooが値として参照されるか、型として参照されるか、参照されないか Fooがfoo.tsで値として定義されているか、型として定義されているか tsconfig のオプション設定 importsNotUsedAsValues: 値として参照されない import 文を残すかどうか preserveValueImports: 参照されない import 識別子が値なら残す isolatedModules: ファイル単位でトランスパイルする 上記は出力するモジュール形式が ESM の場合

2022 年現在、Node.js 界隈は ESM (ES Module) への移行の過渡期であり、特に既存プロジェクトにおいては CJS (CommonJS) 構成であることがまだまだ多い。また、Pure ESM な npm パッケージは、CSJ プロジェクトからの利便性が悪く、dynamic import が必須で非同期化を強いられたり TypeScript の設定変更が必要だったりと面倒が増える。 そんな状況のため、広く使われたい npm パッケージを公開する場合、importでもrequireでも利用できるよう dual package 構成を取りたくなるが、定番手法が確立しているとは言えず、意外と面倒が多い。よく見るのは、tscやesbuild等で ESM 用と CJS 用の設定ファイルを用意してそれぞれ別ディレクトリに出力し、パッケージに両方同梱して conditional ex

最近になって M1 Mac 入手したので環境構築の tips をメモ。 Node.js v16 以上では M1 Mac 向け arm64 バイナリが公式に提供されているが、v15 以下では提供されていない。 M1 Mac で nodenv を使って Node.js をインストールする場合、v16 ではもちろん arm64 バイナリをダウンロードするが、v14 では x86_64 バイナリをダウンロードして Rosetta で動かすのではなく、ソースをダウンロードしてローカルでコンパイルが始まってしまう。 この挙動は厳密に arm64 バイナリが欲しい人には嬉しいかもしれないが、ちょっとした動作確認をしたいだけなのに数分かけてビルドされても困る。 そういう場合、arch コマンドを使うことで nodenv で x86_64 バイナリをインストールできた。

本記事で記述した Node.js ESM 対応は2022 年 5 月に TypeScript 4.7 で正式版としてリリースされました。 本記事の内容との差分はmodule:node12がmodule:node16に変更されたことぐらいです。node16では top-level await が使え、現時点ではnodenextとの差分はありません。 他に関連する機能としてresolution-modeや--moduleDetectionが追加されましたが、一般利用者が意識することはないでしょう。 先日リリースされた TypeScript 4.5 Beta で、待望の Node.js ESM 対応がアナウンスされました。 その後、ユーザーからのフィードバックを経て、TypeScript チームは TS 4.5(11/16 リリース予定)では ESM 対応を stable リリースせず、Nigh

追記: 2023年11月19日 corepack v0.20.0 にて、CLI のコマンド体系が一新されて多少わかりやすくなりました (PR#291)。新しいコマンドは README を参照。 追記: 2022年02月03日 Node.js v14.19.0 に corepack が標準バンドルされました。 corepack がバンドルされていない Node.js v12 系は 2022年04月30日 に EOL を迎えるので、あと 3 ヶ月もすればアクティブな Node.js 環境には必ず corepack が揃っているという状態になりますね。引き続き experimental ステータスのままではありますが。 追記: 2021年09月08日 Node.js v16.9.0 で corepack が標準バンドルされました。まだ experimental 扱いですが。 デフォルトでは yarn も

eslint-plugin-prettier 時代の設定をずっと使っていたので、重い腰を上げてアップデートした作業メモ。 背景 Prettier 公式ドキュメントによれば、現在 eslint-plugin-prettier は以下の問題があるとして推奨していない。 エディタが真っ赤になる(人間が気にする必要のない問題なのに!) 直接実行するより遅い(同様に prettier-eslint も遅い) ESLint と Prettier の間に間接レイヤーを追加するので、壊れやすい なるほど正しい。 一方、別々に実行することで以下のような問題も出てくるので、解決していく。 CLI とエディタを個別に設定する必要がある エディタで ESLint と Prettier の協調動作が必要 CLI (npm scripts) で ESLint と Prettier の対象ファイルが別管理になる 上記の