EditorUIをElectron非依存状態でも動かせるようにする

[yamachu]

内容

#1042
で nodeIntegration を使用しない状態のUIが実現された。

Electronが担っている機能としてはFile I/Oだったり設定のmigrationなど、UIの動作には直接寄与しないものが多い。
File I/Oなどの機能はMockで再現可能ではあるため、テストレベルであればElectronを使用しなくても動作するはずである。

将来的にWeb版を展開することにも繋げられるため、Electronに依存しないUIを実現したい。

Pros 良くなる点

• Webアプリケーションのテストをするのと同じような形になる
• 様々な条件のテストの状態が作りやすくなる（はず
  • electronのipc周りのMockやエンジンとの通信のMockなどで
• ビルドツールの変更が容易に(to Viteなど)
• パッケージの更新なども容易に

Cons 悪くなる点

• ないはず
• 実現方法のPh2? に記載したworkspaceの分離などを行うと、今出ているPR全てとコンフリクトする

実現方法

段階的に進めることになりそう

Ph1

• type ディレクトリ以下の整理
  • UIからも読み込む型のファイルからElectron(Node)に関する型やimportを互換性のあるものに変更
  • UIのみに依存するファイルか、Electron側とやり取りするために必要な型のファイルであるかの分別
• UIに関するファイルから node に関するモジュールのimportやオブジェクトへのアクセスの削除
  • ref: nodeIntegrationを無効にする＆sandbox=trueにする #1017
  • ref: EditorHome.vueとpreload.tsで使われているfs、pathモジュールをメインに移してnodeitegrationをfalseに #1042
  • 上記Issueで触れられている path モジュールや process オブジェクトに対するアクセスを、互換ライブラリの仕様や、DefinePluginでビルド時に埋め込む
  • 今はVue CLI v4が依存しているwebpackがpath-browserifyをpolyfillとして入れてくれているので動いているが、Vue CLI v5にするとwebpack v5になり明示的にpolyfillを入れないと動作しなくなる（はず）なのでやりたい

Ph2?

• preload.ts の Sandbox をbrowser環境で動作する形で実装
  • 最新のChromeで実現できるものは多そう
  • この時点でElectron非依存のテストなどが可能になる
• ディレクトリの分離やworkspaceの分離(別Issueっぽいけど…)
  • Electron依存のライブラリであるのか、UIのためのライブラリなのかがpackage.jsonが分かれていることによってわかりやすくなるため、ライブラリのアプデの影響範囲が調査しやすくなり、セキュリティアップデートや機能追加のためのアプデが容易になる

VOICEVOXのバージョン

0.?.0

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

https://github.com/yamachu/voicevox/tree/project-structure-cleaning
で実験中

[Hiroshiba]

issue作成ありがとうございます！！夢があって良い･･･！！

最終ゴールを「web UIで動くこと」にして、やりたいこととタスクの重要度を設定しておくと迷子になりづらそうに思いました！
例えばpackage.jsonの分離やディレクトリ分離などは、webUIで動くことには必須じゃなさそう、みたいな。

[sevenc-nanashi]

add/electron-mock（比較） でwindow.electronのモックを作ってみました。（自分のフォークにpushしようとしてミスってしまった）

• src/electron/mock.ts にほとんど詰まっています。
• テーマを読み込むのに vite.config.ts のdefineを使っています。
• onReceivedIPCMsgのモックとしてwindowのmessageイベントを使用しています。IpcRendererを返せなくなりますが、どこでも使われていなかったので多分大丈夫？

[yamachu]

Mockの流し方の最初のたたき台として良さそうに思えます！
テストとかの時はその辺り使ってUIテストとかできそうですね

onReceivedIPCMsgに関しては私もここは void にして対応していたので、いいんじゃないかなぁと思っています

sevenc-nanashi さんの実装と前試したやつを元に自分ももうちょい考えてみました
frontend-compat

background.ts で担っている File I/O 周りだったり localStorage をWorkerに流せるようにしてみています。
mockだったり実装は main.ts 側からは意識しない形（ファイル内にもimportとかがない状態）にするのはどうかなと思いまして。
Workerでローカルディレクトリを読んで実際のファイルを使用しながら、APIの向き先はEngineに向ける、みたいのが容易に出来るかなと…！