Fix typo in theia-ide github hyperlink at TheiaIDEHeader.js

[dannaf]

I believe this mistakenly links to Theia's github page rather than Theia-IDE's/Blueprint's, which is what this hyperlink is referring to.

[JonasHelming]

Thank you for the PR. we actually discussed this. The Theia IDE /blueprint repository is really just a distribution. Discussions, development, and bug reports are all happening i the Theia repository. Therefore, we decided to link this repo here. Does this make sense to you? I know it is a bit confusing...

[dannaf]

Thank you for your response. That makes sense to me in that I think I understand what you are saying, and I can see how you could have seen it that way. But it does not make sense to me in that I disagree with it, for the following reasons:

Theia IDE/Blueprint "also serves as a template for building desktop-based products based on the Eclipse Theia platform", and in so far as it is meant to be a "template" of code, its code should be easily discoverable by a new user/developer for that purpose as a template of sample code. And this should be done most straightforwardly via the 'View on GitHub' button at https://theia-ide.org/#theiaide at the "The Eclipse Theia IDE [Beta]" portion of the page, half way down. Note also that way above at the top of the page there is a different heading of "The Eclipse Theia Platform" and there is a already a separate "Github" link near there (at the top left of the page next to the word "Theia") that points to https://github.com/eclipse-theia/theia; this link is properly pointing to what it is talking about (the Eclipse Theia Platform's github page), whereas the github link half way down is then redundant if it is also again pointing to the Eclipse Theia Platform's github page, and simultaneously it is failing at its purported claim of pointing to the code of the Eclipse Theia IDE/Blueprint.

Without a link to https://github.com/eclipse-theia/theia-blueprint there, at the "View on GitHub" button near the "Eclipse Theia IDE" heading, the code for Theia IDE/Blueprint is not so easily discoverable. One would basically need to already know about the deprecated 'theia-ide' at https://github.com/theia-ide/theia-apps and follow the developments from there to understand that there is a new Theia Blueprint that has then been rebranded to Theia IDE. While it is useful that this info is available online at the theia-apps github readme, it should not be necessary for a new user to dig into those past deprecated details just to discover the current Theia IDE/Blueprint. (And a new developer would be unlikely to wind up on the theia-apps github page. I wound up there looking for a past docker image I previously used, which has been unpublished.)

Moreover, even if one goes through the Theia documentation at https://theia-ide.org/docs/ sequentially, from the beginning, one does not discover the code for Theia IDE/Blueprint successfully. The closest the new developer comes to this is when he or she reaches the page https://theia-ide.org/docs/blueprint_download/, where he or she is redirected to https://theia-ide.org/#theiaide, which is where the allegedly defective "View on GitHub" link that is the subject of this PR is located.

So basically a new developer needs to go to the https://github.com/eclipse-theia account page to see what repositories are available there in search of sample code. That's what I eventually did and that's when I finally found clearly the https://github.com/eclipse-theia/theia-blueprint repository, and I finally understood this circle that I was running around in where I saw mentions of Theia IDE/Blueprint but I was returned to the Theia Platform's github page. And the culprit is the promising-looking-but-deceptive "View on GitHub" link for Theia IDE/Blueprint at https://theia-ide.org/#theiaide that does not actually take the new developer to the github page of Theia IDE/Blueprint.

Long story short, a new developer sees numerous mysterious mentions of Theia IDE/Blueprint but fails to easily discover tangible, actual sample code for it. Even worse, the new developer might be confused as to the existence of IDE/Blueprint and regarding what it is and if the sample code template is even available. (This is bad enough on its own, and given the remnant confusion of the Blueprint/IDE rebranding that's yet one more reason to seek to avoid any further confusion as much as possible.) The hyperlink as-is is both redundant and confusing, and it would be neither and instead extremely helpful to a new developer if it would be updated to point to the Theia IDE/Blueprint's github page at https://github.com/eclipse-theia/theia-blueprint.

What do you think?

[JonasHelming]

First of all I think that people like you are the reason, why I enjoy working on open source projects! :-)
Thank you so much for your detailed research, you are absolutely right with your observations and we should fix this.

I am still not fully convinced that changing the link in the Theia IDE header is the best way. Why you are 100% correct with your observation that the Theia IDE repo is not findable at the moment, I still believe we would like the majority of users to navigate to the main Theia repo instead. The use cases are:

• Report a bug
• Ask a question
• Check-out the project in terms of activity
  For all these use cases, we want them at the main repo. Still, we want that interested people find the source of the Theia IDE repo.

How do you like the following ideas (or a combination of these)

• Link the Theia IDE repo under https://theia-ide.org/docs/blueprint_documentation/ and link this webpage under Extensible and Open on https://theia-ide.org/#theiaide
• Add a section to https://theia-ide.org/#theiaide "Sources" explaining the two repos with links
• Add a section to https://theia-ide.org/#theiaide "Theia IDE vy Theia Platform" explaining the two things with links to the repos
• Links the Theia IDE repo in the readme of the Theia repo

One other option would be to add two "...on Github" buttons in the header or even have a drop down, but I find these options rather confusing.

I am if this feels over complicated to you, I am not fully opposed to also just accept your change. I am trying to channel the majority of users to were they probably should be headed when clicking the link. I hope this makes sense to you?

[dannaf]

Thank you for the kind words. The feeling is mutual; thanks for your dedicated work on this important product. Glad to continue the discussion together now, sorry for the delay. And sorry for the very lengthy message below --- hopefully it makes sense to you and is not overwhelming.

On second thought after my original comment on this PR, I might already agree with your original concept that Theia IDE/Blueprint is really just a distribution and that basically all discussions/developments/bug-reports/etc. should be happening in the Theia repository if and only if we take it a step further all the way and let's just say that Theia IDE/Blueprint is completely redundant, and should not be its own repository whatsoever. What do you think of this as a possibility? This is motivated by my first look inside and seeing that https://github.com/eclipse-theia/theia/blob/master/examples/browser/package.json and https://github.com/eclipse-theia/theia-blueprint/blob/master/applications/browser/package.json appear to me to be extremely similar, to the point that I question the Theia IDE/Blueprint package.json and the entire Theia IDE/Blueprint 'distribution' as potentially redundant. (Please correct me where I am wrong, as I am not at all familiar with all the details of these package.json files or the Theia and Theia-IDE architectures.) I wonder if this present issue of the hyperlink is really just a symptom of a broader issue by which Theia IDE/Blueprint should be closed out and formally merged into the browser/desktop example(s) within Theia, and the Theia IDE/Blueprint repo would then be archived as read-only and indicated as such in a manner similar to the closeout of https://github.com/theia-ide/theia-apps with issue #496 there.

(Such a closeout would also simultaneously once-and-for-all resolve permanently the more minor issue of the persisting Theia IDE/Blueprint rebranding confusion: while I can see that the Theia development team is certainly up to date on the Theia IDE name, to a new developer the issue still arises at least by the repository name at https://github.com/eclipse-theia/theia-blueprint, and this further mingles with the present confusion on what the role of Theia IDE/Blueprint is, as a blueprint/distribution/etc. and whether it truly requires its own repository to be such.)

So I am basically suggesting now that the 'View on GitHub' button at the Theia IDE/Blueprint 'header'/portion of the Theia homepage at https://theia-ide.org/#theiaide should be updated to point to the package.json file within the Theia repository (or, more properly, to a nested README.md or other instructions file that should be added within the browser example folder in the Theia repository, or to that folder itself on GitHub where the README.md would show automatically, which would explain how to use the browser example in lieu of the separate-repository Theia IDE/Blueprint 'distribution'). I suggest that this may resolve the issue here, where you think the hyperlink should point to the Theia repository and I suggested it should point to the Theia IDE/Blueprint repository: a merge-and-closeout of Theia IDE/Blueprint into Theia, along with an update to the 'View on GitHub' button to an instruction file within Theia, at the browser example folder (or at the examples folder, perhaps, more broadly), accomplishes the best of both worlds, I suggest, as the hyperlink is still to the Theia repository for the reasons you mentioned, that all discussions, development, and issues should be located there, yet simultaneously this will fix the issue that I raised by which the website hyperlink that purports to point to Theia IDE/Blueprint does not actually do so when it currently points to the Theia repository instead of the Theia IDE/Blueprint repository.

---

Towards this end what I suggest currently is that this discussion --- which I've now suggested we upgrade to deal with the broader architectural question of Theia IDE/Blueprint's necessity as its own repository, and which should thus be taken up more thoroughly --- should be organized into a new 'issue' (or 'discussion', per se, as you prefer), and that the present PR should be resolved with a resolution that is understood to be potentially temporary until the conclusion of the broader Theia IDE/Blueprint as-its-own-repository question. In this meanwhile I would still close out this PR by merging it, because I think it is simply nonsensical for the link to talk about Theia IDE/Blueprint and purport to link to the GitHub page of it and then not link to the GitHub page of it. (When such a GitHub page/repository exists. And if a decision will be reached to close out such a GitHub repository altogether, as suggested above, then at that point in time it will make sense to update this hyperlink to the new location within the Theia repository, in my opinion.) So I suggest specifically that this PR be merged and a new issue be opened to decide on whether to keep the Theia IDE/Blueprint repository, that issue having the intended endpoints of either reaching the decision to keep it, resulting in merely closing the issue, or reaching the decision to closeout the repo, resulting in closing the issue to be replaced by a new separate issue calling for the implementation of that closeout.

In summary:

I think the 'root cause' of the internal struggle of not being fully convinced that changing the link on the Theia webpage (at the Theia IDE/Blueprint 'header'/portion) to the Theia IDE/Blueprint repository, while simultaneously agreeing that the Theia IDE/Blueprint is not properly findable currently without that hyperlink pointing there, is due to the confusing redundancy by which there are two repositories where there should just be one, as I discussed above. As you note, the main intention with regards to Theia IDE/Blueprint is that "we want that interested people find the source of the Theia IDE[/Blueprint] repo", so that people will be able to easily get started with understanding Theia and launching it as a distribution --- but this I suggest can be done by including that source code clearly within the Theia repository, in the examples folder, and including improved instructions on how to use the examples (such as by basically incorporating the README.md of the Theia IDE/Blueprint repo into the examples folder of the main Theia repository, and updating/improving it). Basically, I think the examples folder of the main Theia repository is not easy enough for a new developer to understand --- at least for me it isn't --- whereas in my view what the separate Theia IDE/Blueprint repository accomplishes is merely to more thoroughly and completely and understandably demonstrate the use of the examples. (Please correct me if I am wrong, as I have not studied thoroughly the code in Theia IDE/Blueprint --- see next paragraph.)

To elaborate further on this a bit let me note my own personal experience here and mention that part of the reason that I did not previously go and look at the https://github.com/eclipse-theia/theia/blob/master/examples/browser/package.json, i.e. the package.json file in the Theia repository, was perhaps because I saw the mentions of Theia IDE/Blueprint and I understood from this that there is no need for me to delve inside the Theia repository but only to utilize the Theia IDE/Blueprint repository (which was evasive due to the present hyperlinking issue --- I did actually access it at one point and then I 'lost' it and struggled to get back to it, which was part of how I eventually figured out the hyperlink-circle that I was running around in, because I had that 'I know I saw it somewhere...!' feeling to keep me undeterred from finding it again, but it just wasted some time and effort and caused needless confusion in my opinion). Particularly, my use case was really just to try to quickly get up-and-running with the sample, out-of-the-box Theia 'IDE' for use more than for development. (And as a related point this would have been easier if there had still been an already-built-and-published docker image on Docker Hub, like there previously was during the theia-apps days. I did not understand an explanation from issue #496 there of why the images were removed from Docker Hub and not replaced with updated images, and I would suggest that as part of addressing the present question regarding Theia IDE/Blueprint's possible redundancy the question of publishing Docker Hub images should be taken up again: I suggest that Eclipse-Theia should maintain at least one published docker image on Docker Hub, as this would make getting started for developers easier and also potentially make using for users who only wish to use the out-of-the-box Theia 'IDE' via the browser complete, or at least almost complete [could be completed by adding an example setup for securely serving], and in that way publishing a Docker Hub image would largely contribute to the goals of Theia IDE/Blueprint as a "distribution", as is the topic of the present discussion.)

So in final summary, with regards to the specific ideas you mentioned of different ways of inter-linking and explaining the two repositories, I am suggesting the new approach of eliminating the two repositories and keeping only one: the main Theia repo, which should be be improved with regards to the examples code and explanations to basically accomplish there what the team has attempted to accomplish in the Theia IDE/Blueprint repository. (And I would suggest also improving this meanwhile, at least with the addition of a Docker Hub image and updated instructions, and also with an example of how to quickly-and-easily securely serve the out-of-the-box Theia example(s).)

Bonus appendix: I would even perhaps go as far as to suggest that the secondary, indirect project goal of supporting end-users should be upgraded slightly, albeit not too much, to formally see it as one of the primary, direct project goals to provide a working, supported, demonstrated and easy-to-get-started-with end-to-end sample/example 'out-of-the-box' browser-based IDE (which includes securely serving via internet access). But again, I would offload these discussions into separate, new GitHub issues for us to continue in, for organization's sake and to discuss it thoroughly. Note that I would still retain supporting end-users of a desktop IDE as a mere secondary, indirect project goal, because for that there is already VSCode and such, so that users who come to Theia in order to use a desktop IDE can fairly be presumed to do so for the purpose of being able to modify the desktop IDE, as developers. Whereas there are today I believe many users who want to use a good browser based IDE, either locally or also to a large extent via the internet (and securely so), for which Theia fits the bill, and as such I suggest that Theia should formally and directly support a usable browser example as a project goal. (And arguably this is what Eclipse Theia aimed to do with the Theia IDE/Blueprint repository, but this presumably was kept separate because it was seen as a "secondary, indirect project goal". I propose that it should be both upgraded to a primary, direct project goal and with that merged into the main Theia repository.) And although there are more and more browser based IDEs available, many of which are even being developed with Theia, those seem to be generally part of some particular third-party service through which they are offered, and I still see it as an important role for Eclipse Theia to support a simple, usable out-of-the-box browser IDE for users who do not wish to also use the third-party services that may be providing their own browser-based IDEs. Anything beyond such basic support of a single, usable browser-based IDE I would agree may be out of the scope of the Theia project, as users are free to develop their own modifications and extensions beyond the basic browser-based IDE, or to use third-party services that are more and more now providing browser-based IDE access.

[JonasHelming]

Thank you for your valuable thoughts!

A few comments

Example apps in the Theia repo vs. the Theia IDE
While they look very similar, they serve a very differen purpose. The Theia IDE is a product (including installers) that adopts Theia as a platform. The example apps in the Theia repo are meant to developing on the Theia platform. As an example, the Theia example contain literally everything that the platform provides, while the Theia IDE does a selection. Also, the Theia IDE has a different release cycle than the Theia main repo. So, while similar, they are not really redundant. Specifically the different release cycles justify a separate repository.

Docker Container for Theia IDE
Yes, I agree, we should provid this, would you mind opening an issue for this and tag me!

Blueprint vs Theia IDE
This is really a left over, we rebranded Blueprint to Theia IDE and all remaining references will be gone over time, including the repo name.

About the other points, I would like to discuss this with the Theia community in the Theia Dev Call. I added it to the agenda for next week, please feel free to join if you find the time!.

[dannaf]

Thank you again for your response, and for the invitation to the Dev Call. I'll try to be there to join the discussion.

I'm looking forward to learning more about the differences and similarities between Theia IDE and the Theia examples. But from the information so far I am still not convinced that there isn't some redundancy. Developing with Theia is ultimately for the purpose of deploying a product (whether for the individual developer alone or for multiple users), so it seems to me that the source code of Theia IDE is indeed a good 'example' per se of developing with Theia. Perhaps the distinction again is that Theia IDE as a product (e.g., as an out-of-the-box usable DockerHub image [especially with a secure serving setup/tutorial]) is an example per se of using Theia, whereas the source code of Theia IDE is an example of developing Theia (and it may be a minimal such example, whereas it sounds like the current examples in the Theia repo are maximal examples, like what used to be the theia-full docker image). Then, I think this actually further highlights the idea that the source code of Theia IDE should be moved into the Theia examples folder in the Theia repository (perhaps calling it theia-minimal and renaming the current example to theia-full, or something like that), and the use/usability of Theia IDE/theia-minimal should be officially supported as part of Theia. (Whereas regarding theia-full it could be maintained that this is strictly an example to support development and is not supported as a standalone product for use. [Although I'd be interested to hear some thoughts on this, because shouldn't any of the features included in the current example/theia-full for developing with also maintain a basic supported usability?])

Moreover, I don't think I agree with the general concept that the separate release cycle justifies their separate existence. It seems backwards to me, like having the tail wag the dog. Rather, if they should be united then the release cycle should be changed accordingly.

[dannaf]

As for the remnant Blueprint repo name eventually becoming gone over time, it is not clear to me how or when that is expectsd to happen. It will not happen by itself. At some point in time the repo name will need to be explicitly changed in order to perfect the rebranding, and the longer the wait until that happens the greater the confusion will be, in my opinion. (It might be a small confusion, but it is wholly unnecessary, and it will grow with time as the current repo name/url remains in use.) So I still suggest that merging Theia IDE into Theia, within the examples folder, is the natural action to take that will along-the-way resolve finally the remnant Blueprint repo name issue.

(And by the way, is there a formally open issue for this? There should be since it will not happen on its own, it will need to be actively done at some point.)

[JonasHelming]

Added links to the Theia IDE source repo: #530

[JonasHelming]

Add links in Theia main repo: https://github.com/eclipse-theia/theia/pull/13534/files

[dannaf]

@JonasHelming thanks for addressing some of this issue.

I think the core issue here is still open, however. Which, to review, began as what I thought initially was a simple typo in the github hyperlink on the website at the Theia IDE header, but it turned out from our discussion that it is actually about the bigger question of what Theia IDE is and where it should be (e.g. its own repo) and how it should be maintained, etc. (e.g. have its own issues in the Theia IDE repo or should all issues be in the Theia platform repo, and whether it should be officially supported to serve end users).

At the end of my second last comment above I suggested that

the secondary, indirect project goal of supporting end-users should be upgraded slightly, albeit not too much, to formally see it as one of the primary, direct project goals to provide a working, supported, demonstrated and easy-to-get-started-with end-to-end sample/example 'out-of-the-box' browser-based IDE

I still stand by this suggestion, and to try to move discussion forward on this and make some progress I meanwhile opened eclipse-theia/theia-ide#347, where I suggested the language that Theia IDE should be understand as a 'minimum viable product' for use, in addition to serving as a 'template' for development.

---

So with that position I am still challenging your new language here that you added/emphasized in #530 that "the Eclipse Theia IDE is [only/primarily] an example product used as a reference on how to build desktop IDE-like products based on the Eclipse Theia framework" (emphasis added). It should be, in my opinion, a reference/template and a usable product.

I do agree though with your addition of the instruction that "If you just want to use the Theia IDE, see the user guide". And, indeed, this further makes my point that Theia IDE essentially already is — de facto — a product that Eclipse Theia does (and should) maintain for use, so that new users "[who] just want to use the Theia IDE, [can] see the user guide" and get started out-of-the-box.

Similarly I am challenging your language there of the Docker building of Theia IDE as "experimental": I claim that a reliable, working build instruction for the Theia IDE should be officially supported by Eclipse Theia. (And incidentally this is not currently the case: eclipse-theia/theia-ide#345.)

[dannaf]

As for the question of whether issues regarding Theia IDE should be opened in the main repository. I still think this makes no sense, and this was further made clear to me by the experience tonight of opening eclipse-theia/theia-ide#345, which points to an issue in the current docker building of Theia IDE. I was initially going to post this issue on the main Theia platform repository like we previously discussed above — and as is arguably stated here (although that simply says "Theia") — but that just felt so non-sensical, as that bug is specific to Theia IDE and should clearly be in the Theia IDE repo. So it was pretty clear to me that the issue should be in the Theia IDE repo, so that's what I did. But that seems to be contrary to what you instructed me to do; so I am bringing this topic up for discussion again.

[dannaf]

I suggest perhaps that yet another way of seeing this topic is perhaps by looking at Theia IDE as a 'product test' of Theia platform, to some extent, in addition to its purposes of serving users and supporting developers. Meaning that the core functionalities of the Theia platform, as implemented in the main repo, are essentially tested by their functionality in Theia IDE, as an overall product/integration test in addition to any unit tests in the main Theia platform repo (and in addition to any feedback from developers that build off of the Theia platform). This may shed some light on our discussion of where to include Theia IDE: in its own repo? in the main Theia platform repo within the examples folder? Or, let me suggest now, perhaps some 'higher-level' product/integration tests/examples from the Theia platform repo's examples folder should be moved out to the Theia IDE repo? Something to consider. At least with the core functionalities I think this makes sense for them to be in the Theia IDE repo, and perhaps each of the Theia platform's features should have a similar implementation in Theia IDE as a sort of 'top-level' feature/product/integration tests.

I am not saying necessarily that Theia IDE in this way should have all combinations and permutations of features, like the previous theia-apps repo. Rather, I am suggesting that perhaps the Theia IDE should have just two arrangements: a 'minimal' application (like what is currently thought of as Theia IDE) and a 'maximal' application (like the previous theia-full in theia-apps). This would be the official scope for the formal support by Eclipse Theia for Theia IDE that I suggest (and this indirectly supports the Theia platform, via the 'testing' aspects of it), and all combinations in between would be on individual users to develop using the versatile Theia platform. What do you think?

---

This 'integration testing' concept is also demonstrated by the example of issue eclipse-theia/theia-ide#345, which I sought to resolve via https://github.com/eclipse-theia/theia-blueprint/pulls/346 by proposing an upgrade to the node version (at least in the docker base image). This is seemingly a fix for a Theia IDE build issue, but it gets into an important question for the Theia platform: which version of node is supported by Theia? The package.json in the Theia platform says here that node>=16 is required, but the 'integration test' so-to-speak of packaging the core essentials into Theia IDE revealed that the yarn command failed, in a standardized/reproducible docker build environment, when using the node:16-bullseye docker image.

[JonasHelming]

I still stand by this suggestion, and to try to move discussion forward on this and make some progress I meanwhile opened eclipse-theia/theia-blueprint#347, where I suggested the language that Theia IDE should be understand as a 'minimum viable product' for use, in addition to serving as a 'template' for development.

Thank you, I just reviewed this PR

So with that position I am still challenging your new language here that you added/emphasized in #530 that "the Eclipse Theia IDE is [only/primarily] an example product used as a reference on how to build desktop IDE-like products based on the Eclipse Theia framework" (emphasis added). It should be, in my opinion, a reference/template and a usable product.

I do agree though with your addition of the instruction that "If you just want to use the Theia IDE, see the user guide". And, indeed, this further makes my point that Theia IDE essentially already is — de facto — a product that Eclipse Theia does (and should) maintain for use, so that new users "[who] just want to use the Theia IDE, [can] see the user guide" and get started out-of-the-box.

Hmm, the full sentence is "In this scenario, the Eclipse Theia IDE is an example product used as a reference on how to build desktop IDE-like products based on the Eclipse Theia framework. If you just want to use the Theia IDE, see the user guide". And this is on the page "Extending/Adopting the Theia IDE". I believe putting less emphasis on the role of beeing an example in this scenatio would confuse in the oposite direction tbh. If you do not feel like this, please feel free to make a suggestion (preferably as a PR) on how to change the wording over there.

Similarly I am challenging your language there of the Docker building of Theia IDE as "experimental": I claim that a reliable, working build instruction for the Theia IDE should be officially supported by Eclipse Theia. (And incidentally this is not currently the case: eclipse-theia/theia-blueprint#345.)

This is an explicit decision by the core Theia team and has something to do with resources and focus. For the Theia IDE desktop, we have a preview testing process with a good number of testers. We currently do not have this for the Docker variant. If somebody steps up and establishes a corresponding testing and release process, we are happy to remove the "experimental". In reality, we should find 99.9% of issues for a new release in the desktop variant, too. However, we do not want to release something to the public that nobody at least "smoke tests" without marking it as experimental.

[JonasHelming]

I suggest perhaps that yet another way of seeing this topic is perhaps by looking at Theia IDE as a 'product test' of Theia platform, to some extent, in addition to its purposes of serving users and supporting developers. Meaning that the core functionalities of the Theia platform, as implemented in the main repo, are essentially tested by their functionality in Theia IDE, as an overall product/integration test in addition to any unit tests in the main Theia platform repo (and in addition to any feedback from developers that build off of the Theia platform). This may shed some light on our discussion of where to include Theia IDE: in its own repo? in the main Theia platform repo within the examples folder? Or, let me suggest now, perhaps some 'higher-level' product/integration tests/examples from the Theia platform repo's examples folder should be moved out to the Theia IDE repo? Something to consider. At least with the core functionalities I think this makes sense for them to be in the Theia IDE repo, and perhaps each of the Theia platform's features should have a similar implementation in Theia IDE as a sort of 'top-level' feature/product/integration tests.

I am not saying necessarily that Theia IDE in this way should have all combinations and permutations of features, like the previous theia-apps repo. Rather, I am suggesting that perhaps the Theia IDE should have just two arrangements: a 'minimal' application (like what is currently thought of as Theia IDE) and a 'maximal' application (like the previous theia-full in theia-apps). This would be the official scope for the formal support by Eclipse Theia for Theia IDE that I suggest (and this indirectly supports the Theia platform, via the 'testing' aspects of it), and all combinations in between would be on individual users to develop using the versatile Theia platform. What do you think?

This 'integration testing' concept is also demonstrated by the example of issue eclipse-theia/theia-blueprint#345, which I sought to resolve via https://github.com/eclipse-theia/theia-blueprint/pulls/346 by proposing an upgrade to the node version (at least in the docker base image). This is seemingly a fix for a Theia IDE build issue, but it gets into an important question for the Theia platform: which version of node is supported by Theia? The package.json in the Theia platform says here that node>=16 is required, but the 'integration test' so-to-speak of packaging the core essentials into Theia IDE revealed that the yarn command failed, in a standardized/reproducible docker build environment, when using the node:16-bullseye docker image.

Yes, the Theia IDE is a "product test" of the "Theia Platform". The Theia application in the example folders is the "max" configuration, the Theia IDE is a "sensible" configuration that we deploy and test with real users.
We cannot move the full example out of the Theia repo, it is commonly used for developing on the Theia platform. Still, it is an example, as it is very unlikly that somebody uses this "max" configuration. The Theia IDE on the other hand is composed to make sense as a product for end users. It is really about packaging and providing a specific product based on the platform. Separating the product from the platform code is a very common pattern IMHO.