Muy buenas, soy Luis y para hoy les traigo un artículo.
Índice
Internet Explorer va a desaparecer y todos se regocijan. Las actualizaciones automáticas del navegador y del sistema operativo mantienen a los usuarios actualizados.
Sin embargo, siempre habrá usuarios que visiten su sitio web con un navegador que no admita algunas funciones. Depende de su base de usuarios.
Si algunos de sus clientes son empresas empresariales, es posible que haya más de unos pocos usuarios que tengan que usar IE11
o un Mozilla Firefox realmente antiguo por alguna razón.
Si bien Google Chrome suele ser uno de los primeros en adoptar nuevas funciones de JavaScript, Mozilla Firefox y Apple Safari no siempre se mantienen al día con Google Chrome.
Aún así, admitir IE11
suele ser más difícil que admitir otros navegadores populares.
La esencia: si desea admitir una amplia gama de navegadores, incluidos los antiguos como IE11
, debe incluir polyfills
en su aplicación y asegurarse de que el navegador admita los archivos JavaScript que envía al usuario.
El incidente de IE11
Recientemente, nos topamos con un problema en el que nuestra aplicación no se iniciaba en IE11
en absoluto.
El problema se identificó rápidamente: parte del código no se transpiró como se esperaba, por lo que el usuario descargaría el código JavaScript, incluidas las funciones de flecha, que IE11 no admite en absoluto.
Sin embargo, es una molestia revisar su sitio web para verificar la compatibilidad de navegadores más antiguos. Si no posee una máquina con Windows, entonces sus mejores posibilidades son el uso de servicios como BrowserStack
o LambdaTest
. Sin embargo, esto suele ser bastante lento y engorroso.
Las pruebas de un extremo a otro simulan escenarios de usuarios reales, lo que le permite detectar errores rápidamente. Existen marcos de prueba populares como Ciprés.
Sin embargo, la ejecución de estas pruebas puede llevar algún tiempo y estas pruebas pueden ser más complejas y difíciles de mantener en comparación con las pruebas unitarias.
Aún así, tener al menos algunas pruebas de un extremo a otro brinda cierta confianza en que la aplicación funciona en su totalidad.
El problema con las pruebas de navegador automatizadas es que, si bien muchos marcos y corredores de prueba admiten las últimas versiones de Chrome y Firefox, los navegadores más antiguos como IE11
a menudo no son bien compatibles (por ejemplo, Transportador
) o no son compatibles (por ejemplo, Cypress
).
Esto significa que a menudo no es factible tener pruebas automatizadas que se ejecuten en todos los navegadores de uso común.
Un compañero de trabajo tuvo la gran idea de adoptar otro enfoque que sería mucho más rápido de implementar y proporcionaría al menos cierta seguridad de que el código de la aplicación también funciona en navegadores más antiguos.
La idea era poner en marcha otra verificación en nuestra tubería de integración continua para verificar los paquetes generados después de una compilación de producción.
Esto habría detectado problemas como el problema de la función de flecha antes mencionado antes de que el código se implementara en producción.
Por supuesto, esta simple verificación no puede proporcionar la misma validez que las pruebas manuales o automatizadas. Aún así, esta simple verificación evitaría que los desarrolladores envíen un código totalmente roto sin tener que verificarlo por nosotros mismos.
Los pasos básicos de una canalización de CI / CD
podrían verse así:
- Ejecute una compilación (por ejemplo, con Angular, podría usar
ng build --prod
). - Verifique los paquetes generados para ver si hay problemas. Si hay errores, el trabajo de CI debe marcarse como fallido y no continuar con los siguientes pasos, como la implementación.
- Continúe con los siguientes pasos (por ejemplo, implementación).
Encontramos una biblioteca práctica llamada ES Check
. Se puede instalar con npm como una dependencia solo de desarrollo, pero también se puede invocar usando npx
directamente.
Solo necesita apuntar al directorio de sus paquetes y decirle qué versión de ECMAScript (lea: JavaScript) desea admitir (por ejemplo, ES5
).
Este proceso no debería tardar más de unos segundos. Aquí hay un extracto explicativo tomado directamente de la documentación del proyecto:
«En las compilaciones modernas de JavaScript, los archivos se agrupan para que se puedan servir de manera optimizada en los navegadores.
Los desarrolladores asumen que el JavaScript futuro, como
ES8
, será transpilado (cambiado del JavaScript futuro al JavaScript actual) de manera apropiada mediante una herramienta comoBabel
.A veces hay un problema por el que los archivos no se transpilan. No había una forma eficiente de probar archivos que no se transpilaron, hasta ahora. Eso es lo que hace
ES Check
«.
Cómo verificar paquetes de JavaScript
generados con ES Check
Ahora que entendemos el problema, veamos cómo podemos incorporar ES Check
en nuestra canalización de CI
.
Aquí hay una canalización de CI
de GitLab simplificada:
# Run a full build aot build: image: node:12.18.3 script: # install dependencies - npm ci # run a full, production-ready build (this is a npm script) - npm run build:production # check es5 bundles for older browsers compatibility - npx es-check es5 ./your-dist-folder/*.js --verbose
El resultado de ejecutar ES Check
con éxito se ve así:
ES-Check: Going to check files using version 5 ES-Check: checking ./dist/common-es5.036d8a8f1d8ed1b18e05.js ES-Check: checking ./dist/main-es5.9c2c8a661140187e4316.js ES-Check: checking ./dist/modules-login-login-module-ngfactory-es5.91da0ff09285192d7330.js ES-Check: checking ./dist/modules-user-profile-user-profile-module-ngfactory-es5.68f5a6161704cb750f93.js ES-Check: checking ./dist/polyfills-es5.e3f8b2d4d82eeaed59a0.js ES-Check: checking ./dist/runtime-es5.934c3283cc8c6d77c916.js ES-Check: there were no ES version matching errors! 🎉
Si hay problemas, ES Check
hará que su trabajo de CI
falle, lo que le impide enviar un código que no funciona en absoluto en navegadores más antiguos.
Recientemente, he creado es-check-action
una acción de GitHub simple y configurable para automatizar este proceso. Las acciones son tareas individuales que puede combinar para crear trabajos y personalizar su flujo de trabajo.
Puede crear sus propias acciones o usar y personalizar acciones compartidas por la comunidad de GitHub. Esta acción de GitHub compara los archivos JavaScript con una versión específica de ES
.
Si la versión ES
de un archivo especificado no coincide con el argumento de la versión ES
, esta acción arrojará un error.
Conclusión
En este breve artículo sobre cómo comprobar los paquetes de JavaScript para compatibilidad con el navegador. Como puede ver, es fácil incorporar esta verificación rápida de paquetes como parte de una canalización de CI
.
Sin embargo, esto no elimina la necesidad de realizar pruebas manuales o automatizadas adecuadas. ¿Cómo se comprueba la compatibilidad del navegador con su aplicación web? Házmelo saber en los comentarios.
Gracias por leer este tutorial.
Añadir comentario