¿Por qué los componentes de Bower están instalados en wwwroot? Gulp, bower, asp.net-core

Ha pasado un tiempo desde que jugué con ASP.NET 5, así que fue una sorpresa para mí que los componentes de Bower estén ahora por defecto instalados. wwwrootlib carpeta. Este es el caso debido a la .bowerrc archivo:

{
"directory": "wwwroot/lib"
}

En versiones anteriores los componentes de la glorieta se almacenan en el ./bower_components carpeta, que todavía tiene más sentido para mí.

Espero que necesito un gulp/grunt (con wiredep por ejemplo) tarea para compilar y copiar mis archivos JavaScript y CSS en wwwroot carpeta.

Claramente me estoy perdiendo algo, pero no puedo entenderlo ni encontrar información adecuada sobre este asunto.

¿Por qué quiero todos mis componentes de la glorieta (incluyendo fuentes) en la carpeta `wwwrootlib", especialmente durante la implementación, y cuál es el flujo de trabajo deseado al implementar mi aplicación web Asp.NET 5?

Respuestas

Creo que la razón por la carpeta bower_componentsse abandonó y ahora usa wwwroot / lib porque no importa si, en desarrollo o producción, los archivos estáticos deben vivir debajo de wwwroot; de lo contrario, después de cada edición de un archivo, debe ejecutar taskrunner nuevamente para copiar el archivo a continuación. Es un flujo de trabajo más eficiente si las versiones de desarrollo y de producción de los archivos se encuentran en algún lugar debajo de wwwroot. de esa manera puede editar y actualizar la página en lugar de editar runrunner ejecutar y luego actualizar la página.

Lo que sugiero es convertir los archivos de proceso en una carpeta diferente, como wwwroot / js, al crear versiones de producción minimizadas / procesadas de sus archivos.

Luego, la carpeta wwwroot / lib podría incluso excluirse de la publicación, ya que solo las versiones dev de los scripts de biblioteca vivirían allí.

Estoy pensando en mis propios scripts personalizados que no sonLos componentes de Bower probablemente no deberían vivir bajo wwwroot / lib, así que tal vez ponga los no minificados bajo wwwroot / dev y procese todo el material de producción bajo wwwroot / js para que en la producción solo despliegue la carpeta wwwroot / js que tiene la versión de producción minified / combined archivos. Así que básicamente hacemos nuestros propios paquetes de esa manera.

Las nuevas etiquetas de entorno y el script taghelper permiten señalar fácilmente diferentes ubicaciones de archivos para desarrollo y producción como se ve en este ejemplo:

<environment names="Development">
<script src="~/lib/jquery-validation/jquery.validate.js"></script>
<script src="~/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.js"></script>
</environment>
<environment names="Staging,Production">
<script src="//ajax.aspnetcdn.com/ajax/jquery.validation/1.11.1/jquery.validate.min.js"
asp-fallback-src="~/js/lib/jquery-validation/jquery.validate.js"
asp-fallback-test="window.jquery && window.jquery.validator">
</script>
<script src="//ajax.aspnetcdn.com/ajax/mvc/5.2.3/jquery.validate.unobtrusive.min.js"
asp-fallback-src="~/js/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js"
asp-fallback-test="window.jquery && window.jquery.validator && window.jquery.validator.unobtrusive">
</script>
</environment>

Así que tienes formas fáciles de usar un cdn en producción. Tenga en cuenta que para los archivos que no son CDN, no puede apuntar a ningún otro lugar que no sea wwwroot o alguna carpeta a continuación, por lo que tener archivos en una carpeta de bower_components fuera de wwwroot no es una ubicación donde pueda apuntar a scripts, por lo que no tiene sentido colocar archivos allí.

Al hacer enlaces de guiones a la versión dev de misecuencias de comandos personalizadas Me gusta usar el nuevo atributo taghelper asp-append-version = "true", que agrega un hash del contenido del archivo a la url, lo que garantiza que la memoria caché del navegador anterior se omite cada vez que se edita o modifica el archivo. Y esto sucede sin necesidad de ejecutar taskrunner, solo edito y actualizo la página.

Así que en resumen teniendo todos los scripts a continuaciónwwwroot es un flujo de trabajo mejor que tenerlos en otro lugar y la necesidad de ejecutar taskrunner para moverlos después de cada edición. Si no desea implementar todo el extra de navegación desde debajo de wwwroot / lib, procese lo que desea en una carpeta diferente con taskrunner, lo mismo que tendría que hacer si estuvieran fuera de wwwroot en una carpeta de bower_components tal como se usaron para estar en las primeras versiones beta. Y excluir wwwroot / lib de la publicación con publishExclude en el project.json de su aplicación web.

Han sido trasladados allí porque Microsoft fueviendo mucha confusión por los desarrolladores de .NET que no estaban acostumbrados a las nuevas herramientas. Simplificaron esto para los desarrolladores de .NET al colocar esos componentes en wwwroot en lugar de tener que ejecutar una tarea para moverlos. Mi fuente para esto (y una explicación para cambiarlo al comportamiento anterior) proviene de (empleado de MS) Scott Hanselman "s entrada en el blog.