encore - symfony 4 assets

Diferencia entre assetic: volcado y activos: instalar

Question

En Symfony2, ¿cuál es la diferencia entre assetic:dump y assets:install ? ¿En qué escenarios se deben usar cada uno de estos comandos, y en qué orden (si el orden es relevante)?

Answer 1

De hecho, escribí sobre esto recientemente en un artículo sobre OroCRM, que está basado en Symfony 2. Si quieres algo del contexto / por qué de los diferentes comandos, puede que te resulte interesante.

Hay dos sistemas diferentes para incluir archivos frontend (javascript, css, images, etc.) en una aplicación Symfony. El assets:install comando de assets:install fue lo primero. Este comando buscará todos los paquetes de Symfony en una aplicación para un

Resources/public

carpeta. Si se encuentra, el comando assets:install copiará o vinculará archivos desde Resources/public a web/public/bundle/[bundle-name] . Aquí es donde los enlaces creados con la función de assets twig buscarán estos archivos. Esta

<script src="{{ asset(''js/script.js'') }}" type="text/javascript"></script>

Se convierte en esto

<script src="/bundles/[bundle-name]/js/script.js" type="text/javascript"></script>

Eso es todo lo que hace el sistema de assets . Te permite almacenar tus archivos de frontend con el paquete.

El sistema de assetic es diferente. Con assetic , puedes vincular a archivos como este.

{% javascripts ''@AcmeFooBundle/Resources/public/js/foo.js'' %}
<script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}

Hay etiquetas similares para hojas de estilo e imágenes. Tenga en cuenta que assetic permite vincular a archivos en cualquier paquete. ( @AcmeFooBundle ). Assetic también te permitirá vincular a varios archivos en una carpeta con un comodín.

{% javascripts ''@AcmeFooBundle/Resources/public/js/*'' %}
<script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}

Otra diferencia con assetic es en los enlaces generados. En el entorno de desarrollo se verán algo como esto.

<script type="text/javascript" src="/app_dev.php/js/foo.js"></script>
<script type="text/javascript" src="/app_dev.php/js/bar.js"></script>

Es decir, las solicitudes de estos archivos se ejecutarán a través del controlador frontal de PHP ( app_dev.php ) a través de la configuración de rutas especiales en el paquete de assetic . Esto significa que, cuando estás en el modo de desarrollo, nunca necesitas volcar tus recursos. Están incluidos automáticamente. También le permite aplicar filtros a los archivos. Por ejemplo, lo siguiente aplica el filtro cssrewrite a los archivos cssrewrite .

{% stylesheets ''bundles/acme_foo/css/*'' filter=''cssrewrite'' %}
<link rel="stylesheet" href="{{ asset_url }}" />
{% endstylesheets %}

Si alguna vez quiso modificar de forma programática la salida de sus activos frontend, assetic permite hacerlo escribiendo filtros assetic personalizados.

Sin embargo, esto es un rendimiento intensivo. En producción, en lugar de vincular cada archivo individualmente a través de un archivo de controlador frontal PHP, el HTML generado se verá así:

<script type="text/javascript" src="/js/as5s31l.js"></script>

¿De as5s31l.js viene as5s31l.js ? Eso es lo que hace el assetic:dump . Combina todos los archivos javascript / css individuales (después de aplicar los filtros) y crea un archivo bonito, estático y almacenable en caché para producción.

Qué necesitas hacer

A menos que el proyecto específicamente indique lo contrario, siempre debe ejecutar assets:install y assetic:dump , porque nunca sabrá cuál de sus paquetes de terceros usa estos comandos. Solo necesita ejecutar assetic:dump antes de implementar o ver la aplicación en modo prod . El orden es irrelevante.

En cuanto a qué sistema debe usar su paquete, si ha leído lo anterior y no está seguro de qué puede hacer el assetic por usted, use assets . Estarás bien.