A team may receive an HTML notice whose source mixes tabs with spaces. Setting four-column tabs can make the source easier to inspect, but a reviewer who asks for a spaces-only file needs an actual content conversion. The display and the saved characters are separate checks.
Apply the policy to the current document
For an initialized Monaco editor with the intended document open:
const model = editor.getModel();
if (!model) throw new Error('No source document is open.');
model.updateOptions({
tabSize: 4,
indentSize: 4,
insertSpaces: true
});
tabSize defines tab-stop width. indentSize sets the indentation size, and can also use 'tabSize' to follow that value. insertSpaces controls whether indentation uses spaces rather than tab characters. These options do not provide a migration of the current text.
Read model.getOptions() to inspect the resolved settings for that model. If the application has several source tabs, apply or restore each document's intended policy when selecting it. Do not assume that changing one model configures every open file.
The Monaco source integration describes model creation and lifetime. Keep the same model when changing its indentation policy so the author's unsaved text remains available.
Decide whether file contents may override the default
When creating a standalone editor, an application that requires a fixed four-space policy can start with:
const indentationOptions = {
tabSize: 4,
insertSpaces: true,
detectIndentation: false
};
Merge these options into the application's real editor creation options rather than creating a second editor just to apply them. detectIndentation controls whether Monaco detects tabSize and insertSpaces from the file contents. Choose a fixed policy only when the application or repository requires it; a file editor intended to respect existing conventions may need detection instead. Construction options
Initial configuration and later model changes have different timing. Check the resolved options after the intended document has loaded, especially if the surrounding application replaces the model during navigation.
Convert existing whitespace as a separate edit
Changing a tab stop can move text on the screen while leaving the source string unchanged. Before any conversion, inspect representative lines with actual tab characters and lines with literal spaces. A global string replacement of every tab is not a safe formatting policy for HTML containing preformatted text, scripts, or embedded data.
If the interface offers an indentation conversion action, make its scope explicit and verify the resulting diff. A whole-document formatter is another content operation; the Monaco formatting guide explains awaiting that action before collecting a save value. Neither action should run merely because the reader changes a viewing preference.
Verify the model and a newly typed indent
Use a development document containing a tab before one paragraph and spaces before another. Record model.getValue() before changing the options. After updateOptions(), confirm that the existing source string is unchanged and that getOptions() reports the chosen policy.
Then place the caret at a new blank line, press Tab with the editor's normal indentation key behavior enabled, and inspect the characters inserted into that line. For the four-space configuration, verify four spaces rather than inferring the result from the visual width. If Tab moves focus instead, inspect the application's keyboard mode and keybindings before changing document settings.
Save only the intended content edits. Reopen the source and check its resolved indentation settings alongside the stored whitespace, so a correct-looking pane does not conceal an unconverted or accidentally changed file.