The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Content last reviewed on 2022-12-02
This is the direction page for the Editor group which is part of the Create stage of the DevOps lifecycle and is responsible for the following categories:
Category | Direction | Description | Maturity |
---|---|---|---|
Web IDE | Direction page | A web-based multi-file code editor | Viable |
Remote Development | Direction page | Server-side runtime environments | Planned |
Wiki | Direction page | Built-in, git-backed knowledge base | Viable |
Pages | Direction page | Deploy and host static sites | Complete |
In support of these categories, the Editor group created and maintains two core editing components. These editors are intended to be flexible, extensible, and reusable across GitLab and while they don't meet the traditional definition of a category, they do have distinct strategies and backlogs. They are:
Component | Direction | Description | Strategy epic |
---|---|---|---|
Source Editor | Direction page | Our underlying code editor |
Epic |
Content Editor | Direction page | A visual Markdown editor | Epic |
With 4 categories and 2 foundational editor components, the Editor group has to prioritize aggressively. In general, the group's goals revolve around consolidation and standardization of editing experiences to improve consistency and maintainability. Our current focus areas and engineering investment are broken down by category below, percentages represent how much engineering time on average is allocated in each milestone.
The Web IDE is a very capable multi-file editor, offering a streamlined way to contribute to projects without cloning a repository or reconfiguring your local development environment. There are features, however, that don't meet a developer's expectations when it comes to making more complex edits. We are in the process of building the next iteration of the Web IDE, based on the open-source VS Code project and running entirely in the browser. This will not only bring a more robust, mature feature set to the Web IDE, but it will lay a strong foundation for our Remote Development category.
The Web IDE makes it possible for anyone to contribute to a project right from their web browser. Editing the actual code, however, is only a small part of a developer's workflow. Local IDEs, combined with properly-configured development environments, make it possible to run tests, lint code, generate previews, and offer features that improve developer efficiency like code completion. Without these features, developers can't fully adopt a tool. Remote Development is an early stage category that aims to provide a server-based runtime environment that can be accessed from the Web IDE or your local IDE, eliminating the need for managing a complex set of dependencies on your local machine.
In GitLab 14.0, we introduced a WYSIWYG Markdown editor, what we've come to call the Content Editor, that provides a rich text editing experience to make it easier for everyone to contribute. Initially available in the Wiki, the highest priority for the Editor group here is to build complete support for GitLab Flavored Markdown so that the Content Editor can be used as a production-ready, default editing experience for Wiki. Afterward, the Content Editor can be introduced anywhere Markdown content is written in GitLab. This includes issue and epic descriptions, comments, and even when editing Markdown files directly in the Repository view or Web IDE.
The Source Editor is a flexible and extensible code editing component, based on Monaco, used in several places across GitLab including the Web Editor (also referred to as the Single File Editor, what you use when you edit a file from the repository view), the Pipeline Editor, and the Snippet editor. One of the primary goals for the category is to bridge the gap between the Web Editor and the more complex, but powerful, Web IDE. We are currently focusing on extending the underlying Source Editor itself and enabling more advanced workflows like live Markdown preview or inline merge request discussions.
GitLab Pages offers a streamlined way to deploy and host your statically generated website on our shared infrastructure. The current implementation is focused primarily on making the connection between the CI build process and the deployment of static assets, there is huge potential to improve the user experience around managing, editing, and collaborating on static assets from within GitLab. Pages is a critical piece of the Editor group's strategy for enabling everyone to contribute.
The Wiki is one of our most used categories and there are several opportunities to improve the experience and drive growth. We are wrapping up an effort to migrate the wiki functionality to native Gitaly RPCs, which will bring performance and stability improvements. Following that, however, we will reduce our investment in Wiki to support only the most critical and severe bug fixes while we shift our attention to building an MVC for Remote Development.