Rails 预编译死在 3MB 反应文件上

Posted

技术标签:

【中文标题】Rails 预编译死在 3MB 反应文件上【英文标题】:Rails pre-compile dying on 3MB react file 【发布时间】:2018-09-17 14:33:37 【问题描述】:

我们在 Rails 应用程序中使用 React on Rails。当我们部署时,资产预编译大约需要 20 分钟。

根据部署日志,似乎大部分时间都花在了预编译一个 3.3MB 的 javascript 文件上。该文件“app.js”连接了 webpack 生成的两个文件:

# app.js

//= require vendor-bundle (250KB)
//= require app-bundle  (3.3MB)

考虑到 app-bundle 的大小,我们是否应该期待较长的预编译时间?或者,我们可以改进吗?

作为补充说明,我们尝试直接编译 app-bundle,而不是通过 app.js 要求它,并且花费了相同的时间。

更新:

我们最终将客户端代码拆分为一个单独的 create-react-app 项目,该项目通过 API 连接到我们的 Rails 应用程序。我们的 devops 和部署管道的复杂性大大降低了——没有真正深入研究这个错误。

【问题讨论】:

20 分钟对于 3mb 的 js 文件来说太长了。您是否可能不小心预编译了 node_modules 文件夹中的内容? 绝对是 app.js 文件耗时 20 分钟。我们将其移除,整个部署过程耗时 3 分钟。 那么事情就大错特错了。绝对不是预期的行为。也许放弃资产管道,只使用可用于 webpack 的优化 听起来你需要一些调试帮助。我是 React on Rails 的创建者。我们有一个支持计划来帮助您。见shakacode.com/work/shakacode-pro-support.pdf 很难以这种方式评论,它需要调试,如果没有可重现的样本,很难说出可能是什么问题 【参考方案1】:

您绝对应该使用 webpacker gem (https://github.com/rails/webpacker) 集成 webpack

您也可以尝试查看 Shopify 的 Bootsnap gem (https://github.com/Shopify/bootsnap)

【讨论】:

以上是关于Rails 预编译死在 3MB 反应文件上的主要内容,如果未能解决你的问题,请参考以下文章

带有 Puma 和 Nginx 服务页面的 Elastic Beanstalk 上预编译资产的 Rails 4 应用程序以及旧资产链接

在 Heroku 上预编译资产时如何普遍跳过数据库接触

加速资产:使用 Rails 3.1/3.2 Capistrano 部署预编译

链接到 MacOS 上预编译的 QuantLib 二进制文件时未定义的 Boost 符号

如何解决极其缓慢的 rake assets:在 heroku 上预编译?

预编译咖啡脚本文件(Rails 4)