Pourquoi Rails4 a-t-il abandonné la prise en charge du groupe «actifs» dans Gemfile


99

Dans Rails 3, les gemmes utilisées exclusivement pour générer des actifs dans le pipeline d'actifs étaient correctement placées dans le assetsgroupe du 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

Maintenant, selon la documentation de mise à niveau (toujours en cours) :

Rails 4.0 a supprimé le groupe d'actifs de Gemfile. Vous devrez supprimer cette ligne de votre Gemfile lors de la mise à niveau.

Effectivement, créer un nouveau projet avec RC1 donne un Gemfile avec des gemmes liées aux actifs incluses par défaut en dehors de tout groupe:

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

...

Cela signifie-t-il que ces gemmes seront désormais regroupées dans les versions de production par défaut? Si oui, pourquoi ce changement d'avis? Rails 4 évolue-t-il vers la génération dynamique d'actifs en production?


1
Je ne comprends toujours pas quel était le but du "groupe d'actifs", et ce qui a changé dans Rails 4 qui a rendu le groupe d'actifs inutile.
Michiel de Mare

23
Le «groupe d'actifs» était différent pour différentes personnes. Je l'ai utilisé comme un endroit pour mettre des gemmes dont je n'avais pas besoin dans la production. Mais à en juger par la conversation liée à la réponse acceptée, au moins certaines personnes du noyau de rails l'ont utilisée pour s'assurer que les actifs non précompilés échouaient avec un 404 en production (au lieu de générer automatiquement automatiquement ce qui conduirait à une mauvaise performance). Ce qui a changé, c'est que rails4 ne génère plus automatiquement d'actifs, donc la solution de contournement "groupe d'actifs" (comme le noyau de rails l'a vu) a été supprimée.
jemmons

C'est l'explication la plus claire à ce jour. Si vous le mettez dans une réponse, la prime est à vous.
Michiel de Mare

@MichieldeMare Je me sentirais bizarre de recevoir une prime pour ma propre question ;-) Si vous en avez envie, vous pourriez donner la prime à Filipe Giusti (la réponse acceptée) car il m'a aidé à comprendre.
jemmons

3
Un avertissement aux utilisateurs à l'avenir: si vous choisissez d'ignorer le guide de mise à niveau de Rails et de conserver le groupe d'actifs dans votre Gemfile, gardez à l'esprit que Rails n'aura plus automatiquement besoin du groupe d'actifs lors de la compilation d'actifs en production. Vous devrez soit le faire vous-même, soit ajouter RAILS_GROUPS=assets(voir Rails.groups) avant la commande pour précompiler les actifs en production dans votre environnement de construction.
Ajedi32

Réponses:


100

Auparavant, le groupe d'actifs existait pour éviter la compilation à la demande involontaire en production. Comme Rails 4 ne se comporte plus comme ça, il était logique de supprimer le groupe d'actifs.

Ceci est expliqué plus en détail dans le commit qui a changé cela. J'ai extrait quelques citations avec la réponse réelle.

Certains joyaux peuvent être nécessaires (en production) comme les barres de café si vous utilisez des modèles de café et le fait que maintenant les actifs ne sont plus précompilés à la demande dans la production.

(non précompilé à la demande en production) Cela signifie que si vous avez ces gemmes dans l'environnement de production dans 3.2.x et que vous oubliez de précompiler, Rails fera exactement ce qu'il fait en développement, précompilez les actifs qui ont été demandés. Ce n'est plus le cas dans Rails 4, donc si vous ne précompilez pas les actifs à l'aide des tâches, vous obtiendrez un 404 lorsque les actifs sont des requêtes.


32
N'était-ce pas aussi une économie de mémoire? Maintenant, toutes les gemmes, même celles qui ne sont pas nécessaires en "production" (uniquement en précompilation), sont chargées et donc les rails consomment plus de mémoire?
gucki

3
+1 @gucki et temps de chargement. C'était ma compréhension des groupes. Puisqu'il y avait déjà une option de configuration pour désactiver la compilation en direct de toute façon. Que signifie «soutien» ici. afaik my Rails 3 app avait une ligne dans env / prod.rb qui chargeait les ressources juste lors du développement. Si c'est tout, pouvons-nous simplement l'ajouter quand même?
Karthik T

Le groupe d'actifs est supprimé. Auparavant, les gemmes à l'intérieur des actifs étaient chargées en production, que se passe-t-il maintenant si nous en avons également besoin en production. Par conséquent, ils devraient être chargés en production, la suppression des actifs du groupe garantit cela. Les actifs doivent être précompilés avant de passer à la production.
prashantsahni

13

Rails 4 essaie de vous forcer à précompiler vos actifs avant le déploiement. Vous devez précompiler vos actifs avec

$ RAILS_ENV=production bundle exec rake assets:precompile

Et pourquoi? J'ai trouvé ceci dans le guide:

Par défaut, Rails suppose que les actifs ont été précompilés et seront servis en tant qu'actifs statiques par votre serveur Web.

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

Mais de nombreuses fois, vous devez utiliser ces gemmes «actifs» en production ... par exemple, si vous utilisez un fichier js.coffee dans votre répertoire de vues, alors Rails a également besoin d'un compilateur de café en mode production.

Donc, je suppose que la raison de ce changement est l'amélioration des performances ... et semble plus simple également. :)


22
Les rails supposant que les actifs ont été précompilés est un argument pour conserver le assetsgroupe, et non pour s'en débarrasser (si les actifs sont précompilés, ces gemmes ne sont pas nécessaires en production et ne doivent pas être incluses par le bundler). Et oui, vous utiliseriez peut-être un bijou comme coffee-railsen production ... mais c'était aussi le cas dans Rails 3, non? Et Rails 3 mis coffee-railsdans le assetsgroupe, par défaut. Alors pourquoi le changement pour Rails 4?
jemmons

1
Pourquoi utiliseriez-vous un fichier js.coffee dans votre répertoire de vues? Cela devrait aller dans assets / javascripts.
Marnen Laibow-Koser

3

Nous voulons coffeescript avec AJAX ( historique ), donc quitte coffee-railsle groupe des actifs.
sass-railsse comporte mal ( historique ), donc il sort du groupe d'actifs.

Axez le groupe des actifs.


2
CoffeeScript ne devrait pas être dans les vues. Vous pouvez faire Ajax sans cela. Vous n'avez pas besoin de générer dynamiquement JS pour faire Ajax. En fait, vous ne devriez pas générer dynamiquement JS. Précompilez vos fichiers CoffeeScript et évitez complètement le problème.
Marnen Laibow-Koser

1
sass-rails se comporte mal car il Bundler.require :assetsn'est pas exécuté. Ce n'est pas une raison pour supprimer le groupe d'actifs. Je ne veux pas de therubyracer, libv8 et c. sur la production, pourquoi quelqu'un fait-il? Le modèle Coffee peut être compilé dans un modèle JS, et il n'est pas utile de le compiler chaque fois qu'une nouvelle valeur est remplacée. Il est inutile de porter tout ce fardeau à la production.
phil pirozhkov
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.