¿Por qué Rails4 eliminó el soporte para el grupo "activos" en Gemfile?

En Rails 3, las gemas utilizadas exclusivamente para generar activos en la canalización de activos se colocaron correctamente en el assetsgrupo del Gemfile:

...

# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails'
  gem 'coffee-rails'
  gem 'uglifier'

  # See https://github.com/sstephenson/execjs#readme for more supported runtimes
  # gem 'therubyracer', :platforms => :ruby
end

Ahora, de acuerdo con la documentación de actualización (aún en progreso) :

Rails 4.0 eliminó el grupo de activos de Gemfile. Debería eliminar esa línea de su Gemfile al actualizar.

Efectivamente, hacer un nuevo proyecto con RC1 produce un Gemfile con gemas relacionadas con activos incluidas de forma predeterminada fuera de cualquier grupo:

source 'https://rubygems.org'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.0.0.rc1'

# Use sqlite3 as the database for Active Record
gem 'sqlite3'

# Use SCSS for stylesheets
gem 'sass-rails', '~> 4.0.0.rc1'

# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'

# Use CoffeeScript for .js.coffee assets and views
gem 'coffee-rails', '~> 4.0.0'

# See https://github.com/sstephenson/execjs#readme for more supported runtimes
# gem 'therubyracer', platforms: :ruby

...

¿Significa esto que estas gemas ahora se incluirán en construcciones de producción de forma predeterminada? Si es así, ¿por qué el cambio de opinión? ¿Rails 4 avanza hacia la generación dinámica de activos en producción?

asset-pipeline ruby-on-rails-4

— jemmons
fuente

Sigo sin entender cuál era el propósito del "grupo de activos" y qué cambió en Rails 4 que hizo que el grupo de activos fuera innecesario.

— Michiel de Mare

El "grupo de activos" era diferente para diferentes personas. Lo usé como un lugar para poner gemas que no necesitaba empaquetar en producción. Pero a juzgar por la conversación vinculada en la respuesta aceptada, al menos algunas personas en el núcleo de rieles lo usaron como una forma de asegurarse de que los activos no precompilados fallaran con un 404 en producción (en lugar de autogenerarse silenciosamente, lo que conduciría a una mala actuación). Lo que ha cambiado es que rails4 ya no genera activos automáticamente, por lo que se ha eliminado la solución alternativa del "grupo de activos" (como lo vio el núcleo de rails).

— jemmons

Esa es la explicación más clara hasta ahora. Si lo pones en una respuesta, la recompensa es tuya.

— Michiel de Mare

@MichieldeMare Me sentiría raro recibir una recompensa por mi propia pregunta ;-) Si te apetece, puedes darle la recompensa a Filipe Giusti (la respuesta aceptada) ya que fue fundamental para ayudarme a entender.

— jemmons

Una advertencia para las personas en el futuro: si eliges ignorar la guía de actualización de Rails y mantener el grupo de activos en tu Gemfile, ten en cuenta que Rails ya no requerirá automáticamente el grupo de activos al compilar activos en producción. Deberá hacerlo usted mismo o agregar RAILS_GROUPS=assets(ver Rails.groups) antes del comando para precompilar activos en producción en su entorno de compilación.

— Ajedi32

Respuestas:

100

Anteriormente, el grupo de activos existía para evitar la compilación a pedido no intencionada en la producción. Como Rails 4 ya no se comporta así, tenía sentido eliminar el grupo de activos.

Esto se explica con más detalle en el compromiso que cambió eso. Extraje algunas citas con la respuesta real.

Algunas gemas pueden ser necesarias (en producción) como rieles de café si está utilizando plantillas de café y el hecho de que ahora los activos ya no se precompilan bajo demanda en producción.

(no precompilado bajo demanda en producción) Significa que si tiene esas gemas en el entorno de producción en 3.2.xy se olvida de precompilar, Rails hará exactamente lo que hace en desarrollo, precompilar los activos que se solicitaron. Esto ya no es cierto en Rails 4, por lo que si no precompila los activos usando las tareas, obtendrá un 404 cuando los activos sean solicitudes.

— Filipe Giusti
fuente

¿No estaba también ahorrando memoria? ¿Ahora todas las gemas, incluso aquellas que no se necesitan en "producción" (solo en precompilación), están cargadas y por lo tanto los rieles consumen más memoria?

— gucki

+1 @gucki y tiempo de carga. Esta fue mi comprensión de los grupos ... Dado que ya había una opción de configuración para deshabilitar la compilación en vivo de todos modos. ¿Qué significa "apoyo" aquí. afaik mi aplicación Rails 3 tenía una línea en env / prod.rb que cargaba activos solo en desarrollo. Si eso es todo, ¿podemos simplemente agregarlo de todos modos?

— Karthik T

Se elimina el grupo de activos. Anteriormente, las gemas dentro de los activos se cargaban en producción, ahora, ¿qué pasa si también las necesitamos en producción? Por lo tanto, deben cargarse en producción, el grupo de eliminación de activos asegura eso. Los activos deben precompilarse antes de pasar a producción.

— prashantsahni

Rails 4 intenta obligarlo a precompilar sus activos antes de la implementación. Tiene que precompilar sus activos con

$ RAILS_ENV=production bundle exec rake assets:precompile

¿Y por qué? Encontré esto en Guide:

De forma predeterminada, Rails asume que los activos se han precompilado y su servidor web los servirá como activos estáticos.

(Fuente: http://edgeguides.rubyonrails.org/asset_pipeline.html#in-production )

Pero muchas veces tiene que usar estas gemas de 'activos' en producción ... por ejemplo, si usa un archivo js.coffee en su directorio de vistas, Rails también necesita un compilador de café en modo de producción.

Así que supongo que la razón de este cambio es la mejora del rendimiento ... y también parece más simple. :)

— Zoltan
fuente

Rails, asumiendo que los activos han sido precompilados, es un argumento para mantener el assetsgrupo, no deshacerse de él (si los activos están precompilados, entonces estas gemas no son necesarias en producción y no deben ser incluidas por el agrupador). Y sí, tal vez usarías una gema como coffee-railsen producción ... pero ese también fue el caso en Rails 3, ¿verdad? Y Rails 3 puso coffee-railsen el assetsgrupo, por defecto. Entonces, ¿por qué el cambio de Rails 4?

— jemmons

¿Por qué usaría un archivo js.coffee en su directorio de vistas? Eso debería ir en assets / javascripts.

— Marnen Laibow-Koser

Queremos un coffeescript con AJAX ( historial ), por lo que coffee-railsse sale del grupo de activos.
sass-railsse porta mal ( historial ), por lo que se mueve fuera del grupo de activos.

Elimine el grupo de activos.

— mockturtl
fuente

CoffeeScript no debería aparecer en las vistas. Puedes hacer Ajax sin eso. No es necesario generar JS dinámicamente para hacer Ajax. De hecho, no debería generar JS de forma dinámica. Precompile sus archivos CoffeeScript y evite el problema por completo.

— Marnen Laibow-Koser

sass-rails se porta mal porque Bundler.require :assetsno se está ejecutando. Esa no es una razón para eliminar el grupo de activos. No quiero therubyracer, libv8 et c. en producción, ¿por qué alguien lo hace? La plantilla de café se puede compilar en una plantilla JS, y no tiene sentido compilarla cada vez que se sustituye un nuevo valor. No tiene sentido llevar toda esta carga a la producción.

— phil pirozhkov