[smalruby3-editor] Fix build failures and integration test timeouts

[takaokouji]

Related to

#29

Description

Almost all integration tests in the smalruby3-editor monorepo currently fail because the build process is broken. The build fails primarily due to Module not found errors, as many source files and configuration files still refer to packages using the @scratch/ scope (e.g., @scratch/scratch-vm) instead of the @smalruby/ scope used in this fork.

Root Causes

1. Build Failure: npm run build fails because sub-packages cannot resolve dependencies that have been renamed to @smalruby/.
   • Example: packages/scratch-render/src/SVGSkin.js requires @scratch/scratch-svg-renderer.
2. Webpack Configurations: webpack.config.js in scratch-gui and scratch-vm still use @scratch/ in CopyWebpackPlugin patterns and other places.
3. Integration Test Timeouts: Since the build fails, the build/index.html file used by integration tests is missing or broken, leading to Selenium timeouts when trying to find elements.

Findings

A search revealed numerous occurrences of @scratch/ that should be updated:

• packages/scratch-gui/src/**/*.jsx
• packages/scratch-render/src/**/*.js
• packages/scratch-vm/src/**/*.js
• packages/task-herder/package.json (still named @scratch/task-herder)
• Various webpack.config.js, tsconfig.json, and eslint.config.mjs files.

Proposed Improvements

1. Global Package Name Update: Replace all occurrences of @scratch/scratch-vm, @scratch/scratch-render, @scratch/scratch-svg-renderer, and @scratch/task-herder with their @smalruby/ counterparts throughout the codebase.
2. Update Webpack Paths: Ensure webpack.config.js files correctly reference node_modules in the monorepo structure (e.g., using workspaces or correct relative paths).
3. Fix task-herder: Update packages/task-herder/package.json to use the @smalruby scope if it's intended to be part of this fork.
4. Verify Build: Ensure npm run build completes successfully.
5. Run Integration Tests: Once the build passes, verify that npm run test:integration succeeds.

[takaokouji]

調査結果：メニュー項目クリック時にメニューが閉じない原因

問題の概要

scratch-gui（upstream）では、Fileメニューや Editメニューのメニュー項目をクリックしても、メニューが自動的に閉じられません。これは設計上の問題です。

根本原因

1. メニューを開くイベントハンドラの問題

smalruby3-editor（問題あり）の実装：

// packages/scratch-gui/src/components/menu-bar/menu-bar.jsx
<div
    className={classNames(styles.menuBarItem, styles.hoverable, {
        [styles.active]: this.props.fileMenuOpen
    })}
    onClick={this.props.onClickFile}  // ← onClick を使用
>

smalruby3-gui（正常動作）の実装：

// src/components/menu-bar/menu-bar.jsx
<div
    className={classNames(styles.menuBarItem, styles.hoverable, {
        [styles.active]: this.props.fileMenuOpen
    })}
    onMouseUp={this.props.onClickFile}  // ← onMouseUp を使用
>

2. メニューを閉じる責務

メニュー項目のクリックハンドラ（例：handleClickNew、handleClickGenerateRubyFromCode）は、処理の最後に onRequestCloseFile() や onRequestCloseEdit() を呼び出してメニューを閉じる責務を持っています。

// packages/scratch-gui/src/components/menu-bar/menu-bar.jsx:283-297
handleClickNew () {
    // ... 処理 ...
    this.props.onRequestCloseFile();  // メニューを閉じる
}

handleClickGenerateRubyFromCode () {
    this.props.updateRubyCodeTargetState(this.props.vm.editingTarget);
    this.props.onRequestCloseEdit();  // メニューを閉じる
}

3. Menu コンテナのイベントリスナー

Menu コンテナ（src/containers/menu.jsx）は、mouseup イベントをリッスンしてメニュー外のクリックを検出します：

// src/containers/menu.jsx:27-36
addListeners () {
    document.addEventListener('mouseup', this.handleClick);
}
handleClick (e) {
    if (this.props.open && !this.menu.contains(e.target)) {
        this.props.onRequestClose();  // メニュー外のクリックでメニューを閉じる
    }
}

重要: このハンドラは、メニュー内のクリックでは何もしません。メニュー項目の onClick ハンドラが onRequestClose を呼び出す責務を持っています。

なぜ onClick だと問題が発生するのか

イベントバブリングによる競合

onClick を使用した場合（smalruby3-editor - 問題あり）の処理シーケンス：

1. ユーザーがメニュー項目をクリック
2. MenuItem の onClick が発火
   • handleClickGenerateRubyFromCode() が呼ばれる
   • this.props.onRequestCloseEdit() が呼ばれる
   • closeEditMenu() action が dispatch される
   • メニューが閉じられる
3. click イベントがバブリングして親要素（Edit メニュー div）に伝播
4. Edit メニュー div の onClick が発火
   • this.props.onClickEdit() が呼ばれる
   • openEditMenu() action が dispatch される
   • メニューが再び開かれる
5. 結果：メニューが一瞬閉じられて即座に再び開かれるため、閉じられたように見えない

onMouseUp を使用した場合（smalruby3-gui - 正常動作）の処理シーケンス：

1. ユーザーがメニュー項目をクリック
2. mouseup イベントが発火
   • Edit メニュー div の onMouseUp が呼ばれる
   • しかし、既にメニューが開いている状態では、openEditMenu() を再度呼んでも状態は変わらない
3. click イベントが発火
   • MenuItem の onClick が呼ばれる
   • handleClickGenerateRubyFromCode() が呼ばれる
   • this.props.onRequestCloseEdit() が呼ばれる
   • closeEditMenu() action が dispatch される
   • メニューが閉じられる
4. click イベントがバブリングしても、Edit メニュー div には onClick ハンドラがないため、何も起こらない
5. 結果：メニューが正しく閉じられる

重要: onClick を使用すると、イベントバブリングにより、メニュー項目のクリックがメニューを閉じた後に、親要素のクリックハンドラがメニューを再び開いてしまいます。onMouseUp を使用することで、メニューを開くイベントとメニュー項目のクリックイベントが異なるタイミングで処理されるため、この問題を回避できます。

smalruby3-gui での修正

smalruby3-gui では、以下のメニューを開くイベントハンドラが onClick から onMouseUp に変更されています：

1. File メニュー: onMouseUp={this.props.onClickFile}
2. Edit メニュー: onMouseUp={this.props.onClickEdit}
3. その他のメニュー: 同様に onMouseUp を使用

この変更により、メニューを開くイベントと MenuItem のクリックイベントが異なるタイミングで発火するため、イベント処理が正しく実行されます。

upstream (scratch-gui) の問題

upstream の scratch-gui では、この問題が未修正のままです。そのため、メニュー項目をクリックしても、他の場所をクリックするか明示的な操作をしなければメニューが閉じられません。

影響範囲

この問題は以下のメニューに影響します：

• File メニュー: すべてのメニュー項目
• Edit メニュー: すべてのメニュー項目
• その他のドロップダウンメニュー: Mode、About、Account など

参考情報

比較対象のファイルパス

• smalruby3-gui: gui/smalruby3-gui/src/components/menu-bar/menu-bar.jsx
• smalruby3-editor: gui/smalruby3-editor/packages/scratch-gui/src/components/menu-bar/menu-bar.jsx

関連コード箇所

• メニューコンテナ: src/containers/menu.jsx:27-36
• MenuItem コンポーネント: src/components/menu/menu.jsx:62-86
• MenuItem コンテナ: src/containers/menu-item.jsx:7-33

解決策

smalruby3-gui の実装に合わせて、メニューを開くイベントハンドラを onClick から onMouseUp に変更する必要があります。

具体的には、menu-bar.jsx の以下の箇所を修正：

1. File メニュー: onClick={this.props.onClickFile} → onMouseUp={this.props.onClickFile}
2. Edit メニュー: onClick={this.props.onClickEdit} → onMouseUp={this.props.onClickEdit}
3. その他のメニュー: 同様の修正

この修正により、smalruby3-editor でも smalruby3-gui と同じ動作が実現できます。