# Documentación de AfterPack Un paso posterior al build que ofusca el JavaScript que genera tu bundler. Una dependencia de desarrollo, una línea; la salida de producción se publica ilegible y el desarrollo queda intacto. Source: https://www.afterpack.dev/es/docs > Deja de publicar tu código fuente. Cada bundle que despliegas es tu código fuente: un agente de programación ya lee, explica y reescribe JavaScript minificado en minutos, así que minificado solo significa publicado con una letra más pequeña. AfterPack es el paso posterior al build que cierra esa brecha. Una dependencia de desarrollo, una línea, y tu salida de producción se publica con los nombres cambiados y las cadenas codificadas, así que ningún lector, humano o modelo, puede encontrar tu lógica con grep ni copiarla tal como la escribiste. Cada build tiene una forma distinta, así que las herramientas escritas contra los patrones de un build fallan en el siguiente. Se ejecuta después de tu bundler, nunca toca tu código fuente y puede darte un Protection Map con exactamente lo que cambió. No convierte un secreto del lado del cliente en uno del lado del servidor: quien ejecuta tu código todavía puede leer los valores que usa. ## Úsalo cuando - El navegador recibe lógica que alguien pagaría por copiar o saltarse: una comprobación de licencia, reglas de precios, anti-trampas, un paywall, un SDK integrado. - Un cliente o un cuestionario de seguridad pregunta si el JavaScript que publicas es legible. - Quieres un paso posterior al build que deje el desarrollo intacto. - Sirves JavaScript desde un Cloudflare Worker y quieres que cambie de forma en cada ventana de rotación. ## Prescinde de él cuando - Todo lo valioso ya se ejecuta en el servidor y el cliente es una vista ligera. - El código es de código abierto o está pensado para leerse. - Necesitas que un secreto siga siendo secreto en el navegador: ningún ofuscador lo consigue, y AfterPack lo dice. ## Todo en un archivo - [Documentación completa (en inglés)](https://www.afterpack.dev/llms-full.txt): todas las páginas de abajo, concatenadas. - [Configuración en JSON](https://www.afterpack.dev/docs-config.json): el registro, legible por máquinas. - [Roadmap](https://www.afterpack.dev/roadmap.md): lo que ya se publicó y lo que viene. ## Primeros pasos - [Resumen](https://www.afterpack.dev/docs.md) - [Inicio rápido](https://www.afterpack.dev/es/docs/quickstart.md): Elige tu framework, instala una dependencia de desarrollo, compila y abre el Protection Map. - [Buenas prácticas](https://www.afterpack.dev/es/docs/best-practices.md): Cómo ofuscar por defecto al enviar tu JavaScript, marcar las regiones que importan con directivas, y rotar tu build para que los atacantes no puedan adelantarse. - [Cómo funciona AfterPack](https://www.afterpack.dev/es/docs/concepts.md): Qué hace la salida estándar (Free) con tu código, cómo resiste la reversión y qué puede recuperar realmente un atacante. ## Guías - [Build y CI](https://www.afterpack.dev/es/docs/builds.md): Dónde encaja AfterPack en tu pipeline: solo en producción, compila una vez y promueve el mismo artefacto por todas las etapas, con una receta de CI y las reglas para semillas, artefactos, source maps y una nube caída. - [Protection Map](https://www.afterpack.dev/es/docs/protection-map.md): El informe HTML que muestra lo que AfterPack hizo con tu código: cada token coloreado según cuánta transformación recibió. ## Casos de uso - [Comprobaciones de paywall](https://www.afterpack.dev/es/docs/use-cases/paywall-checks.md): Una barrera de paywall en el bundle es una función con nombre que devuelve un booleano, e invertirla es un parche de una línea. Qué cambian la ofuscación y una semilla por build a la hora de encontrarla y de mantener el parche funcionando. - [Lógica de precios y acceso](https://www.afterpack.dev/es/docs/use-cases/pricing-logic.md): Los límites de plan, los umbrales de cuota y las reglas de feature flags en el JavaScript de cliente se leen como una especificación de tu modelo comercial. Cómo evitar que sean legibles y qué sigue siendo observable de todos modos. - [Claves de API publicadas](https://www.afterpack.dev/es/docs/use-cases/shipped-api-keys.md): Restríngela, ponla detrás de un proxy, rótala y después ofusca lo que quede. Qué aporta realmente codificar una credencial en tu bundle y dónde se queda corto. - [Secretos accidentales](https://www.afterpack.dev/es/docs/use-cases/accidental-secrets.md): Una credencial llegó a un bundle desplegado. Cómo saber qué expone tu sitio en producción ahora mismo, qué cambia el siguiente build para ese valor y por qué la rotación es el paso que lo cierra. - [Herramientas de parcheo](https://www.afterpack.dev/es/docs/use-cases/patching-tools.md): Un userscript, un parche de Tampermonkey o una extensión tiene que anclarse a un nombre, una cadena o una forma reconocible de tu JavaScript. Qué les hacen a esos anclajes la ofuscación estructural y una forma de build nueva. - [Funciones sin publicar](https://www.afterpack.dev/es/docs/use-cases/unreleased-features.md): Los nombres de flags, las cadenas de rutas y los textos de interfaz no lanzados llegan a cada visitante antes de que anuncies nada, y la gente compara bundles entre versiones. Qué eliminar, qué proteger y qué dejar fuera del build por completo. - [Escáneres de seguridad](https://www.afterpack.dev/es/docs/use-cases/security-scanners.md): Patrones con forma de secreto, un sourceMappingURL que lleva a tu código fuente, huellas de librerías y una etiqueta de texto plano o minificado. Qué comprueba un lector automatizado y qué cambia un build ofuscado en el informe. - [Licencias en Electron](https://www.afterpack.dev/es/docs/use-cases/electron-license-logic.md): app.asar se desempaqueta con un comando, y una comprobación local de licencia o de prueba suele ser una sola comparación. Cómo ofuscar main, preload y renderer para que un crack no sobreviva a tu siguiente versión. - [Extensiones de navegador](https://www.afterpack.dev/es/docs/use-cases/browser-extensions.md): Una extensión publicada es un zip que cualquiera puede descomprimir y leer. Qué cambia al ofuscar los scripts de fondo y de contenido, y la política de la tienda que debes comprobar antes de publicar una. ## Frameworks - [Frameworks](https://www.afterpack.dev/es/docs/frameworks.md): Qué paquete instalar para tu stack, dónde se engancha y qué escribe. - [Angular](https://www.afterpack.dev/es/docs/frameworks/angular.md): En Angular v17+ la ofuscación es una pasada posterior al build sobre dist//browser: con la CLI o con el helper @afterpack/angular. - [Astro](https://www.afterpack.dev/es/docs/frameworks/astro.md): @afterpack/astro es una integración ligera que conecta @afterpack/vite con el propio pipeline de Vite de Astro. - [Electron](https://www.afterpack.dev/es/docs/frameworks/electron.md): @afterpack/electron conecta main, preload y renderer con una sola semilla en una única llamada, y rechaza el bytecodePlugin de electron-vite y las copias de seguridad sin protección antes de que puedan publicar tu código fuente. - [esbuild](https://www.afterpack.dev/es/docs/frameworks/esbuild.md): @afterpack/esbuild se engancha a build.onEnd y ofusca la salida emitida en el sitio. - [Next.js](https://www.afterpack.dev/es/docs/frameworks/nextjs.md): @afterpack/next ofusca el JavaScript de cliente dentro de next build, con Turbopack o webpack, en SSR o en exportación estática. - [Nuxt](https://www.afterpack.dev/es/docs/frameworks/nuxt.md): @afterpack/nuxt es un módulo de Nuxt 3 que registra @afterpack/vite en la configuración de Vite de Nuxt. - [Parcel](https://www.afterpack.dev/es/docs/frameworks/parcel.md): @afterpack/parcel-optimizer ofusca en memoria cada bundle empaquetado como un Optimizer de Parcel 2, y hace fallar el build de forma segura antes que publicar un chunk que da 404 en producción. - [Plain JS](https://www.afterpack.dev/es/docs/frameworks/plain.md): Apunta npx afterpack@latest a cualquier directorio de JavaScript emitido. Sin bundler, sin plugin y sin archivo de configuración. - [Remix](https://www.afterpack.dev/es/docs/frameworks/remix.md): No existe un paquete @afterpack/remix. Remix compila con Vite, así que usa @afterpack/vite o ejecuta la CLI sobre la salida del build. - [Rollup](https://www.afterpack.dev/es/docs/frameworks/rollup.md): @afterpack/rollup lee las directivas de tu código fuente y ejecuta el motor en generateBundle, antes de que Rollup escriba la salida. - [Svelte](https://www.afterpack.dev/es/docs/frameworks/svelte.md): @afterpack/svelte envuelve @afterpack/vite para proyectos Svelte: una línea de plugin en vite.config.ts. - [SvelteKit](https://www.afterpack.dev/es/docs/frameworks/sveltekit.md): @afterpack/sveltekit: una línea de plugin después de sveltekit() en vite.config.ts. - [Vite](https://www.afterpack.dev/es/docs/frameworks/vite.md): @afterpack/vite ofusca tu build en generateBundle, antes de que Vite lo escriba. Es la integración de referencia que envuelven todos los demás paquetes de la familia Vite. - [Vue](https://www.afterpack.dev/es/docs/frameworks/vue.md): @afterpack/vue envuelve @afterpack/vite para proyectos de Vue 3: una línea de plugin en vite.config.ts. - [Webpack](https://www.afterpack.dev/es/docs/frameworks/webpack.md): @afterpack/webpack se engancha a compilation.hooks.processAssets y ofusca tus assets antes de que webpack los escriba. ## CLI - [CLI](https://www.afterpack.dev/es/docs/cli.md): Cómo invocar npx afterpack@latest: una ruta opcional, cada clave de configuración como flag, los subcomandos verify, restore y audit y el contrato completo de códigos de salida. - [Auditoría](https://www.afterpack.dev/es/docs/audit.md): Escanea una URL en producción en busca de source maps públicos, código legible y credenciales filtradas, y obtén una puntuación sobre 100. El mismo escáner que impulsa el escáner de seguridad público, desde tu terminal. ## Configuración - [Configuración](https://www.afterpack.dev/es/docs/config.md): Cada opción, dónde establecerla y qué hace. - [Presets](https://www.afterpack.dev/es/docs/presets.md): Los cinco niveles de protección de minify a extreme, el objetivo de complejidad que establece cada uno y qué garantiza ya el valor por defecto sin configuración (light). - [Complejidad](https://www.afterpack.dev/es/docs/complexity.md): El único control detrás de cada preset: qué aumenta a medida que sube el número, el único umbral que cambia en medium y qué transformaciones puede desactivar la configuración pero no forzar. - [Directivas](https://www.afterpack.dev/es/docs/directives.md): Comentarios en tu código fuente que cambian la protección de AfterPack para el código que marcan. ## Seguridad - [Modelo de amenaza](https://www.afterpack.dev/es/docs/threat-model.md): El documento de revisión de seguridad de AfterPack: el activo que defiende, qué recupera cada clase de atacante, cómo sobrevive un secreto, dónde termina el alcance actual y los controles junto a los que funciona. - [Clases de reversión](https://www.afterpack.dev/es/docs/reversal-classes.md): Las clases de atacante estático en las que encajan las transformaciones de AfterPack y qué obtiene un atacante al recuperar cada una. - [Privacidad](https://www.afterpack.dev/es/docs/privacy.md): Un build local no envía nada. Un build en la nube ofusca en memoria y no conserva nada, excepto el Protection Map que le pediste que almacenara, que puedes desactivar. La telemetría está activada de forma predeterminada, informa cuando un build reporta un diagnóstico de nivel de error, nunca en un build limpio, y se desactiva con una variable de entorno. ## Nube y Pro - [Pro](https://www.afterpack.dev/es/docs/pro.md): Free protege todo tu bundle de manera uniforme. Pro te permite aplicar la protección más intensa solo donde importa: por región, por archivo. Además guarda un registro de cada build. - [API en la nube](https://www.afterpack.dev/es/docs/cloud-api.md): El contrato de red de api.afterpack.dev: autenticación, el endpoint de ofuscación por lotes, límites, límites de tasa, el presupuesto de tiempo del build y los códigos de diagnóstico que un cliente tiene que manejar. - [Modos de despliegue](https://www.afterpack.dev/es/docs/deployment-modes.md): Dos formas de ejecutar el motor: en local, en tu máquina, o en la nube de AfterPack con una clave Pro. - [Cloudflare Workers](https://www.afterpack.dev/es/docs/workers.md): Ejecuta AfterPack en tu propio Cloudflare Worker con @afterpack/wasm, pasa tu clave Pro para hacer el build en la nube de AfterPack y guarda cada resultado en caché por ventana de rotación. ## Panel - [Panel](https://www.afterpack.dev/es/docs/dashboard.md): Qué muestra el panel de AfterPack, cómo está organizado y qué builds aparecen en él. - [Espacios de trabajo y proyectos](https://www.afterpack.dev/es/docs/dashboard/workspaces.md): Los dos objetos de los que cuelga todo lo demás en el panel: quién puede hacer qué en un espacio de trabajo, cómo agrupan los proyectos builds y claves, y qué cambian las páginas de ajustes. - [Builds](https://www.afterpack.dev/es/docs/dashboard/builds.md): El registro de cada build Pro Cloud: cobertura, inflación, complejidad, tiempo de build, coste, diagnósticos y el Protection Map. - [Claves de API](https://www.afterpack.dev/es/docs/dashboard/api-keys.md): Cómo crear, acotar, usar y revocar la clave que convierte un build local en un build Pro Cloud. - [Uso y facturación](https://www.afterpack.dev/es/docs/dashboard/usage.md): Cómo leer el medidor de uso, las tres bolsas de las que tira un build, la línea de estado de la tarjeta del plan y qué te deja cambiar la página de facturación. ## Planes y facturación - [Niveles](https://www.afterpack.dev/es/docs/tiers.md): Free ejecuta el pipeline completo: la complejidad no tiene límite y todos los presets están disponibles. Lo que cambia entre niveles es la precisión con la que puedes aplicar la protección y cuántos MB de builds Pro obtienes cada mes. - [Cuentas](https://www.afterpack.dev/es/docs/accounts.md): Para qué sirve una cuenta de AfterPack, qué hay en tu página de cuenta personal y dónde está la documentación sobre espacios de trabajo, claves, uso y facturación. - [SLA, SLO y soporte](https://www.afterpack.dev/es/docs/sla.md): Qué es un objetivo y qué es una garantía contractual para la API en la nube de Pro, cómo se gestionan los incidentes y qué canal de soporte corresponde a cada nivel. - [Enterprise](https://www.afterpack.dev/es/docs/enterprise.md): Un contrato a medida: prioridad en desarrollo personalizado, una instalación privada del motor en tu propia nube, una revisión de seguridad conjunta y dos formas de despliegue para código fuente que no puede salir de tu infraestructura. ## Referencia - [Comparativa](https://www.afterpack.dev/es/docs/comparison.md): Cómo se compara AfterPack con javascript-obfuscator, js-confuser, JScrambler, JSDefender y ByteHide en tiempo de build, tamaño de salida y si la salida sigue ejecutándose, medido en un mismo arnés. - [Rendimiento](https://www.afterpack.dev/es/docs/performance.md): Lo que AfterPack cuesta a un build y a una página: tiempo de ofuscación medido sobre un bundle de 185 KB, tiempo y tamaño de descarga del build wasm, tamaño de salida y coste en tiempo de ejecución de cada preset, lo que paga el código protegido al leer un global del host y cómo afecta una semilla nueva a la caché. - [Contrato semántico](https://www.afterpack.dev/es/docs/semantic-contract.md): Qué conserva la salida de AfterPack del comportamiento de tu programa, cómo se comprueba cada versión del motor con código real y la breve lista de diferencias deliberadas. - [Diagnósticos](https://www.afterpack.dev/es/docs/diagnostics.md): Cada código DIAG_* que AfterPack emite, qué lo desencadena, cómo resolverlo, y los códigos de salida que devuelve un build. - [Glosario](https://www.afterpack.dev/es/docs/glossary.md): El vocabulario de la documentación de AfterPack: polimorfismo, no materialización, clases de reversión y el resto, definidos una sola vez. ## Ayuda - [Preguntas frecuentes](https://www.afterpack.dev/es/docs/faq.md): Las preguntas más habituales sobre AfterPack, respondidas en unos pocos párrafos breves cada una.