Support EditorConfig inside of the Web IDE
Problem to Solve
Developers collaborating on projects follow certain coding standards and styles to maintain consistent levels of readability and format. These standards are usually provided to developers through configuration files that the developer's editor might read and apply. When working in the Web IDE, even if a project has configured this type of file, those settings can't be enforced.
The leader in standards for this is EditorConfig which providers a file format for defining coding styles. There is also a collection of text editor plugins that enable editors to read the file and adhere to defined styles.
The Web IDE should support the following
.editorconfig settings which align with available methods in the Monaco API.
indent_style: Monaco attribute https://microsoft.github.io/monaco-editor/api/interfaces/monaco.editor.itextmodelupdateoptions.html#insertspaces
indent_size: Monaco attribute https://microsoft.github.io/monaco-editor/api/interfaces/monaco.editor.itextmodelupdateoptions.html#tabsize
end_of_line: Monaco attribute https://microsoft.github.io/monaco-editor/api/enums/monaco.editor.endoflinesequence.html
trim_trailing_whitespace: Monaco attribute https://microsoft.github.io/monaco-editor/api/interfaces/monaco.editor.itextmodelupdateoptions.html#trimautowhitespace
tab_width: Monaco attribute https://microsoft.github.io/monaco-editor/api/interfaces/monaco.languages.formattingoptions.html#tabsize
insert_final_newline: There is the attribute https://microsoft.github.io/monaco-editor/api/enums/monaco.editor.editoroption.html#renderfinalnewline, but it's for rendering a final new line, not adding it. Not sure if this is supported.
Based on the comment #23352 (comment 342757032), we are going with a frontend approach for this issue. The comment goes over why that approach would be better than doing it in the backend right now.
On the frontend
- Whenever the Web IDE is open, fetch the root
.editorconfigfile if it exists.
- Whenever any directory tree opens, fetch the
.editorconfigfile of that directory and all its parents (if needed).
- Use editorconfig-core-js and adapt it to work in a browser environment with the Web IDE. It is basically some code on top of an
.iniparser and a minimatch utility.
- Use the above utility to parse the
.editorconfigfiles in the current directory and its parents, and determine which properties apply to the the currently open file.
- Map those properties to Monaco's equivalent names, and apply.
On the backend
Backend creates a new API, which accepts an array of file paths and returns a JSON containing the contents of those files. It would be very helpful, but the initial POC can be built by sending multiple requests too.
What's covered and what's not
- We will add support for
.gitattributefiles will not be supported in this iteration.
- The support will be added only to the Web IDE, and not the single file editor or Snippets.
- Live application of
.editorconfigsettings by means of editing that file in the Web IDE will be supported.
- The library mentioned above is quite dated. If we use it and adapt to use with the Web IDE, maintaining it is in our own hands.
- It has three dependencies, which we would need to include:
lru_cache(Note: this is actually a good thing to include in the Web IDE, and can help us with &2433.)
sigmund(this is basically just a high performing
- It could be expensive in terms of performance to parse the properties, but we can't say right now how expensive. The initial POC will not concern itself with performance, but if concerns arise, we will move the processing to a Web Worker.
- The library would increase the bundle size of the Web IDE quite a bit. Not sure how much yet, but will get to know about this as the POC begins.