サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
zenn.dev/qnighy
Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。本稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり
とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基本的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか? ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。
ただし、種別は以下の通りです。 prefix (前置演算子) …… もとの式の手前に何個でもつけられる演算子。 例: -~-~x postfix (後置演算子) …… もとの式の直後に何個でもつけられる演算子。 例: x.foo()`bar`[0] postfix once …… もとの式の直後に1個だけつけられる演算子。 例: x++ は可能だが x++-- はパースされない。 逆に ++--x はパースされるが、構文とは別のルールで禁止される。 (後述) infixL …… 中置演算子で左結合 (演算子の優先度が同じ場合は左側にあるほうが優先される) 例: 0.1 + 1.0 - 1.0 は (0.1 + 1.0) - 1.0 になる infixR …… 中置演算子で左結合 (演算子の優先度が同じ場合は右側にあるほうが優先される) 例: 2 ** 2 ** 3 は 2 ** (2 **
ECMAScript Annex Bおよび関連する仕様を読みます。 おことわり 言うまでもありませんが、ここで説明されている機能は使わないようにしましょう。 筆者がJavaScriptを書き始めたのは2005年頃で、その後2010年代は実質的な空白期間でした。そのため本記事に含まれる歴史的背景の説明は、2005年頃の筆者が学んだ内容に加えて、当時の資料を遡って調査した結果に基づいて記載されています。できる限り信頼性の高い情報を見つけた上で記述するよう心がけましたが、当時常識だった知識の欠落等により不正確な記述になっている部分があるかもしれません。もし誤り等があったら指摘いただけると嬉しいです。 現在のzennでは <sub></sub> や <ins></ins> は描画されていませんが、心の目で下付き文字や下線装飾に読み替えてください。 ECMAScript Annex B とは ECM
おことわり 個々の関数や変数に正しい型をつける話はしません。TypeScript HandbookのDeclarationの章などを読むことをおすすめします。 かわりに、本稿では関数や変数の型宣言をどこにどう置くべきかの指針を与えます。 モジュールとスクリプト declareを正しく使うにはまずモジュールとスクリプトの区別を理解し、意識することが大切です。 ブラウザやNode.jsは外部からの指定でモジュールとスクリプトを区別しますが、TypeScriptでは原則としてファイルの内容でモジュールとスクリプトを区別します。 import 宣言または export 宣言が1つ以上あればモジュール。 CommonJSモジュールの場合はTypeScript専用構文である import = 宣言、 export = 宣言を使う。 それ以外の場合はスクリプト。 ただし、JavaScriptファイル (
babel-plugin-node-cjs-interop というパッケージを作ったのでその紹介です。 (GitHub) 何が問題か Node.jsのネイティブES ModulesサポートとBabelやTypeScriptのES Modulesサポートを併用したときに問題が起きます。 ESMとCJS JavaScriptには標準のモジュールシステム (ES Modules, ESM) がありますが、ESMの策定前に先だっていくつかのコミュニティー定義のモジュールシステムが存在していました。そのうちNode.jsを中心として使われていたのがCommonJS Modules (CJS) です。そのNode.js界隈でもESMへの移行が進んでいます。 移行にあたって問題になることのひとつが、ESMとCJSのエクスポートモデルの違いです。 ESMでは、モジュールは0個以上の名前つきエクスポートを定
JavaScriptの識別子として使えるもの・使えないものに関して整理しました。 識別子、予約語、キーワード ECMAScriptでは識別子、予約語、キーワードを以下のように使っています 識別子 (identifier) とは、ざっくり言うとローカル変数名に使える名前のことです。が、この定義は細かいことを言うと状況によってぶれがあり複雑です。これを細かく見ていくのが本記事の主眼です。 例: foo 規格上は Identifier がこれに相当しますが、様々な例外を勘案するとこれをそのまま使うのが自然とは言えないため、以降では微妙に異なる定義を採用します。 予約語 (reserved word) とは、識別子と同じ形式であるにも関わらず識別子としては使えないもののことです。 例: if, public (strict modeの予約語だが、使い道はない) 非例: async (識別子として自
TypeScriptの主要な入力ファイルは .ts, .tsx, .mts, .cts ですが、JavaScriptファイル (.js, .jsx, .mjs, .cjs) も読み込んで処理することができます。JSDocによる型アノテーションを認識するため、生のJavaScriptでもそれなりに型をつけることができます。 本稿ではタイトル通り、TypeScriptのJSDocサポートでできることとできないこと (.ts でしかできないこと) をまとめます。 おことわり 本記事はTypeScript 4.4時点での実装状況に基づいています。なるべくソースコード中の関係する箇所を参照するようにしたので、今後の変更はご自分で検証してください。 (TypeScript Playgroundで試すだけでも有用です JavaScriptモードで開始できるリンク) JSDocの機能一覧・TypeScri
TypeScriptコンパイラリーディングをする上で、目当てのコードに辿りつくまでの手間を短縮するためのメモ書きです。コードリーディングの一般論や、TypeScriptコンパイラから読み取れる個別事象については極力省略しています。 TypeScriptの主要な処理系 多くのJavaScriptパーサーが拡張としてTypeScriptを読めるようになっています。また抽象構文木のフォーマットに事実上の標準があり、各パーサーはそれに従っています。AST Explorerでこれらのパーサーの出力を調べることができます。特に重要なのが以下の2つの処理系です。 TypeScript TypeScriptの型推論・リント・トランスパイル・モジュールバンドリング等ができる。 Babel TypeScriptのトランスパイルができる。 TypeScriptコンパイラの構成 libに標準ライブラリ (型定義フ
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 中止処理 並行処理ではしばしば実行中の処理を中止したい場合があります。 古典的なキャンセル処理 Webブラウザ/Node.jsともに、 setTimeout の中止が可能です。 const timeout = setTimeo
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 用語に関する注意 前々回定義した以下の用語を今回も使います。 1 tick ... タスクキューが1周すること。 1 microtick ... マイクロタスクキューが1周すること。 これらの単位は非同期処理の間の相対的な優先
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 用語に関する注意 前回定義した以下の用語を今回も使います。 1 tick ... タスクキューが1周すること。 1 microtick ... マイクロタスクキューが1周すること。 これらの単位は非同期処理の間の相対的な優先順
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 入門記事へのリンク プロミスの使用 - JavaScript | MDN Promise, async/await (現代の JavaScript チュートリアル) JSの初心者にPromiseとasync/awaitの使い方
現代のJSで Function コンストラクタを直接触ることはほとんどないと思いますが、隠された機能がちょっと面白いので本記事で説明します。 Function コンストラクタ JavaScriptの Function 関数は厳密にはクラスではありませんが、クラスのように使うことができます。 // typeof object === "function" とするべきだが、これでもほぼ同様に判定できる if (object instanceof Function) { // ... } // ソースコードから関数を生成 const f = new Function("x", "\"use strict\"; return x + 1"); console.log(f(42)); // => 43 // newが無くても同じ const f = Function("x", "\"use stri
目的と対象読者 IteratorとIterableとGeneratorとGenerator Functionの区別が曖昧な人 (記事前半) Generatorの制御フローを完全理解したい人 (記事後半) の理解を深めるための記事です。 まとめ IteratorとIterableの関係 Iteratorは狭義には呼び出し元の next 呼び出しに応じて要素を出力するインターフェースである。 IterableはIteratorを生成するインターフェースである。 IterableだからといってIteratorとは限らず、IteratorだからといってIterableとは限らない。しかし実際には多くのIteratorはIterableのインターフェースも実装している。 Iterableとコレクションは相互変換可能である。 Iterableは for-of ループで処理できる。 IteratorとG
<script> タグ内部は利便性や歴史的な経緯から、SGML/HTML/XMLの一般的なテキストノードとは異なる構文を持ちます。 本稿は最新のHTML仕様に基づいて <script> 要素内の構文を説明します。執筆時点のバージョンはここから参照できます。 HTMLとXHTML (XHTMLに興味がない人は読み飛ばしてOKです) 構文的な観点からは、HTMLとXHTMLは「よく似た別のマークアップ言語」であると考える必要があります。 <script> の扱いはそのような顕著な例のひとつです。XHTMLにおけるベストプラクティスとHTMLにおけるベストプラクティスは排他的であり、うまく共存する手は基本的にありません。 XHTMLでは <script> というタグ名が構文的に例外扱いされることはなく、かわりにCDATA sectionを使ってエスケープを回避するのが一般的です。 <script
Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基本となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別
「公式ドキュメントを読め」というのが急に話題になっていたので自分なりに整理してみました。 注意: そんなに真面目に推敲していません。フィーリングで書いているので実態に即してない部分もあるかも…… 公式ドキュメントとは何か あなたが使おうとしている道具 (ライブラリ、フレームワーク、プログラミング言語、ミドルウェア、コマンドラインツール、etc.)[1] は必ず誰かによって作られています。ある程度成熟した道具であれば通常、その作った人・組織自身によって公開されているドキュメントがあるはずです。これが公式ドキュメントです。 公式ドキュメントは、OSSにおいてはソースコードと双璧をなす最も信頼できる資料のひとつです。ソースコードが非公開の場合は通常、公式ドキュメントが最も信頼できる資料でしょう。 (以降はOSSを主に想定して説明します) たとえば…… Python のソースコードはGitHub上
「小説家になろう」のAPIを使ったちょっとしたアプリケーションを作ろうとして、Nコードの正規表現が必要になりました。そこで軽く調査したのですが、すでにより細かい調査をしている人がいたのでそれを元にまとめてみます。 ※運営元である株式会社ヒナプロジェクトに確認した内容ではないので注意してください 生成アルゴリズム DB設計が公開されているわけではないので推測ですが、「小説家になろう」「ノクターンノベルズ」「ムーンライトノベルズ」「ミッドナイトノベルズ」で公開された小説は同一のテーブルで管理され、連番のIDが割り振られると考えられます。 この連番のIDから1を引いて[1] 9999で割った余り[2]と商を求めます。 先頭→ 常に "n" です。 数字部分→ 9999で割った余りに1を足し、4桁になるように0で左詰めします。 ローマ字部分→ 9999で割った商を "a, b, c, ..., z
ジェネリクスを持つ多くの言語では括弧の種類が足りなかったり、既存の文法との互換性を保つために <> をジェネリクス引数に使っている。この文字は比較演算子やシフト演算子にも使われるため、多くの場合は構文的曖昧性の問題がある。 // ジェネリクス引数 (convert<int, string>(number)) // 比較演算子 (score < MAX_SCORE, score > (MIN_SCORE)) 各言語でこの問題をどのように解決しているか調べる。 関連する問題として < > を含むトークン (<<, >> など) をどう分割するかという問題があるが、こちらは本スクラップでは扱わない。
Gitで全てのリポジトリのignore指定を ~/.gitignore_global に置いている例はよく見られます。実際、この名前はGitが公式で公開している本 (Pro Git 2) (→日本語版) でも言及されています。 このような設定を行うには、グローバルな .gitignore のようなファイルが必要です。 ~/.gitignore_global ファイルへ次の内容を書き込んで、 (...) ところがこれはややミスリーディングです。この部分は core.excludesfile 自体の説明にほかならないのでわざわざ設定を書き換えていますが、実はデフォルト値があります。これは gitignoreのマニュアル で説明されています。 Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is eith
MDNにはたまにアットマークを2つ並べた @@ という記法が登場します。 Array.prototype[@@iterator]() The @@iterator method is part of The iterable protocol, that defines how to synchronously iterate over a sequence of values. しかし、この記法をそのままJavaScriptやTypeScriptの処理系に入力しても構文エラーになります。 console.log(Array.prototype[@@iterator]()); // => Uncaught SyntaxError: Invalid or unexpected token ではこの @@ はどこから来て、何を意味する記法なのでしょうか。 結論 これはドキュメント用のwell-
Mapped Typesの基本形 Mapped Typesの基本形は { [P in K]: T } です。 P は T の中で使える型変数です。このとき、 P はこのMapped Typeの引数型 (parameter type) K はこのMapped Typeの制約型 (constraint type) T はこのMapped Typeのテンプレート型 (template type) と呼びます。 T の中で P がどのように振る舞うかに注目すると type Element<P extends K> = T; という形の定義と相似であることから、P が引数型、 K が制約型と呼ばれる理由がうかがえるかと思います。 Mapped Typesの基本形で、 T が P に依存しないケースには Record<K, T> という名前がついています。 type Record<K extends
このツイートの解説をします。 TypeScriptにはanyは4種類、undefinedは3種類、nullは2種類、trueは2種類、falseは2種類、neverは5種類あるのか。普通に使ってる分にはわからないが…… TypeScriptでは表面上は同じ名前でも内部的に異なる型が割り振られている場合がいくつかあります。そのようなもののうち、プリミティブな型についてまとめました。 対象TypeScriptバージョンは4.1.3です。 2021-01-09 update: 数え方を見直しました。 any が4種類から6種類に増えました。 注意 ここに書かれていることを知らなくても、TypeScriptプログラミングにおいて全く困りません。あくまでコンパイラの機微を楽しむつもりでお読みください。 前提知識 any, undefined, null, true, false, never 型につ
Node.jsのアプリケーションでは以下のようなコードで始まるJavaScriptを見ることがあります。 この最初の行はshebang (hashbang)と呼ばれるものですが、なぜこれが含まれるJavaScriptコードが動作するのでしょうか。調べたところ、以下のような真相のようです。 元々JavaScriptには #! をコメントとみなす仕組みはなかった。[1] Node.jsの最初期にshebangサポートが入った。 (2009年のコミット) 2017年から2018年にかけて、shebangサポートがECMAScriptに提案された。 2017-11-28 TC39: "Interpreter Directive" がStage1 proposalになった (議事録, コミット) 2018-03-21 TC39: "Interpreter Directive" が "Hashbang
このページを最初にブックマークしてみませんか?
『Masaki Haraさんの記事一覧』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く