[IMP] Eliminar en lo posible dependencias de terceros éstas deberían salir del generator o de algún cdn.

[nhomar]

Por @jgomo3 indica por slack.

Una cosa que me gustaría limpiar también, son las dependencias de tercero.
No deberíamos tener en control de versiones bootstrap ni nada .min

Estoy de acuerdo.

[hernanramirez]

De acuerdo,

¿Se resolvería haciendo link externo?

[jgomo3]

2016-02-07 5:38 GMT-04:30 J. Hernán Ramírez R notifications@github.com:

De acuerdo,

¿Se resolvería haciendo link externo?

Parcialmente. Al usar enlaces externos y CDNs, siempre deberíamos
proporcionar un plan b en caso de que esos recursos fallen.

—
Reply to this email directly or view it on GitHub
#91 (comment)
.

[satanas]

¿Cuál sería la solución completa? No me queda claro lo del plan B

[jgomo3]

Algo como:

• http://requirejs.org/docs/api.html#pathsfallbacks
• http://fallback.io/
• script de fallback a mano (alguna vez lo hice).

Todo lo que sea algo de terceros, debería ir declarado como dependencia. Durante el desarrollo, cada desarrollador bajará esas dependencias de alguna manera (npm install) y durante el despliegue a producción, travis haría el trabajo de obtener esas dependencias y ubicarlas en su lugar (grunt, gulp, webpack, etc.).

En el código, se haría referencia al recurso tanto en _CDN_s, páginas oficiales o copias que hospedemos en nuestro site (estas copias serían las que travis obtuvo durante el despliegue).

De esta manera, en nuestro control de versiones no estaríamos "manteniendo" código que no es nuestro.

¿Qué pasaría si durante el despliegue, el repositorio oficial de alguna dependencia, el CDN y cualquier otro sitio que definamos como fuente de descarga del mismo fallan?. Es decir, la misma pregunta para producción pero durante despliegue.

Este problema es casi irrelevante, ya que los despliegues no ocurren con la misma frecuencia que las visitas a la página. Pero, como ejercicio "mental", la solución sería hacer un último "fallback" a una copia que nosotros hospedamos. Sin embargo, esto pudiera contradecirlo todo, ya que estaríamos "hospedando" código de terceros. A menos que en vez de mantener esos recursos en nuestro control de versiones, dediquemos un espacio especializado para mantener copias de nuestras dependencias (puede ser otro repo). Es decir, nuestro propio "CDN".

Si instalamos nuestro propio "CDN" entonces travis no tendría que descargar ninguna dependencia. Ojo: esto no elimina la necesidad de que el código de la aplicación tenga una cadena de opciones con fallbacks en caso de que fallen algunas fuentes de recursos.

No creo que debamos llegar a cumplir con todo esto antes de deshacernos de las dependencias de terceros en nuestro control de versiones. Pudiéramos empezar a trabajar con lo que plantea @hernanramirez: "haciendo link externo". Pero hay que tomar en cuenta que esto implica que el desarrollador debe tener acceso prácticamente permanente (no intermitente) a Internet para poder trabajar.

Nota aparte:

Un asunto parecido es el manejo de multimedia. Aunque no son necesariamente dependencias de terceros, dado su gran peso y autoría particular[1](que pudiéramos considerar como independiente del proyecto: la página) pudiéramos sacar esos elementos del repositorio de la página a alguna galería de recursos multimedia. Es otro asunto a discutir.

[1] Con esto me refiero al hecho de que crear una imagen, video o sonido casi siempre es como un proyecto en si mismo, cuyo producto por lo general se utiliza en muchos otros proyectos compuestos: como libros, páginas web, artículos, juegos, software en general.

[nhomar]

Perrísimo @jgomo3

Configuren los css para que se monten con npm (eso no sé hacerlo).
Pero está buenísimo el concepto, de hecho en el único punto donde es irrelevante (cuando el npm falle) simplemente podemos tomar lo últimos funcionales compilados (opción 1) o simplmente "no desplegar" (opción 2 y no tendríamos que hacer nada por que travis estaría rojo).

Me gusta me gusta. Hazte un hola mundo y yo te sigo para la parte travis.

[hernanramirez]

@jgomo3 aparte de necesitar Internet para la disponibilidad de trabajar local y permanencia de la versión adecuada es critico. Ya me paso con un cambio de versión de jquery que detuvo un sistema en producción un fin de semana.

En muchos casos prefiero no depender de terceros para que la cosa funcione..