CI & Authoring: Make a Determination Between WebIDE and Editor Lite
Topic to Evaluate
The Problem
We have a handful of issues that rest on moving or creating gitlab-ci.yml
interactions into the Web IDE as the preferred interaction location.
For instance:
- #232779 (closed)
- #215575
- #15622 (closed) (first iteration #241722 (closed))
There are some technical and organizational factors that may make the Editor Lite a better interactions driver. The purpose of this issue is for us to make the determination about which direction we want to take, so we can work on these issues.
What is the difference between WebIDE and Editor Lite?
The WebIDE and the Editor Lite are the two main file-editing experiences in our product. The former is the experience trigged with the WebIDE button on files and is a web-based version of an IDE and comprises editing, file browsing, and source code process interactions (committing, etc.).
The latter is the lighter experience that is activated when clicking the Edit button from a file blob. It shows a single file, which can also be committed from the form / generate a new branch and new MR, etc. It can show multiple instances on a page and is architected to be able to use a series of extensions, of which our interaction plugins would be be part.
Both are based on the Monaco editor, which is the kernel to VSCode, and can be extended with all sorts of plugins. EditorLite is a very slim wrapper around this basic functionality, while the WebIDE is a fairly complected and monolithic implementation.
There is a third, older editor, the Ace-based single-file editor. This has been phased out in all locations except the CI Linting page.
More data about the discoverability of the editors and the cases in which they are used can be found in a blog post on Gitlab Unfiltered.
Risks and Implementation Considerations
In the case of using the Web IDE, the two main risks are:
- Limitations on our desired interactions based on performance concerns, since the Web IDE is a chonky boi
- Limitations on iteration speed, since we do not own this slice of the product and therefore need to be sure we are collaborating
In the case of using Editor Lite, either through the single-file Edit button we have now and/or within a new a authoring area, the main risks are:
- Whether it will be discoverable
- Possibly needing to create a way to edit multiple included CI files in instances of Editor Lite, similar to a multiple snippet page, whereas multi-file editing is "free" with the Web IDE
Recommendation
My recommendation, made in concert with discussions with the ~"group::editor" team, is that we focus on using Editor Lite, possibly in concert with creating a pipeline authoring area that can host multiple instances of the Editor to address the multi-file shortcoming.
This will give us flexibility and the ability to suck up all the computer cycles for our own ends. Mwahahahaha.