カテゴリー: 技術

本記事は https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/yield*#%E4%BE%8B の yield* 式自体の値 に例示されているものを改めて考えつつ説明したものです。

https://github.com/susisu/tskaigi2025 のコードリーディングをしていて、ここがわからなくてしばらく詰まっていた。

it("ジェネレータから yield された Promise が fulfill されたらその位置から再開する", async () => {
  function* myFunc(): Comp<number> {
    const a = yield* waitFor(Promise.resolve(1));
    const b = yield* waitFor(Promise.resolve(2));
    return a + b;
  }
  const promise = run(myFunc());
  await expect(promise).resolves.toEqual(3);
});

JavaScriptには yield* という構文がある。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/yield*

これはジェネレーターの中で使い、別のiterableに制御を移譲するために使う。とてもわかりやすい例があったので引用させてもらう。
https://stackoverflow.com/questions/17491779/delegated-yield-yield-star-yield-in-generator-functions

function* someGenerator() {
    yield 0;
    yield [1, 2, 3];
    yield* [4, 5, 6];
}

for (v of someGenerator()) {
    console.log(v);
}
// 0, [1, 2, 3], 4, 5, 6

yield [1, 2, 3]; は [1, 2, 3] をそのままyieldする。一方で yield* [4, 5, 6]; は [4, 5, 6] がiterableなオブジェクトならば、その生成値を1つずつyieldする。移譲すると書いたが、someGeneratorの呼び出し側から見ると、内側の内側にあるiterable（[4, 5, 6] のこと）を透過的に扱えるとも言えそうだ。

ところでジェネレーターの中ではyieldの他にreturnも使える。returnに到達すると値を返しつつジェネレーターは終了する。

const gen = function* () {
  yield 1;
  return 2;
}()

console.log(gen.next()); // { done: false, value: 1 }
console.log(gen.next()); // { done: true, value: 2 }
console.log(gen.next()); // { done: true, value: undefined }

では yield* で移譲されたジェネレーターがreturnしたとき何が起きるのか。僕はなんとなくreturnされた値も透過的に外側から触れると思っていたが、触れない。

const g_inner = function* () {
    yield 1;
    return 2;
}();

const g_outer = function* () {
    const a = yield* g_inner;
    yield 3;
    return 4;
}()

console.log(g_outer.next()); // { done: false, value: 1 }
console.log(g_outer.next()); // { done: false, value: 3 }
console.log(g_outer.next()); // { done: true, value: 4 }

なんとなく出てくる値は 1, 2, 3, 4 になりそうな気がしたが（俺だけか？）、正解は1, 3, 4だ。MDNに

yield* は式であり、文ではありません。そのため、値に評価されます。

とサラリと書かれている通り、g_innerのreturnで返される値はg_outerのaに束縛される。それだけで、g_outerの呼び出し側には返されない。

ここで逆に考えてみる。移譲先のreturnで停止すると仮定すると、どのような問題が起きるだろうか？

まず、yieldの機能として、呼び出し側からnextに引数を与えることで、値を受け渡すことができる。

const gen = (function* () {
  const a = yield 1;
  const b = yield 2;
  return a + b;
})();

console.log(gen.next());     // { value: 1, done: false }
console.log(gen.next(10)); // { value: 2, done: false }
console.log(gen.next(20)); // { value, 30, done: true}

初回呼び出し後にyield 1;で停止しているジェネレーターに対して10を与えて再開させ、次にyield 2;で停止しているジェネレーターに20を与えて再開させている。3回目のnext呼び出しの後はreturn a+bに到達して30を返して終了する。

これは yield* で移譲された内側のジェネレーターにも機能するのだが、returnで停止すると仮定してシミュレーションしてみる。

const g_inner = function* () {
    const a = yield 1; // aに10が入る
    return 2; // ここで停止すると仮定
}();

const g_outer = function* () {
    const x = yield* g_inner;
    yield 3;
    return 4;
}()

console.log(g_outer.next());     // { done: false, value: 1 }
console.log(g_outer.next(10)); // { done: false, value: 2 } が返ると仮定する
console.log(g_outer.next(20)); // { done: false, value: 3 } このnextに渡した20はどこへ…？
console.log(g_outer.next());     // { done: true, value: 4 }

return 2で停止すると仮定すると、そのときnextに渡された値はどこに行くのだろう？xにはg_innerから返された値が入ることになっているので行き場がない。捨てるしかない。そうなると、g_outerを利用する側は中でg_innerに処理を移譲しているなんて本来知る必要がないのに、それを知らないと何回目かのnextに渡した値が勝手に捨てられてしまうことになる。インターフェースとしての安定性が失われている。

そういう意味で、returnでは停止しないのは筋が通っている。割と非直感的だと思ったんだけど、MDNだとサラッと1行説明されて例が1つあるだけで終わるので難しかった。普段からジェネレーターを使ってる人（いますか？）には自明な動作なのかもしれない。

一般のジェネレーターにおいてreturnは停止して値を返すという点でyieldと同じように見えるが、その見方は間違っているのだろう。yieldが明確に停止を意図した機能である一方で、returnは終了だから結果的に停止に見えてしまっているだけで、その本質はただ値とともに処理を返すことだけだ。yield* のようにその後も外側のジェネレーターに制御を戻して続行できるのであれば停止しないように見えるのは必然なのだろう。

項目	内容	得点	換算点
睡眠時間	7時間19分	100	13.0/13.0
起床	8:08	93	7.4/8.0
散歩	実施・ゴミ拾いあり	100	5.0/5.0
朝食の栄養カバレッジ	3色カバー	100	5.0/5.0
体操	実施	100	5.0/5.0
労働	passion: 85点, discipline: 75点	80	19.2/24.0
ジム	有酸素	100	12.0/12.0
勉強会	参加	100	12.0/12.0
個人開発	実施	100	7.0/7.0
あすけん	-	80	7.2/9.0
総合	1日の総合評価	-	93

今日の仕事は並列度が高くてあまり集中できなかったな。

『モナ王』

『モナ王』を食べた。『チョコモナカジャンボ』の隣に並んでいたらまず選ばない商品だが、だからこそ食べておくかということで食べた。結論から言うと特に選ぶ理由はない。チョコの風味が要らない、パリパリが要らない、そんなムーディーな気分の日ならいいかもしれない。

sort-package-json3.2.0でソートアルゴリズムが変わったっぽい

sort-package-jsonというライブラリがある。その名の通りpackage.jsonをソートすることで秩序をもたらすツールである。最近npmのソートアルゴリズムに合わせるということで変更が入ったのだが

https://github.com/keithamus/sort-package-json/pull/358

これがyarnのソートアルゴリズムとは違っており、しかも間の悪いことにyarnは yarn install を実行するたびにpackage.jsonをソートし直すので、sort-package-jsonとの共存が実質的に不可能である（開発中に yarn install をするたびに意味のない差分が発生し、commitするときにlint-stagedで消える）。じゃあsort-package-jsonの代わりに yarn install を使えばいいのでは？とも思うが、コマンドの意味・副作用からしてかなり正しくない度が高い解決だ。苦しい。

https://github.com/keithamus/sort-package-json/issues/363

ソートアルゴリズムの違いというのはどうやらこういう違いのようだ。

https://github.com/keithamus/sort-package-json/issues/355#issuecomment-2848325132

// yarn
> ["a", "b", "A", "B"].sort()
[ 'A', 'B', 'a', 'b' ]
// npm, sort-package-json
> ["a", "b", "A", "B"].sort((a,b) => a.localeCompare(b, "en"))
[ 'a', 'A', 'b', 'B' ]

実はnpmではパッケージ名に大文字を使ってはいけない。昔は使えたのかも知れないが、今は大文字名でinstallしようとすると404で弾かれる。だからこの問題は内製パッケージを使っていたりエイリアスを付けていたりしないと表面化しにくい（一応 - と _ とかでも差が出てしまうらしい？）。

まあそこまで重大な違いではないように思えるが、sort-package-jsonは結構な人気があるパッケージなので、そこそこ困っている人がいるかもしれない。

import { foo } from "./foo.ts";

のように .ts を付けてimportするためにはtsconfig.jsonでallowImportingTsExtensionsがtrueになっている必要がある。しかしこのオプションはnoEmitも同時にtrueにしなければならない。その理由はuhyo氏が解説している。トランスパイルしたら.tsファイルじゃなくなるのでimportできなくなって意味ない（そこの辻褄合わせまでtscはやりません）のでトランスパイルしないでくださいということ。

https://zenn.dev/uhyo/articles/rewrite-relative-import-extensions-read-before-use#--allowimportingtsextensions-%E3%82%AA%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3

じゃあトランスパイル後に消えていいimport、つまりimport typeならよくね？と思って調べたら、実際そうだった。

// allowImportingTsExtensionsがfalseでもエラーにならない
import type { foo } from "./foo.ts";

https://github.com/microsoft/TypeScript/pull/54746

これに気づいたのは、vibe codingで軽めに作っているアプリケーションにテストを追加しようとしたときだ。現状nodeのビルトインテストフレームワークと--experimental-strip-typesを使うとjestやらvitestやらがなくてもそれっぽいテストが作れる（jestのためにトランスパイルとか、結構複雑だったよね）。

https://blog.koh.dev/2024-10-23-nodejs-builtin-test-typescript/

しかしnodeとして実行するならimportには拡張子が必要であり

https://zenn.dev/mizchi/articles/experimental-node-typescript#%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E8%A7%A3%E6%B1%BA

拡張子をつけると今度は「allowImportingTsExtensionsをtrueに旋回！」と怒られる。うーん、このルールの意図を考えればimport typeにすれば通るんじゃね？と思ったら通ったという次第。import typeにできる箇所で良かった。というかそうでなければそもそもtscだけではビルドできなかったんだけどな。

nodeのドキュメントにもimport typeはstripすると読める説明が書いてあった。

https://nodejs.org/api/typescript.html#importing-types-without-type-keyword

Due to the nature of type stripping, the type keyword is necessary to correctly strip type imports.

TypeScriptとの微妙な距離感が面白かった。

https://nodejs.org/api/typescript.html#importing-types-without-type-keyword

As in JavaScript files, file extensions are mandatory in import statements and import() expressions: import './file.ts', not import './file'.

The tsconfig.json option allowImportingTsExtensions will allow the TypeScript compiler tsc to type-check files with import specifiers that include the .ts extension.

あくまで拡張子付きのimportという文法が先にあり、それをTypeScriptが許可するかはオプション次第ですね〜というスタンスが感じられ、なるほど言語を作っている方からはそういう見方になるんだなあと思った。