minificar archivos java javascript automation minify

java - minificar archivos js



¿Cómo se automatiza la minificación de JavaScript para sus aplicaciones web Java? (10)

Publicación de resumen

Si publica algo nuevo en este hilo, edite esta publicación para vincularla con la suya.

Me interesa saber cómo prefiere automatizar la minificación de Javascript para sus aplicaciones web Java. Aquí hay algunos aspectos en los que estoy particularmente interesado:

  • ¿Cómo se integra? ¿Es parte de su herramienta de compilación, un filtro de servlet, un programa independiente que procesa posteriormente el archivo WAR, o alguna otra cosa?
  • ¿Es fácil de habilitar y deshabilitar ? Es muy extraño intentar y depurar un script minificado, pero también es útil para un desarrollador poder probar que la minificación no rompe nada.
  • ¿Funciona de manera transparente , o tiene algún efecto secundario (aparte de los inherentes a la minificación) que tengo que considerar en mi trabajo diario?
  • ¿Qué minificador usa?
  • ¿Le falta alguna característica que pueda pensar?
  • ¿Qué te gusta de ello?
  • ¿ Qué no te gusta de eso?

Esto servirá principalmente como referencia para mis proyectos futuros (y con suerte otros SOer también lo encontrarán informativo), por lo que todo tipo de herramientas son interesantes.

(Tenga en cuenta que esta no es una pregunta sobre qué minificador es el mejor . Ya tenemos muchos a su alrededor).

Creo que necesitas una biblioteca de compresión, por ejemplo, la etiqueta Granule.

http://code.google.com/p/granule/

Se gzip y combina javascripts envueltos por g: comprime la etiqueta usando diferentes métodos, también tiene la tarea Ant.

muestra de código es:

<g:compress> <script type="text/javascript" src="common.js"/> <script type="text/javascript" src="closure/goog/base.js"/> <script> goog.require(''goog.dom''); goog.require(''goog.date''); goog.require(''goog.ui.DatePicker''); </script> <script type="text/javascript"> var dp = new goog.ui.DatePicker(); dp.render(document.getElementById(''datepicker'')); </script> </g:compress> ...

Creo que una de las herramientas mejores y más adecuadas para el trabajo es wro4j Consulte https://github.com/wro4j/wro4j

Hace todo lo que necesita:

  • Mantenga los recursos web del proyecto (js y css) bien organizados
  • Combínalos y minítalos en tiempo de ejecución (usando un filtro simple) o tiempo de compilación (usando el plugin maven)
  • Fuente gratuita y abierta: publicada bajo una licencia Apache 2.0
  • varias herramientas de minificación compatibles con wro4j: JsMin, Google Closure compressor, YUI, etc.
  • Muy fácil de usar Admite filtro de servlets, configuración Java simple o Spring
  • Soporte de JavaScript y CSS Meta Frameworks: CoffeeScript, Less, Sass, etc.
  • Validación: JSLint, CSSLint, etc.

Puede ejecutarse en depuración y en modos de producción. Simplemente especifique todos los archivos que debería manejar / preprocesar y el resto.

Simplemente puede incluir recursos combinados, minificados y comprimidos como este:

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

Escribí macros ant para el compilador Google Closure y el compresor Yahoo e incluí este archivo en diferentes proyectos web.

<?xml version="1.0" encoding="UTF-8"?> <!-- CSS and JS minifier. --> <!DOCTYPE project> <project name="minifier" basedir="."> <property name="gc" value="compiler-r1592.jar" /> <property name="yc" value="yuicompressor-2.4.6.jar" /> <!-- Compress single js with Google Closure compiler --> <macrodef name="gc-js"> <attribute name="dir" /> <attribute name="src" /> <sequential> <java jar="${gc}" fork="true"> <!-- - - compilation_level WHITESPACE_ONLY | SIMPLE_OPTIMIZATIONS | ADVANCED_OPTIMIZATIONS Specifies the compilation level to use. Default: SIMPLE_OPTIMIZATIONS - - warning_level QUIET | DEFAULT | VERBOSE Specifies the warning level to use. --> <arg line="--js=@{dir}/@{src}.js" /> <arg line="--js_output_file=@{dir}/@{src}-min-gc.js" /> </java> </sequential> </macrodef> <!-- Compress single js with Yahoo compressor --> <macrodef name="yc-js"> <attribute name="dir" /> <attribute name="src" /> <sequential> <java jar="${yc}" fork="true"> <arg value="@{dir}/@{src}.js" /> <arg line="-o" /> <arg value="@{dir}/@{src}-min-yc.js" /> </java> </sequential> </macrodef> <!-- Compress all js in directory with Yahoo compressor --> <macrodef name="yc-js-all"> <attribute name="dir" /> <sequential> <apply executable="java" parallel="false"> <fileset dir="@{dir}" includes="*.js" excludes="*-min*.js" /> <arg line="-jar" /> <arg path="${yc}" /> <srcfile /> <arg line="-o" /> <mapper type="glob" from="*.js" to="@{dir}/*-min-yc.js" /> <targetfile /> </apply> </sequential> </macrodef> <!-- Compress all css in directory with Yahoo compressor --> <macrodef name="yc-css-all"> <attribute name="dir" default="${build.css.dir}" /> <sequential> <apply executable="java" parallel="false"> <fileset dir="@{dir}" includes="*.css" excludes="*-min*.css" /> <arg line="-jar" /> <arg path="${yc}" /> <arg line="-v --line-break 0" /> <srcfile /> <arg line="-o" /> <mapper type="glob" from="*.css" to="@{dir}/*-min.css" /> <targetfile /> </apply> </sequential> </macrodef> </project>

  • Integración: <import file="build-minifier.xml" /> en su build.xml, luego invoque como tareas habituales de ant: <gc-js dir="${build.js.dir}" src="prototype" /> <yc-js-all dir="${build.js.dir}" />

  • Elección de dos minificadores: el compilador Google Closure y el compresor Yahoo, debe descargarlos manualmente y colocarlos cerca del archivo xml.

  • Los minificadores omiten archivos ya comprimidos (que terminan en -min* )

  • Normalmente hago tres versiones de script: sin comprimir (por ejemplo, prototype.js ) para la depuración, comprimido con el compilador de cierre ( prototype-min-gc.js ) para el servidor de producción, comprimido con Yahoo ( prototype-min-yc.js ) para la resolución de problemas porque el compilador de cierre usa optimizaciones arriesgadas y a veces produce archivos comprimidos no válidos y el compresor Yahoo es más seguro

  • El compresor de Yahoo puede minimizar todos los archivos en un directorio con una sola macro, el compilador de cierre no puede

Estamos utilizando la tarea Ant para minificar archivos js con YUICompressor durante la compilación de producción y poner el resultado en una carpeta separada. Luego cargamos esos archivos a un servidor web. Puede encontrar algunos buenos ejemplos para la integración de YUI + Ant en este blog .

Aquí hay un ejemplo:

<target name="js.minify" depends="js.preprocess"> <apply executable="java" parallel="false"> <fileset dir="." includes="foo.js, bar.js"/> <arg line="-jar"/> <arg path="yuicompressor.jar"/> <srcfile/> <arg line="-o"/> <mapper type="glob" from="*.js" to="*-min.js"/> <targetfile/> </apply> </target>

Esto funcionó para mí: https://bitbucket.org/m6_russell_francis/yui-compressor-ant-task/wiki/Home

<!-- minimize all static *.css & *.js content --> <target name="static-content-minify"> <taskdef name="yuicompressor" classname="com.metrosix.yuicompressor.anttask.YuiCompressorTask"> <classpath> <pathelement location="${jar.yui.compressor}"/> <pathelement location="${jar.yui.anttask.compressor}" /> </classpath> </taskdef> <yuicompressor todir="${build.static.content.min}" charset="utf-8" preserveallsemicolons="true" munge="true" > <fileset dir="${src.static.content}"> <include name="**/*.css"/> <include name="**/*.js"/> </fileset> </yuicompressor> </target>

Estoy escribiendo un marco para administrar activos web, llamado humpty . Su objetivo es ser más simple y más moderno que jawr o wro4j utilizando WebJars y ServiceLoaders.

¿Cómo se integra? ¿Es parte de su herramienta de compilación, un filtro de servlet, un programa independiente que procesa posteriormente el archivo WAR, o alguna otra cosa?

En desarrollo, un servlet procesa los activos según sea necesario. Los activos se precompilarían antes de la producción y se colocarían en una carpeta pública, de modo que la única parte que se utiliza es generar las inclusiones correctas en el HTML.

¿Es fácil de habilitar y deshabilitar? Es muy extraño intentar y depurar un script minificado, pero también es útil para un desarrollador poder probar que la minificación no rompe nada.

Eso se haría cambiando entre los modos de desarrollo y producción.

¿Funciona de manera transparente, o tiene algún efecto secundario (aparte de los inherentes a la minificación) que tengo que considerar en mi trabajo diario?

Creo que es transparente, pero favorece fuertemente el uso de WebJars.

¿Qué minificador usa?

Cualquiera que use el complemento que pones en tu classpath. Actualmente estoy buscando escribir un complemento para Google Closure Compiler.

¿Le falta alguna característica que pueda pensar?

Todavía prelanzamiento, aunque lo estoy usando en producción. El plugin maven aún necesita mucho trabajo.

¿Qué te gusta de ello?

La simplicidad de solo agregar una dependencia para configurar el marco

¿Qué no te gusta de eso?

Es mi bebé, lo amo todo;)

Estoy realmente sorprendido de que nadie haya mencionado a JAWR - https://jawr.github.io

Es bastante maduro y admite todas las características estándar que se esperan, y un poco más. Así es como se mantiene en contra de los excelentes criterios del OP.

¿Cómo se integra? ¿Es parte de su herramienta de compilación, un filtro de servlet, un programa independiente que procesa posteriormente el archivo WAR, o alguna otra cosa?

Originalmente, el procesamiento / levantamiento de pesas al inicio y la ejecución de la aplicación se basaba en un servlet . Comenzando con 3.x agregaron soporte para integrarse en el tiempo de compilación .

El soporte para JSP y Facelets se proporciona a través de una biblioteca de etiquetas JSP personalizada para importar recursos procesados. Además de eso, se implementa un cargador de recursos JS que permite cargar los recursos desde páginas HTML estáticas .

¿Es fácil de habilitar y deshabilitar? Es muy extraño intentar y depurar un script minificado, pero también es útil para un desarrollador poder probar que la minificación no rompe nada.

Hay disponible una opción de debug=on antes del inicio de la aplicación, y se puede especificar un parámetro GET personalizado en solicitudes individuales en producción para alternar el modo de depuración de manera selectiva en el tiempo de ejecución para dicha solicitud.

¿Qué minificador usa?

Para JS es compatible con YUI Compressor y JSMin, para CSS no estoy seguro.

¿Le falta alguna característica que pueda pensar?

SASS soporte de SASS viene a la mente. Dicho esto, admite LESS .

Intenté de dos maneras:

  1. usando un filtro de servlet. Cuando está en modo de producción, el filtro se activa y comprime cualquier información limitada a URL como * .css o * .js
  2. usando maven y yuicompressor-maven-plugin ; la compresión se realiza una-tantum, (al ensamblar la guerra de producción )

Por supuesto, la última solución es mejor, ya que no consume recursos en tiempo de ejecución (mi aplicación web utiliza el motor de la aplicación de Google) y no complica el código de la aplicación. Entonces asuma este último caso en las siguientes respuestas:

¿Cómo se integra? ¿Es parte de su herramienta de compilación, un filtro de servlet, un programa independiente que procesa posteriormente el archivo WAR, o alguna otra cosa?

usando Maven

¿Es fácil de habilitar y deshabilitar? Es muy extraño intentar y depurar un script minificado, pero también es útil para un desarrollador poder probar que la minificación no rompe nada.

lo activas solo cuando ensamblas la guerra final; en modo de desarrollo, verá la versión no comprimida de sus recursos

¿Funciona de manera transparente, o tiene algún efecto secundario (aparte de los inherentes a la minificación) que tengo que considerar en mi trabajo diario?

absolutamente

¿Qué minificador usa?

Compresor YUI

¿Le falta alguna característica que pueda pensar?

no, es muy completo y fácil de usar

¿Qué te gusta de ello?

está integrado con mi herramienta favorita (maven) y el complemento está en el repositorio central (un buen ciudadano maven)

Nuestro proyecto lo ha manejado de varias maneras, pero hemos seguido usando el compresor YUI a través de nuestras diferentes iteraciones.

Inicialmente teníamos un servlet que manejaba la compresión de JavaScript la primera vez que se accedía a ese archivo en particular; luego fue almacenado en caché. Ya contamos con un sistema para manejar los archivos de propiedades personalizadas, por lo que simplemente actualizamos nuestros archivos de configuración para permitir habilitar o deshabilitar el compresor según el entorno en el que estuviéramos trabajando.

Ahora los entornos de desarrollo nunca usan JavaScript comprimido para fines de depuración. En su lugar, manejamos la compresión en nuestro proceso de compilación al exportar nuestra aplicación a un archivo WAR.

Nuestro cliente nunca ha expresado su preocupación por la compresión y los desarrolladores no lo notan hasta que deciden depurar JavaScript. Así que diría que es bastante transparente con efectos secundarios mínimos, si acaso alguno.