Transcripción automática con Whisper. Puede tener errores, sobre todo en nombres propios y términos técnicos.
Capítulos
= cuánto merece la pena el capítulo si solo quieres las ideas (de 0 a 3 cubos). Haz clic en una tarjeta para saltar.
Resumen
German Del Zotto cuenta en Madrid.rb, en octubre de 2018, por qué en Jobandtalent quitaron la gema webpacker de sus aplicaciones Rails y se quedaron con Webpack a secas. La charla mezcla la historia, los problemas concretos que les dio la configuración por defecto y una demo del flujo de desarrollo, CI y release que montaron 1:22.
Las librerías de JavaScript ya no se bajan en un zip para copiarlas a vendor. Hay que transpilarlas, y Webpack resuelve eso además de los módulos, el tree shaking y el chunking 2:54. Webpacker llegó con Rails 5.1 como solución cero config, y funciona muy bien mientras tu setup se parezca al de Basecamp 6:05.
Cuando no se parece, aparecen los problemas. La gente de frontend tiene que leer generadores Ruby del repo de Webpacker para añadir un loader, el troubleshooting es tortuoso y la versión de Webpack queda atada a la gema, como un plugin que pedía Webpack 3.7 cuando Webpacker iba por la 3.3 7:32. A eso se suman CDNs, hostnames y puertos, entornos compartidos para demos, proxies y VPNs, y servidores donde nadie quiere instalar Node 9:09. En su caso además corren varias aplicaciones en local a la vez, tienen staging, clústeres, CDN y rollbacks, y la configuración se convierte en una traducción continua entre el snake_case de Rails y el camelCase de Node 12:16.
La alternativa resultó sencilla. Webpacker era Webpack más un helper de Rails que lee el manifest.json, así que mantuvieron los mismos tags en los ERB y dejaron que Webpack escriba el manifest con los hashes 15:31. El precio es arrancar dos procesos en desarrollo, el servidor de Webpack y el de Rails. A cambio, todo el JavaScript y su configuración quedan en package.json, a la vista de quien hace frontend, y los errores dejan de esconderse dentro del proceso de Rails 18:21.
La demo enseña hot module reload con React conservando el estado 23:20, linters y tests de JavaScript en modo watch 24:48, y tests de Rails y de sistema con Capybara contra un servidor de Webpack para tests que recompila en vivo y avisa si el manifest es viejo 33:44. El repo de ejemplo, commit a commit, lo iba a publicar al terminar la charla 20:31.
El CI tiene que ser rápido, simple y confiable, porque si está en verde va a producción. Lo tienen dockerizado, con build, linters, tests, Brakeman, bundle audit y chequeo de vulnerabilidades en cada commit 36:20. Lo muestra con un Docker Compose y un script en Ruby que imita el CI en menos de dos minutos 39:16. Para el release, una imagen construye el JavaScript y la imagen de Rails queda limpia, sin Node ni V8, así que es más pequeña, usa menos memoria y tiene menos superficie de ataque. Los assets van a un CDN y Puma no sirve ningún fichero estático 44:41.