はてなブックマーク

Windows の Node.js で存在しないファイルを fs.readFileSync で読み取ろうとすると ENOENT が返ってくる。けど ENOENT は POSIX で定義されてるエラーコードであって、Windows のものではない。どこかで正規化されてるのか? という疑問が出てきたので調べてみた。 答え Node.js の公式ドキュメントの error.errno の説明に答えが書いてあった。 https://nodejs.org/api/errors.html#errorerrno On Windows the error number provided by the system will be normalized by libuv. どうも libuv でエラーコードの正規化がされてるらしい。確かに libuv のコードを見ると、int uv_translate_sy

tsx は TypeScript コードを事前トランスパイルすることなく、直接 Node.js で実行するためのツール。 https://github.com/privatenumber/tsx ところで最近の Node.js には Type Stripping という機能が入った。これを使うと、tsx なしで TypeScript コードを事前トランスパイルせずに実行できる。 https://nodejs.org/api/typescript.html#type-stripping 両者の違い 一見すると両者は機能的に同じものかのように思うけど、実は結構違いがある。 import specifier の指定方法が異なる 最も大きな違いは、「import specifier」の指定方法。import specifier というのは、以下の部分のこと。 import { add } './m

CSS Modules は、CSS をローカルスコープ化する仕組み。*.module.css に CSS を記述すると、bundler がクラスセレクターなどをユニークなものへと変換してくれる。クラスセレクターなどが *.module.css ファイルごとに異なる名前に変換され、擬似的にローカルスコープ化が実現される。 developer.hatenastaff.com CSS Modules では、基本的には CSS の標準の構文をそのまま利用する。しかし、一部 CSS Modules 独自の構文がある。実際どのようなものがあるのかというのを、紹介する。 CSS Modules の公式ドキュメント (仕様) のリンクを貼りつつ紹介するが、公式ドキュメントの仕様は非常に緩く書かれているので注意すること。真の仕様を把握するには、postcss-modules などの実装も必ず見るように。 :

色々セッションを聴いてきたので、その感想です。沢山ありすぎたので、聴いてて気になったものだけ感想書いてます。 The New Powerful ESLint Config with Type Safety https://talks.antfu.me/2025/tskaigi/1 ESLint の Flat Config についてのセッション。新 config への移行を補助するツール (@eslint/migrate-config, Config Inspector) が色々紹介されていた。存在そのものは知っていたけど、実際どういうことができるのかとか、動いている様子とかは見たことがなかったので、そういうのがセッションで見れて良かった。 @eslint/migrate-config はまあ良さそうだけど、Config Inspector はそんなに必要な状況あるかなあとは思った。そもそも

「TypeScript Language Service Plugin で CSS Modules の開発体験を改善する」というタイトルで発表しました。 speakerdeck.com CSS Modules には、Find All References などの言語機能が動かないといった問題があります。本発表では、その問題を解決するためのツールキット「CSS Modules Kit」を紹介しました。 github.com CSS Modules Kit は、Find All References といった主要なな言語機能をサポートしています。更に、VS Code 以外の様々なエディタで動くという特徴があります。その裏側では TypeScript Language Service Plugin と Volar.js を駆使した、非常に巧妙な実装がなされています。 CSS Modules を使

tsconfig.json を使うと、型チェックを緩く/強くしたり、また出力する JS の形式を変えたりできる。しかしいくつかの事情から、正しく書くのが難しい。 オプションの数が非常に多い その数なんと 133 個 *1 オプションの意味や役割が理解しにくい 公式ドキュメントは丁寧にかかれているが... JavaScript や TypeScript の仕様、型の知識、歴史的経緯などを知らないと理解しづらい 推奨されるオプションが変わっていく 言語やエコシステムの進化/変化によって変わる 最近だと Node.js の TypeScript サポートで変わった 「オプションの細かい意味とかは一旦いいから、モダンで最小限の tsconfig.json がすぐに欲しい！！！」。そうした声に応えて、id:mizdra がオススメする「4 ステップでモダンな tsconfig.json を作る方法」

ターミナル向けに色付きの文字を format する関数を実装してて、そのテストを Vitest で書こうとしていた。 // src/format.ts function red(text: string): string { // ... } export function formatError(message: string): string { if (process.stderr.hasColors()) { return red('error: ') + message; } else { return 'error: ' + message; } } // src/format.test.ts import { expect, test } from 'vitest'; import util from 'node:util'; import { formatError } f

その名も CSS Modules Kit です。去年の11月からずっと作ってました。 github.com www.youtube.com 何故作ったか 実は以前にも happy-css-modules という CSS Modules のための補助ツールを作っていました。これを使うと、.module.css から import したオブジェクト (styles) に TypeScript の型が付き、かつコードジャンプできます。 www.mizdra.net 便利ではあったのですが、不満がなかったわけではありません。 .module.css.d.ts.map が .module.css の横に生成されてしまう ファイルツリーの見通しが悪くなる VS Code であれば files.exclude でファイルツリーから隠せるが...他のエディタではそうはいかないケースも Button.mod

これは はてなエンジニア - Qiita Advent Calendar 2024 - Qiita 15日目の記事です。昨日は id:utgwkk さんの「ISUCONの感想戦を支えるEC2の自動開始・停止、そしてAWS Step Functions」でした。 はてなでフロントエンドエキスパートをしている id:mizdra です。この記事では、JavaScript で GraphQL サーバーの技術選定をする際に、どのようなツールやライブラリがあるのかを紹介します。 というのも、JavaScript で GraphQL サーバーを作ろうと思って検索してみると、「Next.js + Apollo Server + graphql-codegen で GraphQL サーバーを作ろう！」だとか、そういう記事が多数出てきます。ただ、複数のライブラリやツールを組み合わせると作れることは分かるので

社内で「node --test って実際どうなの?」という議論がありました。その参考に、id:mizdra が node --test 最近を触って思ったことや、感想などを書いてみます。 結論だけ先に書いておくと、node --test はミニマムなテスティングフレームワークです。テストする時に必要とされる機能は大体ありますが、Vitest と比較すると色々欠けてます。そして、Vitest と比べて何が足りないのか、実際に触ってみるまで意外と分からないです。とりあえず動けば OK という人は、Vitest 使ったら良いと思います。node --test はミニマリスト向けです。 node --test とは まず node --test って何という人のために書いておくと、Node.js 組み込みのテストランナーのことです。Node.js v16.17.0, v18.0.0 から導入されて

今まで id:mizdra はターミナルで Git ブランチを切り替えるときに、zsh + peco を使った Git ブランチ検索用のキーバインドを使用していた。 # .zshrc function select-git-branch() { selected_branch=$(git branch | cut -c 3- | peco) BUFFER="${LBUFFER}${selected_branch}${RBUFFER}" CURSOR=$#LBUFFER+$#selected_branch zle redisplay } zle -N select-git-branch bindkey '^b' select-git-branch zsh + peco で Git ブランチを切り替える様子 便利っちゃ便利なのだけど...沢山のブランチの中から「あの時作業していたあのブランチ」

特定の時間になったらコンテンツをページに出したい、ということがあると思う。漫画サービスなら「ゴールデンウィーク限定！全話無料キャンペーン！」みたいなのとか。 普段の業務ではこうしたことを実現するために、時限式コンポーネントや、ScheduledComponent などと呼ばれるものを作ってる *1。 // components/ScheduledComponent.tsx export function ScheduledComponent({showAt, children}: { showAt: Date; children: React.ReactNode; }) { if (new Date() < showAt) { return null; } else { return children; } } これを Next.js Pages Router などから、以下のようにして使

TL;DR "include": ["src/index.ts"] はやめよう src 配下にあるのに型チェックされない & auto-import できないファイルが生まれてしまう "include": ["src/**/*"] や "include": ["**/*"] がオススメ どっちが良いかはプロジェクトによる "include": ["src/**/*"] は "include": ["src"] と、"include": ["**/*"] は include 指定無しと同じなので、それでも OK すっごい凝りたいなら Solution Style tsconfig.json を使おう はじめに tsconfig.json の include オプションは、プロジェクトを構成するファイルを指定するオプションです。 https://www.typescriptlang.org/j

最近用語集のようなページを作る機会があった。それぞれの用語の名前と説明がバーっと並んでて、説明部分は <details> 要素で隠されている。用語の名前をクリックすると <details> が展開されて、説明部分が読める、といった感じ。 用語集ページの例 他のページから特定の用語の説明に飛べるように、用語を表す要素それぞれに id 属性が振ってある。例えば https://glossary.example.com/#javascript という URL でアクセスすると、「JavaScript」の用語がある位置にスクロールした状態で、用語集ページを開ける。 ただ (一部ブラウザで) https://glossary.example.com/#javascript でアクセスしても、JavaScript の説明の欄が閉じたままで困っていた。その用語の説明が見たいがためにしてきているので、最初

Node.js には --require=module と --import=module というオプションがあります。このオプションを使うと、エントリポイントとなるプログラムよりも前に、任意のモジュールを実行できます。 例えば以下のようなコマンドを実行すると、Node.js ランタイムはまず最初に preload.cjs を実行し、それから main.mjs を実行できます。 node --require ./preload.cjs main.mjs エントリポイントよりも前に、何かしらの処理を実行したい時に使うことを想定しています。 --require と --import の違い --import も --require と同じように、モジュールをプリロードするためのオプションです。両者の違いはプリロードするモジュールの読み込み方です。 --require は require(...

tsc の代替実装を作る話、とりわけ Rust や Go で tsc を高速化した移植版を作る話について。非常に野心的で面白いと思いつつ、正直僕は実用レベルまで達したものが本当に登場するのか疑問に思っている。今ある型システムもそうだし、新機能として追加されるものにも追従する必要がある。当然、実用レベルとして使ってもらうには、不具合も少なくないといけない。 それに tsc も最近はパフォーマンス改善に力を入れているように見えている。実際にリリースノートを見ると、ちょくちょくパフォーマンス改善系の変更が入っている。 TypeScript: Documentation - TypeScript 4.8 TypeScript: Documentation - TypeScript 4.9 TypeScript: Documentation - TypeScript 5.0 TypeScript:

React + CSS Modules なプロジェクトを例にサンプルコードを書いてるけど、それ以外の構成のプロジェクトでも使えるテクニックのはず。記事タイトルは id:hitode909 さんの 似ているけどちょっと違うものたちをモデリングする技術 - hitode909 のリスペクトです。 data 属性, 属性セレクター, CSS カスタムプロパティを使う 記事のリストがあって、記事のカテゴリごとに文字色やボーダーの色を変えたい、みたいな状況だったとする。多分素朴に書くと以下のようになるはず。 import styles from './Entry.module.css'; import clsx from 'clsx' function Entry(props) { return ( <div className={ clsx(props.category === '暮らし' ? s

TL;DR あるリソースの fetch 中にページ遷移すると、一部ブラウザでは fetch が中断される 中断されると、TypeError が throw される ページ遷移時は、ブラウザによって遷移前のページの実行が"停止"され、"捨てられる"ので、通常 throw された後のことは考えなくて良い しかし、そのページが Back/Forward Cache から復元されうるなら、話は別 ブラウザバックすると、エラーが throw された後からページが再開される！！！ そして発生する、奇妙な現象の数々... はじまりは、あるサービスの不具合報告 ある日、「Webサービスから外部サービスにページ遷移した後、ブラウザバックで戻ると、エラー画面が表示される」という不具合が報告された。どうも Webサービスの ErrorBoundary で何かしらのエラーが catch され、それによってエラー画

これは、はてなエンジニアアドベントカレンダー2023 4日目の記事です。 3日目は id:mechairoi さんの「SQLiteでLinderaを使った日本語全文検索」でした。 blog.chairoi.me 今日のテーマは、JavaScript 向けの Linter 「ESLint」についてです。ESLint を使うと、JavaScript で書かれたコードを静的解析して、よくある間違いを検出したり、コーディングスタイルを統一できます。 通常、ESLint のルールによって報告された問題 (error や warn) は人が手で修正します。ただし、ルールが報告する問題の中には「fixable」な性質を持ったものがあります。こうした fixable な問題は、eslint --fix で自動修正できます。例えば、object-shorthand ルールによって報告された問題は、以下のよう

GraphQL を使って Web アプリケーションを実装していると、GraphQL API のリクエストをモックしたいことがあると思います。 ユニットテストのために、ダミーレスポンスに差し替えたい ビジュアルリグレッションテストのために、ダミーレスポンスに差し替えたい Storybook で story を書くために、ダミーレスポンスに差し替えたい バックエンドの resolver 実装を待たずにフロントエンド側の開発を始めるために、ダミーレスポンスに差し替えたい 一般には GraphQL Client にモックするための機能が実装されてるので、そうしたものを使うことが多いと思います。 zenn.dev また最近は Client よりも外側のレイヤーでリクエストを interrupt してモックする「msw」を使うケースも増えてきてます *1。 blog.engineer.adways.n

多言語対応している Web アプリで、あらかじめファイルに書き出しておいた画像 (アセット) が言語別にあって、それをページに埋め込むにはどうするか、という話題です。基本は言語ごとに別々の画像を出すことないと思いますが、たまーにあるんですよね。例えばGoogle Play のバッジが言語ごとに違うので、これを言語ごとに出し分けたいとか。 Google Play バッジ – Google 色々方法があるので、それをいくつか紹介します。 方法1. import 文を言語の数だけ書く シンプルにやるなら、言語の数だけ import 文を書いて、next/image の <Image> コンポーネントで読み込むコードを書くかと思います。 // pages/index.ts import Image from 'next/image'; import GooglePlayJaJP from '../

Web ページを作るときに、あらかじめファイルに書き出しておいた画像 (アセット) をページに埋め込みたいことがよくあると思います。例えばヘッダーにサービスのロゴ画像を埋め込む場合、以下のようなコードを書くと思います。 // src/components/Header.tsx export function Header() { return ( <header> <img src="/assets/logo.png" alt="Logo image" /> {/* ... */} </header> ); } 一方で、最近のWeb フロントエンドフレームワーク (例: Next.js, Remix) を使う場合は、import 文を用いて以下のように書くことが多いと思います。 // src/components/Header.tsx import I_LOGO from '../asse

npm package を作る度にイチから開発環境の構築をしていて大変だったので、自分専用のテンプレートリポジトリを作りました *1。 github.com せっかくなので、テンプレートの特徴とか、どういうこと考えながら作ったとか紹介してみます。 はじめに: 基本的な技術スタック npm TypeScript Node.js Native ESM Prettier ESLint Vitest Renovate GitHub Actions vscode 向けの各種設定ファイル (extensions.json, launch.json, settings.json) GitHub の「テンプレートリポジトリ」機能を使う GitHub にそれっぽい機能があったので使ってみました。 docs.github.com 「Use this template」というボタンが出て便利です。 「Use t

去年の 11 月から続く一連の騒動を受けて、id:mizdra のフォロワーの中でも Twitter から Fediverse に移行してきている人が増えてきた。僕自身は移行するつもりはないけれど、移行したフォロワーが僕のツイートを Fediverse から見れるように、ツイートを Mastodon へと転送するようにしてみた。せっかくなので、そのやり方について書き残しておく。 作戦 IFTTT という「〇〇したらXXする」みたいなピタゴラスイッチをボタンポチポチで作れるサービスがある。これを使い、当該 Twitter アカウントでツイートがされたら、それを契機に Mastodon にトゥートを投稿する、というピタゴラスイッチを組むことにする *1。 転送する上での注意点 (2023/4/10 追記) (トラバで情報を頂いたので追記) 今回紹介する方法では、普段は自動投稿のみをする BOT

Next.js で開発していると、複数のページの getServerSidePropsで同じようなコードを度々書くことになると思う。例えば 「GraphQL クライアントでクエリを fetch して、そのレスポンスをpagePropsに焼き込むロジック」であったり、「(マルチテナントアプリケーションにおいて) リクエストヘッダーからテナントを特定するロジック」であったり。こうした大部分のページで使われるロジックのコードは、何度も書かずに済むよう、何らかの共通化をしたくなる。 すでに色々な人が似たような動機でgetServerSidePropsを共通化する方法を紹介していると思う。それを参考にしながら id:mizdra も自分流の共通化方法を実践している。何度か Next.js アプリケーションを作っているうちに、自分の型のようなものが身についてきたので、それを紹介してみる。 はじめに結論

登壇とかではなく、いち聴者として参加してきました。 yapcjapan.org 前日祭も参加していて、土日での京都滞在でした。 yapcjapan.connpass.com 僕と YAPC YAPC への参加は去年の YAPC::Japan::Online 2022 に続いてとなり、YAPC::Kyoto 2023 で2回目です。オフラインの YAPC は初めてでした。 また、別の話として新卒入社のタイミングがコロナと重なっており、参加人数が数百人超える大きなカンファレンスに出たことがほとんどありませんでした (入社前のものを含めると HTML5 Conference 2018 と builderscon tokyo 2019 くらい?)。大きなカンファレンスへの参加が4年ぶりということで楽しみにしてました。 印象深かったセッション moznion さんの廃墟の話が印象深かったです。出てく

id:mizdra は eslint-interactive というツールをメンテナンスしています。このツールを使うと、多数の ESLint エラーを効率的に修正できます (詳しくは以前書いた記事を見てください)。 www.mizdra.net eslint-interactive では「中規模〜大規模なコードベースであってもキビキビ動く」を大事にしてます。その一環として、eslint-interactive には CI (GitHub Actions) でベンチマークを取り、以前から大きく劣化していたら CI を fail させる仕組みがあります。 https://github.com/mizdra/eslint-interactive/actions/workflows/benchmark.yml?query=is%3Afailure しかし CI で実行するためにノイズが大きく、よく

ある機能を実装する際、完成形のコードになるまでには、プログラムとして不正確な状態や、プロダクト品質ではない状態を経る 静的型検査や lint rule に違反したコードが途中に挟まる 型エラーや lint エラーは望ましくないので、できるだけ早くこうした情報を開発者に伝え、気付けるようにすると良い CI でこうしたエラーを検知して、Pull Request をマージする前に気づけるようにするとか エディタ上にエラーの情報を表示して、コーディング中に気づけるようにするとか エラーを積極的に通知してくれるのはありがたいけど、やりすぎには注意するべき なんとなくでも動いてくれたほうが嬉しい 例えば lint エラーがあった際に、watch モードで起動しているビルドやテストの実行を止めて、lint エラー見つけたよーと教えてくれる開発環境がたまにあるけど... 別にビルドやテストの実行は止める必