Migrar con cabeza y el lockfile

Una migración de editor fracasa casi siempre por el mismo error, y no es técnico: es hacerla de golpe. Borrar lo viejo el lunes, estrenar lo nuevo el martes, y el miércoles descubrir en mitad del trabajo que falta la mitad de tu memoria muscular. Un Arquitecto se muda como se despliega software: entorno de pruebas aislado, período de convivencia, checklist de paridad medible, y un corte que solo ocurre cuando la vuelta atrás ya no hace falta — pero sigue siendo posible. Esta lección da ese método para las dos direcciones, porque las dos son legítimas: entrar en LazyVim para delegar mantenimiento, y salir de ella para recuperar el control. Que sepas hacer ambas es precisamente lo que hace que ninguna te ate.

• Trazar el mapa de equivalencias entre tu config del Nivel 2 y la estructura de LazyVim.
• Montar la jaula de pruebas con NVIM_APPNAME y entender qué aísla exactamente.
• Migrar de config propia a LazyVim por capas, sin copiar y pegar a lo bruto.
• Averiguar, con evidencia y no con intuición, qué plugins de la distro usas de verdad.
• Extraer de LazyVim las specs de lo que usas, para llevártelas a una config propia.
• Aplicar la checklist de paridad antes de cualquier corte, y usar el lockfile como red.

El mapa de equivalencias

La razón de que estas mudanzas sean baratas comparadas con cambiar de editor es estructural, y conviene verla antes de empezar: tu config del Nivel 2 y LazyVim son el mismo idioma. Ambas son lazy.nvim gobernando specs, con la misma anatomía de carpetas. Migrar no es traducir entre dos mundos: es reorganizar piezas que ya encajan.

Léelo también en la otra dirección, porque es el mismo mapa: todo lo que LazyVim hace está en una de esas filas, y por tanto todo tiene un sitio natural en una config propia. No hay magia sin equivalente.

Fase 0, siempre: la jaula

Las dos direcciones comparten el primer paso, y ya lo conoces de las lecciones 0.2 y 5.1: NVIM_APPNAME. Cambia la carpeta que Neovim usa para config, datos, estado y caché a la vez, así que dos APPNAME distintos son dos instalaciones que no comparten absolutamente nada: ni plugins, ni lockfile, ni sesiones, ni historial de shada, ni caché de Treesitter.

# la config candidata vive en su propia jaulagit clone https://github.com/LazyVim/starter ~/.config/nvim-candidata   # (o tu esqueleto)NVIM_APPNAME=nvim-candidata nvim# comodidad durante la convivenciaalias nvc='NVIM_APPNAME=nvim-candidata nvim'

La jaula convierte la migración de apuesta en experimento: la config nueva se construye, se prueba con proyectos reales y se abandona o adopta sin que la vieja se haya enterado. El día del corte no es un salto: es un mv de carpetas — o quedarte con el alias para siempre, que también es un final válido.

Entender qué aísla la jaula es lo que te permite experimentar con agresividad: nada de lo que hagas dentro puede costarte nada fuera.

Dirección A: de tu config a LazyVim

No copies y pegues a lo bruto: tu config del Nivel 2 contiene mucho que LazyVim ya trae, y duplicarlo es heredar conflictos. Migra por capas, de lo más barato a lo más delicado:

LazyVim limpio en la jaula

Clona el starter bajo un APPNAME propio, arranca, pasa :LazyHealth (lección 5.2). Antes de portar nada, úsalo un rato tal cual: necesitas saber qué trae de fábrica para no llevarle redundancias.

Opciones: porta el diff, no el archivo

Abre tu options.lua junto a los defaults de la distro (~/.local/share/nvim-candidata/lazy/LazyVim/lua/lazyvim/config/options.lua, o su documentación) y compara línea a línea. Muchas de tus opciones —relativenumber, undofile, ignorecase con smartcase, el clipboard del sistema— ya están puestas. A lua/config/options.lua va únicamente lo que sea distinto o tuyo. Cuanto más corto quede el archivo, mejor hecho está el paso.

Keymaps: audita antes de portar

El peligro de esta capa no es perder atajos: es pisarlos. Antes de pegar tu keymaps.lua, pasa cada lhs por :map en la LazyVim limpia y apunta los choques — recuerda que la distro reparte s, S y <C-Space> (lección 5.3). Para cada choque decide: ¿adopto su tecla, o la recupero con las técnicas de override? Ambas respuestas valen; lo que no vale es no decidir y dejar que gane el orden de carga.

Lenguajes: archivos fuera, extras dentro

Donde tenías lua/plugins/lang-rust.lua a mano, activa el extra de Rust en :LazyExtras y borra tu archivo. Deja que la distro mantenga eso: es su mejor mercancía. Lo que quede sin extra —Swift en nuestro caso— entra por las dos vías de la lección 5.4. Al final de este paso, tu soporte de lenguajes debe ser una lista en lazyvim.json más un archivo para Swift, no una carpeta de configs.

Plugins únicos: solo los que la distro no cubre

Recorre tus specs restantes con tres destinos posibles: la distro ya lo trae (borra tu spec; si quieres cambiar su config, override de opts, no spec completa), la distro trae un equivalente (pruébalo una semana antes de imponer el tuyo desactivando el suyo), o es genuinamente tuyo (cópialo a lua/plugins/ tal cual — las specs son las mismas).

Convivencia y corte

Trabaja en la jaula con proyectos reales hasta pasar la checklist de paridad (abajo). Entonces — y solo entonces — el corte: tu config vieja a ~/.config/nvim.bak, la candidata a ~/.config/nvim. La vieja no se borra: se conserva versionada, porque es tu salida de emergencia y, dentro de un año, tu documentación.

Dirección B: graduarse de LazyVim

También es válido —y este curso lo considera una graduación, no una apostasía— salir de la distro cuando quieras control total. La clave técnica ya la tienes: LazyVim es lazy.nvim por debajo, sus specs están en Lua legible en tu disco, y extraer es leer y copiar. La clave metodológica es otra, y es donde falla casi todo el mundo: antes de extraer hay que saber qué extraer, y la intuición miente.

Inventario con evidencia, no con memoria

Tu sensación de qué plugins usas está sesgada hacia lo visible: recordarás el picker y el statusline, y olvidarás el plugin silencioso que hace que todo encaje. Reúne evidencia real durante una semana de trabajo normal:

• :Lazy te dice qué cargó. La UI del gestor distingue los plugins cargados en esta sesión de los que siguen dormidos. Un plugin que tras una semana de trabajo real nunca aparece como cargado es un candidato firme a no existir en tu config futura.
• El experimento de la ausencia. Para los dudosos, la prueba definitiva: enabled = false (lección 5.3) y una semana de trabajo. Si no lo echaste de menos, ya tienes la respuesta. Si algo cojea, acabas de descubrir para qué servía — que es exactamente el conocimiento que necesitas para la config nueva.
• Tu memoria muscular, por escrito. Durante unos días, apunta cada atajo que uses que no sea Vim puro. Esa lista corta — suele sorprender lo corta que es — es tu contrato de paridad: la config nueva debe cubrirla entera.

Extrae las specs de tu inventario

Para cada plugin superviviente tienes dos fuentes de su configuración exacta: el código de la distro en ~/.local/share/nvim/lazy/LazyVim/lua/lazyvim/plugins/, y su página en la documentación, donde cada plugin muestra la spec completa desplegable. Copia la spec a tu config nueva y recórtala: la distro configura para todos sus usuarios; tú solo necesitas tu caso. No portes las integraciones con plugins que no te llevas.

Recrea el esqueleto que ya sabes montar

Parte de tu config de los Niveles 1–4 — o de kickstart, si quieres una segunda opinión de base — en su propia jaula de NVIM_APPNAME. Añade los plugins del inventario uno a uno, probando entre cada alta. La tentación es traerlo todo de golpe; el método es que cada plugin entre cuando el anterior funcione. Aquí es donde cobras los réditos del Nivel 2: nada de esto es nuevo, solo es tuyo otra vez.

Paridad, convivencia, corte

El mismo final que la dirección A: la checklist de abajo, semanas de convivencia real, y un corte reversible. Con un matiz de calendario: al salir de la distro recuperas la responsabilidad del mantenimiento, así que el mejor momento para el corte es uno en que tengas margen para absorber la primera rotura del ecosistema tú solo. Saliste de LazyVim sabiendo lo que hace; procura salir también sabiendo lo que hacía por ti.

La checklist de paridad

El corte no se decide por sensaciones («ya me encuentro cómodo») sino por una lista que se pasa o no se pasa. Esta es la del curso; añádele tus filas:

Mientras haya una fila sin pasar, no hay corte: hay convivencia. La jaula hace que esperar sea gratis.

El lockfile en la mudanza

Tanto tu config como LazyVim generan lazy-lock.json: la lista de versiones exactas (commits) de cada plugin instalado. En una migración cumple un papel extra que conviene explotar:

Congela durante la mudanza

Mientras migras, no actualices: que la única variable sea tu migración. :Lazy restore te mantiene en las versiones del lockfile si algo se instala de más.

Foto del estado bueno

Versiona el lockfile en Git en las dos configs — y en LazyVim, también lazyvim.json, que es la mitad de tu configuración. El commit del día del corte es tu punto de restauración con nombre.

Reproducible en otra máquina

Con lockfile y lazyvim.json versionados, tu setup se clona idéntico donde haga falta. Sin ellos, cada máquina es una migración nueva.

Y la disciplina de siempre, que en migración importa el doble: actualiza a propósito, no por inercia. :Lazy update cuando tengas tiempo de revisar lo que cambió; :Lazy restore como vuelta atrás inmediata si la actualización rompe algo. Con esta red, ni migrar ni mantener vuelven a ser apuestas.

El stdpath debe apuntar a la carpeta del APPNAME, no a la de tu config de siempre. Esa línea es la prueba de que nada se comparte.

Los que nunca cargan tras trabajo real son los primeros candidatos a no acompañarte en la mudanza.

La fila más rentable del mapa de equivalencias: un archivo entero se convierte en una línea de lazyvim.json mantenida por otros.

Las specs de LazyVim son specs de lazy.nvim normales: extraer es leer, copiar y quitar lo que no es tu caso.

Una salida de emergencia solo existe si la has probado. Debe costarte menos de un minuto.

El lock-in se mide en coste de salida

Toda esta lección es la aplicación concreta de una pregunta que deberías hacerle a cada dependencia seria de tu vida profesional — un framework, una nube, un formato de datos, un empleador de tu conocimiento: no «¿qué me da?», que es lo que su propaganda ya contesta, sino «¿cuánto me costaría irme?». Esa cifra, el coste de salida, es la definición operativa del vendor lock-in, y tiene una propiedad incómoda: no la ves hasta que intentas salir, y para entonces la pagas al precio que sea. Los sistemas que atrapan no suelen hacerlo con cadenas; lo hacen con formatos que solo ellos leen, con conocimiento que solo dentro de ellos vale, y con la simple acumulación de años de decisiones sin documentar.

Míralo con LazyVim y verás por qué esta guía la eligió sin miedo: sus specs son Lua legible en tu disco, su gestor es el mismo que usarías sin ella, su estructura es la estándar, y salir — lo acabas de ver — es un procedimiento de una lección, no una odisea. Su coste de salida es bajo por diseño, y esa es una virtud que deberías pesar tanto como cualquier feature cuando compares herramientas: la calidad de una jaula se mide por lo bien dibujada que tiene la puerta.

Pero la mitad de la cuenta es tuya, no de la herramienta, y es la moraleja del nivel entero: el lock-in no está solo en el software — está en lo que tú no sabes. Para quien no distingue el gestor de la distro, salir de LazyVim es imposible aunque la puerta esté abierta de par en par; para ti, que construiste primero y aprendiste la distro después, es un fin de semana con checklist. El conocimiento de las capas de debajo es la única póliza anti-lock-in que funciona con cualquier proveedor, porque viaja contigo. Los Niveles 1 a 4 de esta guía fueron exactamente esa póliza. Este nivel fue el recibo.

Muévete sin miedo

1. Monta la jaula con NVIM_APPNAME y verifica el aislamiento con :echo stdpath("data") en las dos configs.
2. Ejecuta la dirección que te toque — hacia LazyVim o hacia config propia — hasta el paso de convivencia, siguiendo las fases en orden y sin saltarte la auditoría de keymaps.
3. Construye tu inventario con evidencia: el estado de carga de :Lazy tras un día real, y tu lista de memoria muscular por escrito.
4. Pasa la checklist de paridad entera y anota qué filas fallan. Cada fila fallida es tu trabajo de esta semana, no un motivo de corte anticipado.
5. Versiona lazy-lock.json (y lazyvim.json si aplica) en las dos configs, y practica el ciclo :Lazy update seguido de :Lazy restore para ver la red funcionando.
6. Ensaya la vuelta atrás con cronómetro. Cuando cueste menos de un minuto, y solo entonces, ejecuta el corte — o decide quedarte donde estás, que con la puerta ensayada también es una decisión libre.