使用Bundler和Rails 4

时间:2016-09-28 19:35:43

标签: ruby-on-rails-4 asset-pipeline bundler precompile dev-to-production

问题

我们部署的应用程序中包含开发依赖项。我们有很多开发依赖项。这增加了生产中的工件大小和内存消耗,因为所有这些依赖关系都是require&#d; d。大多数实例都部署在云中,因此更多内存=更大的实例更多的钱。我们希望减小大小/内存,并在部署的工件和开发环境之间进行更明确的分离。特别关注的是生产环境中therubyrhino的需求,即使我们的资产是预编译的。

上下文

This question有一些非常高度评价的评论提出了同样的问题(请参阅this onethis one),但我实际上并没有看到任何答案。

查看Rails upgrade guide,建议如下: enter image description here

同样,资产预编译使用以下命令完成:
RAILS_ENV=production rake assets:precompile

如链接问题中所述,这意味着生产中需要所有宝石。从根本上说,这对我来说没有意义,我觉得我错过了一些明显的东西。资产预编译的重点是我们在生产中避免这样做,所以这个命令(据我所知)应该是这样的: RAILS_ENV=development RAILS_ENV_TARGET=production rake assets:precompile
或者一些生意。

我已经阅读了关于旧Rails票证here的讨论,似乎没有回答这个问题 - 我们如何从生产环境中获取开发依赖?特别是一个用户总结了同样的问题here

  

对于我来说,在生产中使用像biubyracer这样的东西的记忆膨胀是很糟糕的,特别是如果预编译是核心推荐和此时广泛持有的最佳实践。许多人可能永远不会停止考虑,如果他们在资产组移除后来到Rails,或者从未考虑过为此目的而进行过多考虑,甚至会发生这种情况 - 至少在生成的Gemfile中有一个暗示性的评论可能是好的想法。

     

现在,开发人员可以解决这个问题,因为他们知道在生产Web或工作进程中不需要宝石,因为加载组已从预编译任务中删除。我现在基本上将其作为新应用中的样板包含在内:    namespace :assets do # Override sprockets-rails task to put back assets group require, so as to # avoid memory bloat in web processes :-/ task :environment do Bundler.require(:assets) Rake::Task['environment'].invoke end end
  并将Bundler.require(*Rails.groups(assets: %w[development test]))还原为config/application.rb。真是一团糟。

     

仅供参考,du在我的机器上报告称为17MB,并且它不使用自动加载。我们没有使用任何CoffeeScript视图模板。

该评论的作者提出了一种解决方法,但后来在线程中,该策略讨论了缺陷,这让我很紧张。

TL; DR:

我们如何从生产运行时删除开发依赖项?或者,我错过了为什么这种能力是可取的/默认的?

1 个答案:

答案 0 :(得分:2)

我们如何从生产运行时删除开发依赖项?

您引用的主题中的

This comment包含启用旧:assets组行为的说明:

Bundler.require(*Rails.groups)更改为Bundler.require(*Rails.groups(assets: %w[development test]))中的config/application.rb,并将其添加到您的佣金任务中:

namespace :assets do
  # Override sprockets-rails task to put back assets group require, so as to
  # avoid memory bloat in web processes :-/
  task :environment do
    Bundler.require(:assets)
    Rake::Task['environment'].invoke
  end
end

或者,我错过了为什么这种能力是可取的/默认的?

因此,严格来说,这些不是开发依赖项。您不应该这样认为它们,因为资产预编译应该在生产环境中进行,即使它只是在部署期间。您绝对不应该在开发人员计算机上进行预编译。

最重要的是,自资产管道的早期版本以来,资产特定宝石和生产宝石之间的界限变得更加模糊。例如,许多宝石现在希望有一个javascript解释器可用。此外,许多Rails应用程序现在在视图中使用.coffee模板(而不是.js.erb),并且由于这些模板无法预编译,因此coffeescript必须在生产中可用。

基本上,随着rails贡献者开始从:assets组中删除越来越多的宝石,他们意识到它不再需要存在,并且如果它刚刚消失就会简化。它只是存在于第一位,以避免意外的按需编译,但资产管道在Rails 4中更新,以期望默认只提供静态资产。

最后它可能不是最优化内存的决定(因为你require你曾经使用过的一堆宝石,但它是最普遍的兼容性。

修改:有关此问题的更多讨论/答案,请参阅this question