Next

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.

Additional Details

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.

Acceptance criteria

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.

Proposal

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 .editorconfig file if it exists.
• Whenever any directory tree opens, fetch the .editorconfig file 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 .ini parser and a minimatch utility.
• Use the above utility to parse the .editorconfig files 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 .editorconfig files only. .gitattribute files 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 .editorconfig settings by means of editing that file in the Web IDE will be supported.

Concerns

• 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.)
  • path
  • sigmund (this is basically just a high performing deepEquals function)
• 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.