JavaScript
Explica cómo linting, formatting y herramientas de compatibilidad mantienen reglas consistentes, detectan errores y adaptan código a distintos entornos.
Linters, formatters, type checkers, tests y herramientas de compatibilidad detectan categorías distintas de problemas.
formatter → forma del código
linter → patrones y reglas estáticas
TypeScript/JSDoc → contratos de tipos
unit tests → comportamiento en casos
compatibility data → soporte del runtimeUn formatter decide espacios, saltos y presentación.
const value={a:1,b:2}puede convertirse en:
const value = {
a: 1,
b: 2,
};Reduce discusiones de estilo, pero no sabe si el algoritmo es correcto.
Un linter analiza el código y aplica reglas.
Puede detectar:
Una advertencia no siempre representa un fallo real. Investiga el propósito de la regla antes de desactivarla.
// eslint-disable-next-lineDebe incluir una razón concreta y el alcance mínimo.
export default [
js.configs.recommended,
{
rules: {
eqeqeq: "error",
},
},
];Una configuración versionada mantiene reglas iguales en editor, CI y equipo.
Algunas reglas necesitan información del type checker.
Pueden detectar:
El análisis es más costoso; configura proyectos y caches correctamente.
JavaScript puede documentar formas para editores y type checkers.
/**
* @param {{ price: number, quantity: number }} item
* @returns {number}
*/
function subtotal(item) {
return item.price * item.quantity;
}JSDoc no valida datos durante ejecución.
TypeScript comprueba contratos estáticos y genera JavaScript.
No garantiza:
Las fronteras externas continúan necesitando validación runtime.
Una herramienta puede transformar:
user?.profile?.name;para un target antiguo.
No puede transformar automáticamente toda API ausente:
fetch;
IntersectionObserver;
structuredClone;Necesitas:
Proyectos pueden declarar navegadores objetivo.
last 2 versions
not deadLas consultas concretas dependen de la herramienta y datos actuales. Define objetivos según usuarios reales, no mediante una cadena copiada sin contexto.
Datos como MDN, Can I Use y web-platform Baseline ayudan a conocer disponibilidad.
Comprueba:
if (typeof structuredClone === "function") {
return structuredClone(value);
}Detectar una propiedad es preferible a adivinar por user agent cuando el contrato permite fallback.
Puede ser necesaria para bugs específicos, pero es frágil:
Prefiere feature detection y pruebas del comportamiento relevante.
Un polyfill modifica o añade APIs globales.
Riesgos:
Usa implementaciones mantenidas y carga solo cuando sea necesario.
Una función importada que no modifica globals.
import structuredCloneFallback from "./clone.js";Reduce efectos globales, pero cada consumidor debe usarla explícitamente.
Pipeline mínimo:
format check
↓
lint
↓
typecheck
↓
tests
↓
buildEl orden puede optimizar tiempo, pero todos deben utilizar la misma configuración que el equipo.
Hooks locales ofrecen feedback rápido, pero pueden omitirse. CI es la fuente de verificación obligatoria.
No ejecutes toda una suite enorme en cada commit si vuelve el flujo inutilizable; selecciona checks rápidos localmente y completos en CI.
Herramientas cambian reglas y defaults. Actualiza de forma revisada:
No siempre conviene lintar o formattear output de build, vendor o archivos generados. Define ignores explícitos para evitar ruido.
button.addEventListener("click", () => {
void save().catch(showError);
});Una regla puede exigir que toda promesa sea awaited, retornada o marcada como fire-and-forget con manejo explícito.
¿Por qué compilar optional chaining no hace que IndexedDB exista en un runtime que no la implementa?
Porque optional chaining es sintaxis transformable. IndexedDB es una API del host y necesita soporte o una alternativa de diseño.
Leer documentación y especificaciones explica cómo encontrar el contrato correcto y distinguir estándar, host y herramienta.