DEV Community: Carlos

I wrote a VS Code extension because my settings.json kept getting shuffled

Carlos — Mon, 09 Nov 2026 17:13:56 +0000

I usually have three or four VS Code windows open at once. The API, the frontend, some side project, and whatever repo I opened "just to check something" two hours ago. They all look the same, so I'd regularly type into the wrong one.

The fix everybody knows is to give each workspace its own color. Blue title bar for the API, orange for the frontend, and so on. There are extensions for that and they work fine.

My problem was with what they did to .vscode/settings.json.

The diff that annoyed me

In a couple of my projects .vscode/settings.json is committed. I keep it organized by hand: related keys together, a comment here and there explaining why something is set. Every time I changed the color, the diff looked something like this:

   "workbench.colorCustomizations": {
-    // My own tweaks, grouped on purpose
     "editor.lineHighlightBackground": "#ffffff0d",
     "editorCursor.foreground": "#ffcc00",
-    // Workspace tint
-    "statusBar.background": "#2f6fd6",
+    "terminal.background": "#1b1b1f",
+    "statusBar.background": "#2e8b57",
     "statusBar.foreground": "#e7e7e7",
-    "statusBarItem.hoverBackground": "#447dda",
-    "terminal.background": "#1b1b1f"
+    "statusBarItem.hoverBackground": "#439768"
   }

Two values changed. The diff touches eight lines, both comments are gone, and terminal.background, which I never touched, jumped to the middle of the block.

It's not a bug in those extensions, really. It's how the VS Code API works. When you call

workspace.getConfiguration().update('workbench.colorCustomizations', newObject)

you're handing VS Code a brand new object, and it writes that object in place of the old one. Whatever order the keys have in newObject is the order you get in the file, and comments inside it are simply dropped because a JS object has nowhere to keep them.

So I wrote my own extension, Tidy Tint. It does the same job (color the activity bar, title bar and status bar per workspace) but it never calls update() for the colors. It edits the file as text.

Editing JSON as text without going crazy

Doing string surgery on JSON by hand sounds like a terrible idea, and it is. Luckily VS Code itself solves this problem with jsonc-parser, the same library it uses to read your settings. It understands comments and trailing commas, and it has a modify() function that, instead of returning a new document, returns a list of edits: "at offset X, replace N characters with this string".

That's exactly what I wanted. The rules I ended up with are:

if a key already exists, only its value changes, in place;
if it's new, it goes at the end of its object;
removing colors deletes only the keys Tidy Tint wrote, with their comma and their line;
nothing else in the file is touched.

The first version was basically applyEdits(text, modify(text, path, value, { formattingOptions })) in a loop, and it almost worked. The catch is that when you pass formatting options, jsonc-parser sometimes reformats the lines around the edit too. Not much, but enough to show up in the diff, which was the whole thing I was trying to avoid.

The workaround was to ask for the edits without formatting and then format only the text I just inserted:

function applyMinimal(text: string, edits: Edit[], options: FormattingOptions): string {
  for (const e of [...edits].sort((a, b) => b.offset - a.offset)) {
    text = text.slice(0, e.offset) + e.content + text.slice(e.offset + e.length);
    if (e.content.length > 0) {
      text = applyEdits(text, format(text, { offset: e.offset, length: e.content.length }, options));
    }
  }
  return text;
}

The edits are applied from the end of the file backwards so earlier offsets stay valid. The formatting options aren't hardcoded either: the extension looks at the file first and copies whatever it finds (tabs or spaces, indent width, \n or \r\n). If your file uses tabs and CRLF, so do the new lines.

Deleting a key is the annoying part

Adding and changing values was the easy half. Removing them cleanly took more fiddling than I expected, because of commas.

If the key is in the middle of the object, you delete from the start of its line to the start of the next key. If it's the last one, you have to eat the comma of the previous key instead, otherwise you're left with a trailing comma (valid in JSONC, but ugly and not what was there before). And if it's the only key, the object just becomes {}.

if (siblings.length === 1) {
  // Only property: the object becomes "{}".
  start = obj.offset + 1;
  end = obj.offset + obj.length - 1;
} else if (i < siblings.length - 1) {
  // Another one follows: delete from this property to the start of the next.
  start = lineStartIfOnlyIndent(text, prop.offset);
  end = lineStartIfOnlyIndent(text, siblings[i + 1].offset);
} else {
  // It's the last one: delete from the end of the previous one (including its comma).
  const prev = siblings[i - 1];
  start = prev.offset + prev.length;
  end = prop.offset + prop.length;
}

When you run "Remove Colors" and workbench.colorCustomizations ends up empty, the extension removes that key too, so you don't keep a lonely {} hanging around. If you had your own keys in there (like my cursor color or the terminal background) they stay exactly where they were.

Writing the file without breaking undo

The last detail: once I have the new text, I don't write it to disk with fs. I apply it with a WorkspaceEdit and then save the document. Two reasons. If you have settings.json open with unsaved changes, writing behind VS Code's back is asking for trouble. And with a WorkspaceEdit the change goes into the editor's history, so Ctrl+Z (Cmd+Z on Mac) undoes a color change like any other edit.

The colors

This part is less interesting but I'll mention it. You pick one base color and the extension derives the rest: foreground is light or dark depending on the base's luminance (the WCAG formula), inactive title bar is the same color with some transparency, the badge on the activity bar uses the hue rotated 150° so it stands out, and the hover color on the status bar is slightly lighter or darker. There are 13 keys in total, and those 13 are the only ones Tidy Tint will ever write or delete.

The random color isn't fully random either. It picks a random hue but keeps saturation and lightness in a range that doesn't give you neon green or a gray that looks like nothing changed.

Tests

Since the whole point of the extension is "don't mess up my file", the JSON editing code is tested with Node's built-in test runner, no extra framework. The tests are boring in a good way: take a settings file with comments and keys in a weird order, change the color twice, and check that the order of keys is identical and the comments are still there. Remove colors and check that only Tidy Tint's keys disappeared.

Using it

Install Tidy Tint from the Marketplace and open the command palette:

Tidy Tint: Change Color lets you pick from a list of favorites, type a hex value, or go random
Tidy Tint: Random Color if you don't care
Tidy Tint: Remove Colors to undo everything

You can turn off each bar separately (tidyTint.affectActivityBar, tidyTint.affectTitleBar, tidyTint.affectStatusBar) and change the favorites list in tidyTint.favoriteColors.

In a multi-root workspace the colors go in the .code-workspace file, so you need to save the workspace first.

One honest limitation: Tidy Tint only controls what it writes. If another extension or the Settings UI later rewrites workbench.colorCustomizations as a whole object, the order will change again. I can't do anything about that.

That's it

It's a small extension, around 350 lines of TypeScript, and it solves a problem that maybe only bothers people who read their own diffs too carefully. If you're one of them, give it a try.

The code is MIT and lives on GitHub: cbsumastre/tidy-tint. Issues and PRs are welcome, and if you find a settings file that it mangles, I'd really like to see it.

Cómo se calcula la letra del DNI y del NIE (módulo 23, con código)

Carlos — Wed, 30 Sep 2026 10:39:17 +0000

Si alguna vez has validado un DNI en un formulario, o has necesitado datos de prueba para un entorno de test, te habrás preguntado de dónde sale esa letra final. No es aleatoria ni un truco: es un dígito de control que se calcula con una operación muy simple. Vamos a verlo paso a paso y con código.

El algoritmo del DNI

Un DNI son 8 dígitos y una letra. El Ministerio del Interior publica el algoritmo [1], y la letra se obtiene así:

Toma los 8 dígitos como un número entero.
Calcula el resto de dividirlo entre 23 (módulo 23).
Busca ese resto como posición en esta tabla de 23 letras:

TRWAGMYFPDXBNJZSQVHLCKE

La posición empieza en 0. El resto 0 es T, el 1 es R, el 2 es W, y así hasta el 22, que es E.

Ejemplo

DNI 12345678:

12345678 mod 23 = 14
La posición 14 de la tabla es Z
Resultado: 12345678Z

Un caso límite del cálculo: 00000000 da resto 0, que es T, así que 00000000T.

No están todas las letras del alfabeto: faltan I, Ñ, O y U. No hay una explicación oficial fácil de encontrar. Estas son las que circulan:

I y O: en esto coinciden todas las fuentes. Se descartan porque se confunden con 1 y 0.
Ñ: hay dos versiones. Según el matemático Raúl Ibáñez (UPV/EHU), se quitó por los problemas con sistemas informáticos de otros países, que no tienen esa letra [3]. Según Wikipedia, para no confundirla con la N [4].
U: según Ibáñez, para quedarse en 23 letras. El 23 es primo, y eso es lo que permite detectar errores (lo vemos más abajo) [3].

El NIE: el mismo algoritmo con un paso previo

El NIE (número de identidad de extranjero) tiene una letra inicial X, Y o Z, siete dígitos y una letra final de control.

Un poco de historia: al principio el NIE era una X seguida de ocho dígitos. La Orden INT/2058/2008 [2] fijó el formato actual de nueve caracteres, con una letra inicial, siete dígitos y un carácter de verificación. También estableció que, al agotarse la serie de la X, se siguiera por orden alfabético. Por eso existen los NIE con Y y con Z.

Para calcular la letra final [1]:

Sustituye la letra inicial por un dígito: X → 0, Y → 1, Z → 2.
Concatena ese dígito con los 7 dígitos: obtienes un número de 8 cifras.
Aplica el mismo módulo 23 y la misma tabla.

Ejemplo

NIE X1234567:

X → 0, así que el número es 01234567
1234567 mod 23 = 19
La posición 19 de la tabla es L
Resultado: X1234567L

Con Y1234567 se calcula 11234567, y con Z1234567 se calcula 21234567.

En código (TypeScript)

const LETTERS = "TRWAGMYFPDXBNJZSQVHLCKE";
const NIE_PREFIX: Record<string, string> = { X: "0", Y: "1", Z: "2" };

// Los usuarios escriben "12.345.678-z": quita espacios, puntos y guiones.
const normalize = (s: string) => s.toUpperCase().replace(/[\s.-]/g, "");

export function dniLetter(digits: string): string {
  return LETTERS[Number(digits) % 23];
}

export function isValidDni(raw: string): boolean {
  const m = /^(\d{8})([A-Z])$/.exec(normalize(raw));
  return m !== null && dniLetter(m[1]) === m[2];
}

export function isValidNie(raw: string): boolean {
  const m = /^([XYZ])(\d{7})([A-Z])$/.exec(normalize(raw));
  return m !== null && dniLetter(NIE_PREFIX[m[1]] + m[2]) === m[3];
}

isValidDni("12345678Z"); // true
isValidDni("12.345.678-z"); // true
isValidDni("12345678A"); // false
isValidNie("X1234567L"); // true

Un detalle práctico: normaliza siempre antes de validar. Es lo que hace normalize. Si no, rechazarás documentos correctos escritos con puntos, guiones o en minúsculas.

Qué valida y qué no

La letra detecta errores de tecleo. Si te equivocas en un dígito o intercambias dos cifras, la letra ya no cuadra, porque ninguno de esos cambios deja el mismo resto al dividir entre 23. Lo que no hace es comprobar que el documento exista. 12345678Z es un DNI con formato y letra válidos, pero eso no dice nada de si pertenece a alguien.

Esto tiene una consecuencia útil para testing: puedes generar miles de DNI con letra correcta que pasan cualquier validación de formato sin corresponder a personas reales.

Probarlo sin escribir el código

Si solo necesitas datos de prueba o comprobar un documento:

Generador de DNI válido: números aleatorios y ficticios con la letra correcta.
Validador de DNI: te dice si la letra cuadra y, si no, cuál debería ser.

Los datos son ficticios. Úsalos para pruebas, QA, demos o seeds de base de datos, y nunca para hacerte pasar por nadie ni en trámites reales.

Resumen

Letra del DNI = TRWAGMYFPDXBNJZSQVHLCKE[número mod 23].
NIE = igual, cambiando X/Y/Z por 0/1/2 al principio.
Solo detecta errores de escritura: no prueba que el documento exista.

Fuentes

Ministerio del Interior. Cálculo del dígito de control del NIF/NIE.
BOE. Orden INT/2058/2008, de 14 de julio, sobre el Número de Identidad de Extranjero (BOE núm. 170, de 15 de julio de 2008).
Raúl Ibáñez. Un código detector de errores: la letra del DNI. Cuaderno de Cultura Científica, UPV/EHU, 2022.
Wikipedia. Número de identificación fiscal.