dtaniguchi.com

blog

VSCode の “実行とデバッグ” から Chrome が立ち上がらない時

d.taniguchi

2023年12月29日 22:45

Post / コメント

  • Tips
  • VSCode

私はいつも、 VSCode の実行とデバッグから開発環境を立ち上げている。

この機能の美点は、なんと言っても開発サーバーの起動と同時に、 Chrome が立ち上がる点にある。それも普段使いしている Chrome とは異なる、デバッグのための独立した環境を持つ Chrome だ。この環境は、使用の終了とともに閲覧履歴やお気に入り設定などが消失するゲストモードとは異なり継続する。このデバッグ専用 Chrome には開発に必要な設定だけを適用できるので、開発効率の良さは文句のつけようがない。そんなものがデバッグ連携機能とともに供されるのだから、至れり尽くせりとはこのことだ。

こんな快適な環境が破壊されるようなことがあったら、開発への悪影響は計り知れない。

ブラウザーは既に 古いデバッグセッション から実行されいるようです。それを閉じてからデバッグしてみてください。それ以外の場合は、 VS Code がそれに接続できない可能性があります。

悪夢は現実になったようだ。突如、デバッグ専用の Chrome が立ち上がらなくなった。

このエラー、一度表示されたら最後、自然に復旧することはない。締め切りに追われる中、開発環境の再構築は痛いロスタイムだ。しばらくは諦めて普段使っている Chrome で開発を進めていたが、 IDE と Debugger が連携しない不自由さは筆舌に尽くしがたい。何かコード上の問題に突き当たる度に DevTool から対象ファイルを探して、 Breakpoint を設定するのが面倒になるのに時間はかからなかった。

そして、何度か環境構築のやり直しと、問題再発を繰り返したていたら原因が判明した。

Chrome のユーザー選択画面が表示されているタイミングで、開発環境の立ち上げを行うと問題が発生する。ユーザー選択後であれば問題は生じない。

解決方法は VSCode のクリーンインストールになる。デバッグセッションとやらは、 VSCode 側で保持されいてるようだ。

Visual Studio Code – “Uninstall Visual Studio Code” https://code.visualstudio.com/docs/setup/uninstall#_clean-uninstall

Chrome のクリーンインストールは必要なかった。

yarn から npm に戻した話 ② – package.json 編

d.taniguchi

2023年10月7日 22:26

Post / コメント

  • Node.js
  • npm

前回の続きである。

前回は yarn1 系の yarn install コマンドに、 yarn.lock ファイルが存在する場合 Storybook7 の依存性解決が失敗するというバグがあったため、プロジェクトで使用するコマンドをすべて npm に戻したという話をした。

今回は、npm コマンドに戻したことで、 yarn コマンドでは何事もなかった package.json の scripts プロパティ呼び出しが一部失敗するという問題が発生したので、その話をする。

呼び出しが上手くいかなくなったのは、npm-run-all を使用する下記 package.json の 11 行目の build:stg コマンドと、 12 行目の build:prod コマンドである。これは私が STG 環境と PROD 環境向け Build のために 8 行目の build コマンドを参考に追加したものである。8行目の build コマンドは Vue3 の Scaffolding tool にて Project 生成した当初からあったものだ。

package.json
{
  "name": "vue3",
  "version": "0.0.0",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "run-p type-check \"build-only {@}\" --",
    "build-only": "vite build",
    "type-check": "vue-tsc --build --force",
    "build:stg": "run-p \"build {@}\" -- --mode stg --sourcemap true",
    "build:prod": "run-p \"build {@}\" -- --mode prod",
    // 省略
  },
  "dependencies": {
    // 省略
  },
  "devDependencies": {
    "npm-run-all": "^4.1.5",
    // 省略
  }
}

yarn だと、正常に動作する。

ところが npm を使用すると失敗する。

vite v5.1.3 building for production...
 0 modules transformed.
x Build failed in 6ms
error during build:
RollupError: Could not resolve entry module "stg/index.html".
    at getRollupEror (file:///Users/work/Desktop/vue3/node_modules/rollup/dist/es/shared/parseAst.js:375:41)
    at error (file:///Users/work/Desktop/vue3/node_modules/rollup/dist/es/shared/parseAst.js:372:42)
    at ModuleLoader.loadEntryModule (file:///Users/work/Desktop/vue3/node_modules/rollup/dist/es/shared/node-entry.js:18928:20)
    at async Promise.all (index 0)
ERROR: "build-only stg" exited with 1.
ERROR: "build --mode stg --sourcemap true" exited with 1.

コマンドに引数を引き渡すための Syntax だと思われる `{@} – -` だが、私は今回のプロジェクトで初めて目にすることになった。これは何物だろう。npm の公式を調べたのだが情報が出てこない。

エラーを眺める限り引数がズレている。それは分かるが、この問題の辛いところはエラー内容が発生している問題を表現していない点にある。キーワードをいろいろと変えて検索を試みたのだが、同じ問題に直面しているページすら発見できなかった。そんなことがあり得るのか?

諦めるのは簡単だ。 STG 環境や PROD 環境向け Build コマンドを 以下のようにしてしまえばいいだけだ。

    "build:stg": "vite build --mode stg --sourcemap true",
    "build:prod": "vite build --mode prod",

しかし、これは敗北である。これでは、型チェックコマンドを別途実行しないといけない。何より折角の build コマンドが再利用できない。再利用できる物は徹底的に再利用するのがプログラマの美徳だ。プロは差分しか書かない。平然と重複コードを許すエンジニアに価値はない。こんなコードは耐えられない。この回避策はあまりに情けない。

ヤケクソ気味になり、ひたすら問題に体当たりしていると、解決方法が判明した。以下のように修正したところ、 npm コマンドで引数が正しく引き渡された。

    "build": "run-p type-check \"build-only {@}\" -- --",
    "build:stg": "run-p \"build {@}\" -- -- --mode stg --sourcemap true",
    "build:prod": "run-p \"build {@}\" -- -- --mode prod",

おわかりだろうか、` – -` をさらにもう一つ追加するのだ。

驚くべきことに、 Vue3 の Scaffolding tool で最初から設定されている build コマンドから間違っていたのである。Vue3 の開発チームはまだ yarn を使っているのかもしれない。

yarn から npm に戻した話 ① – Storybook が起動しない編

d.taniguchi

2023年10月6日 6:19

Post / コメント

  • Node.js
  • npm
  • Storybook

引き続き、Vue3 による新規開発プロジェクトで仕事をしている。

プロジェクト基盤の整備が終わり、コンポーネント開発に着手した。 Composition API でボタンや入力コンポーネントを作成したり、Router に Page コンポーネントと Path の紐付けを追加したり、といった作業を進める。

Vue Router4 に Nested Routes があるのは嬉しかった。今回 Modal 表示を Path で制御したい箇所がある。Next.js の App Router では Layout 作成がしやすかった。この機能は積極的に使いたい。

いくつかコンポーネントができたので、 Storybook7 を導入して作成したコンポーネントを登録することにした。まずは Local 上で Project に Storybook を Install 、正常に起動した。続いて docker-compose.yml にコンテナを追加して起動しようとしたとき問題が発生した。起動しないのである。またかい。Vite が Docker で動作しないに引き続きである。

Dockerfile は以下のような内容だ。

Dockerfile
FROM node:18.18 AS development

ENV LANG C.UTF-8
ENV TZ Asia/Tokyo

RUN apt-get update

WORKDIR /app
COPY ["package.json", "yarn.lock", "./"]

RUN yarn

エラー表示は以下の通り。

storybook  | 🔴 Error: It looks like you are having a known issue with package hoisting.
storybook  | Please check the following issue for details and solutions: https://github.com/storybookjs/storybook/issues/22431#issuecomment-1630086092
storybook  | 
storybook  | 
storybook  | /app/node_modules/cli-table3/src/utils.js:1
storybook  | const stringWidth = require('string-width');
storybook  |                     ^
storybook  | 
storybook  | Error [ERR_REQUIRE_ESM]: require() of ES Module /app/node_modules/string-width/index.js from /app/node_modules/cli-table3/src/utils.js not supported.
storybook  | Instead change the require of index.js in /app/node_modules/cli-table3/src/utils.js to a dynamic import() which is available in all CommonJS modules.
storybook  |     at Object.<anonymous> (/app/node_modules/cli-table3/src/utils.js:1:21)
storybook  |     at Object.<anonymous> (/app/node_modules/cli-table3/src/table.js:2:15)
storybook  |     at Object.<anonymous> (/app/node_modules/cli-table3/index.js:1:18)
storybook  |     at Object.<anonymous> (/app/node_modules/@storybook/core-server/dist/index.js:66:2799)
storybook  |     at Object.<anonymous> (/app/node_modules/@storybook/cli/dist/generate.js:11:4494)
storybook  |     at Object.<anonymous> (/app/node_modules/@storybook/cli/bin/index.js:26:1)
storybook  |     at Object.<anonymous> (/app/node_modules/storybook/index.js:3:1) {
storybook  |   code: 'ERR_REQUIRE_ESM'
storybook  | }

御丁寧なことにエラーに直接 Issue の URL が明記されている。世の中にそんなエラー表示があったのか。

https://github.com/storybookjs/storybook/issues/22431#issuecomment-1630086092

Issue を要約すると次のようになった。

  • yarn ではなく、 pnpm を使用したら動いた
  • yarn ver. 1 系のバグ
  • yarn ver.3 系にアップグレードすると直る
  • yarn.lock がある状態で yarn コマンドを実行すると依存性解決に失敗する
  • package.json だけの状態から yarn コマンドを実行すると依存性解決は成功する

試しに正常動作している Local の node_modules を削除して yarn コマンドを再実行すると、 問題が出現した。原因は Docker ではなく yarn だった。yarn install コマンドでは yarn.lock ファイルがある場合と、ない場合で異なる処理系を用いているのだろうか。悪い設計の典型だ。

依存性解決に yarn.lock ファイルを利用できないということは、コンテナイメージが作られる度に、 Install されるライブラリの Version が微妙に異なるコンテナができあがることを意味する。仮にE2E テストが失敗しても、テストに使ったコンテナが消えた途端、テストが失敗したライブラリの Version 情報が失われることになる。こんな方式は採用できない。

呆れながら npm i コマンドを実行し、node_modules を削除後 npm ci コマンドを実行したら、 Storybook は正常に立ち上がり、 Docker 上でも問題なく動いた。

Vue3 や Storybook の公式を見てみると npm をデフォルトとして表示している。 Storybook 公式での並び順は、今回の Issue を反映しているかのようだ。もう yarn を使用する理由はないようだ。

私のプロジェクトでも、すべて npm で作業を進めることにした。Dockerfile やドキュメント類のコマンドはすべて yarn から npm に戻した。

型安全芸術への招待 – TypeScript で Object の const assertion と Key, Value の型指定が気に入っている件

d.taniguchi

2023年10月1日 21:31

Post / コメント

  • Java
  • Tips
  • TypeSafetyArt
  • TypeScript

学生の頃、趣味で VBA や COBOL を書いていたのだが、仕事で書くようになったのは Java であった。Java で学んだことは今も血肉として活きているし、代えがたい愛着もある。Java の好きな点はいくつもあるが、とりわけ好きだったのが Enum である。

よくこんなコードを書いた。

Options.java
public interface Options<K extends Serializable, V extends Serializable> {
    K getKey();
    V getValue();

    static <K extends Serializable, ENUM extends Enum<ENUM> & Options<K,?>> ENUM getEnumFromKey(Class<ENUM> clazz, K key) {
        for (ENUM enm : clazz.getEnumConstants())
            if (key.equals(enm.getKey())) return enm;
        throw new IllegalArgumentException();
    }

    static <V extends Serializable, ENUM extends Enum<ENUM> & Options<?,V>> ENUM getEnumFromValue(Class<ENUM> clazz, V value) {
        for (ENUM enm : clazz.getEnumConstants())
            if (value.equals(enm.getValue())) return enm;
        throw new IllegalArgumentException();
    }
}
Enums.java
public class Enums {
    public enum Sex implements Options<Integer, String> {

        FEMALE(0, "女性"),
        MALE(1, "男性");

        private final int key;
        private final String value;
        Sex(int key, String value) { this.key = key; this.value = value; }
        @Override public Integer getKey() { return key; }
        @Override public String getValue() { return value; }
    }
}
User.java
class User {
    @Getter
    @Setter
    private String name;

    @Getter
    private Enums.Sex sex;

    @Getter
    @Setter
    private int age;

    public void setSex(int sex) {
        this.sex = Options.getEnumFromKey(Enums.Sex.class, sex);
    }
}

上記コードは DB から取得した User Entity が、取得時点で int 定数を Enum に変換、カプセル化される様子を再現している。

Java の Enum は Singleton なので、データの一意性や型安全性、不変性を保証するときに強力な効果を発揮する。データ入力時点には意味も型安全も持たなかった int 定数は、意味も型安全も不変性も一意性も有している Enum で Field に保持されるので、それ以降の処理で定数やラベルの誤りなど発生しようがない。

Generics を使用することで、動的型付け言語と同じ型指定の柔軟性を持たせつつ、型の誤りは問題発生段階から抑止できる。これは動的型付け言語が逆立ちしても実現できない、型安全のためのチェック網だ。これはもう静的型付け言語による、型安全芸術と呼んでよろしかろう。

Java が魅せるオブジェクト指向と静的型付けの世界に耽溺していた私には、 当初 TypeScript に対してよい印象を持つことは難しかった。JavaScript との相互変換を意識するあまり、静的型付け言語としてはあまりに型安全性が脆弱な、”妥協的産物”というイメージがあったからである。例を挙げるなら Union 型だろう。

TypeScript
function getYearOfBirth(age: string|number) {
    let numericAge
    if (typeof age === "string") {
        numericAge = Number(age)
        if (Number.isNaN(numericAge)) {
            throw Error()
        }
    } else {
        numericAge = age
    }
    // 以降省略

この見苦しい関数は何だ。なぜ何の継承関係もない string 型と number 型の両方が、同じ関数の同じ引数に指定できてしまうのだ?言語仕様がリスコフの置換原則を否定しているではないか。これでは静的型付け以前に、オブジェクト指向言語と言えるのかすら怪しくはあるまいか。

今考えると、言語仕様を妥協したとしても、JavaScript と完全にトランスパイルできるようにしたのは、正しい判断だったと思っている。現実世界では、理想を主張する方が簡単だ。TypeScript を厳格な静的型付け言語に設計し、TypeScript から JavaScript へ変換できても、JavaScript のライブラリは TypeScript で使用不可能だったら、これほど広く使用される言語になったかどうか疑わしい。使われないものに価値はない。 Alt JS のデファクトスタンダード登場が遅れていたかもしれない。Microsoft 社の TypeScript 開発チームのこの英断こそ、プロの仕事と呼ぶに相応しい。

特に面白みもなく書いていた TypeScript が、私の中で輝きを放つきっかけとなったのが Literal 型であった。

TypeScript
type Fruit = "apple" | "orange" | "grape" | "banana"

Literal 型を初めて知ったときは驚愕した。まさか string や boolean といった型にまだ subtype を定義できる余地が残っていたとは思いもよらなかったからだ。Anders Hejlsberg の仕業だろうか。才能豊かな言語設計者の発想には頭が下がる。

Literal 型は Enum と似ている。似ているが 仰々しい Java の Enum より遙かにシンプルな Syntax だ。これはとんでもなくよいアイデアではあるまいか。

TypeScript
type user = {
  name: string,
  age: number
  favoriteFruit: Fruit
  ...
}

これを Key Value 形式のデータ構造である Object 型に応用すれば、上述した Java の Enum と同じような役割を与えることが可能になるではないか。

TypeScript では Object の key を ` <T extends Object> keyof T ` 、value を ` <T extends Object> T[keyof T] `として型定義することができる。

TypeScript
export type Options<K extends number|string, V> = Readonly<Record<K, V>>

export type OptionsKey<T extends Options<any, any>> = keyof T

export type OptionsValue<T extends Options<any, any>> = T[keyof T]


/**
 * Options の value から key を取得する
 *
 * @param options
 * @param value
 * @returns key
 */
export const getOptionsKeyFromValue = <T extends Options<any, any>, K extends keyof T, V extends T[keyof T]>(options: T, value: V): K =>
   (Object.entries(options).find(el => el[1] === value) as [K, V])[0]
TypeScript
export const SEX = {
  0: "女性",
  1: "男性"
} as const satisfies Options<number, string>
TypeScript
export type User = {
  name: string
  sex: OptionsKey<typeof SEX>
  age: number
}

これにより格納される値はただの int 定数であったとしても、コード上は意味も型安全もある別物となった。例えば、テストや Storybook の引数設定などで、Field 値が必要になったとしても、型を意識することなく導出可能である。

TypeScript
const user: User = {
  name: "test taro",
  sex: getOptionsKeyFromValue(SEX, "男性"),
  age: 23
}

この関数、さらに Literal 型の効力で選択肢が Suggest される。

何という便利、何という型安全性だろう。これこそ私が目指す型安全芸術だ。ただの JavaScript の Object が、TypeScript の型機能によって、別次元のものとなった。

Vite が Docker で動作しない

d.taniguchi

2023年9月23日 22:55

Post / コメント

  • Docker
  • Tips
  • Vite
  • Vue3

Vue3 による新規開発プロジェクトが始まり、プロジェクト基盤の整備を行っている。

Scaffolding tool で 初期 Project を生成、Router や Linter、Validator 等、使用ライブラリの選定・設定や、環境毎の DI 設定など、前準備の真最中だ。

概ね必要な部品群は揃い、いよいよ Dockerfile を追加して docker-compose で画面が立ち上がれば準備完了という段に来て、これまで堅調に進んでいた構築作業は水を差された。これは恒例行事だった。Docker の設定、この作業がスムーズにいった試しはない。悪いことに、今回はいつも以上にしぶとい抵抗を見せるのだった。どうやっても Vite が下記のエラーで立ち上がらない。

Segmentation fault

この時の Vite の Version は 4.4.9 、Docker for Mac の Version は 4.23 であった。調べてみると Docker の GitHub リポジトリに Issue が立っていた。

https://github.com/docker/for-mac/issues/6824

このエラー、 Docker の開発陣にも原因がよく分かっていないようだった。以下条件で発生するという。

  • Intel Mac の一部機種
  • Node Version 18 〜 20 で実行
  • Docker for Mac Version 4.19 以上
  • Docker ではなく、 Mac の Hypervisor の問題

CPU に Core i7 や i9 を搭載している機種で多く発生していて、 i5 だと動くことが多いようである。私の使用していた iMac は i9 だ。手元に i5 搭載の MacBook があったのでこちらにリソースを移して docker-compose をたたいてみたらすんなり動いた。

問題が発生しても対応は簡単で、Docker の GUI から Setting > General 内にある VirtioFS のチェックを osxfs(Legacy) に変更、Use Virtualization framework のチェックを外せばいいだけである。

これにより Vite が立ち上がるようになった。