Obstacles for Dog-Fooding Theia Development

[tsmaeder]

Feature Description:

In a recent community meeting, I've proposed that Theia contributors use Theia itself for developing Theia. Personally, I have a number of issues that keep me from doing that. This Issue serves to collect the obstacles (technical and otherwise) to adopting Theia as a dev platform

[tsmaeder]

I'll go first: here's what's not working for me:

1. Debugging the electron back end from the launch config is broken
2. When debugging a vs code extension via the "extensionHost" launch config type, web views don't seem to work in the debuggee.
3. When using Blueprint, I can't have two versions of blueprint installed. This precludes things like having a "stable" version for development and a "under development" version where I can try things.

[colin-grant-work]

Here's what comes to mind for me. I'm going to include things that have recently been resolved to give more a flavor of what sorts of things might fit in each category. Thomas' list is more about specific technical things that make it difficult to use Theia when developing Theia; mine is more about things that I mostly know how to work around that nevertheless make it difficult to want to use Theia for Theia development (or otherwise).

1. Odd disruptive bugs / poor performance - these are the biggest blockers
   • Multiple DebugEditorModels for same URI lead to stack overflow #11878
   • Loading large files can hang things for quite a while
   • Processing large RPC messages can hang the UI if resources are tight (e.g. in a large repository with many untracked files, processing messages from @theia/git's backend)
   • Bad handling of multiple Electron instances (state restoration, themes broken in additional instances)
   • Vulnerability to breaking in response to slightly-bad inputs (Unresponsive Page When duplicate workspace url in theia-workspace file #12155)
   • Plugin friction
     • RedHat XML vscode extension stopped working from the latest Theia releases #12129
     • Mismatching normalized URI in plugin system #11179
2. Missing conveniences
   • Ability to open a file in the current instance from an internal terminal using something like $ theia my-file
   • Ability to control whether additional instances of files get opened in response to e.g. 'Goto Definition' (Implement workbench.editor.revealIfOpen preference #12145)
   • Automatic cleanup of editors on same tabbar (Close duplicate editors on same tabbar #12147)
3. Messy console / indiscriminate logging
   • The practical part: it's hard to sort through all the output for interesting bits related to current work.
   • The more rational part: we get a lot of console errors and warnings under various conditions, some benign, some that probably do indicate real problems, even if the application still runs.
   • The less rational part: there's just a lot of logging, and knowing it's there - as a Theia developer - makes it feel untidy.

There are likely additional subpoints for the first two categories, and I'll add them if they occur to me.

[emilhammarstedtst]

Its been a while since i tried this, so I created a PR, #12166 to be able to actually give a response to this Question, while hopefully contributing some improvements.

I Used Theia blueprint 1.32

I have come across some issues, in no particular order:

• Logging/output to the terminal you started theia from makes that terminal unusable.
• "slow start", hard to pinpoint what, but might be my computer?
• "Unpolished" UI
• Huge git repos created performance issues with git-integration. halted application at one point.
• Rust support is clunky.

In my own conclusion I haven't really found a show stoppers or issues warranting not "dog-fooding" all(most) of my time yet. As i was able to complete all my work using Theia as it stands currently, that is not to say everything is perfect, but i got my work done about as fast as I usually do.

I´ll amend this list as(if) more appear.

[tsmaeder]

Closing in favor of #12693 for taking concrete steps.