Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

编译很慢 #722

Open
Gpia opened this issue May 28, 2018 · 15 comments
Open

编译很慢 #722

Gpia opened this issue May 28, 2018 · 15 comments
Labels

Comments

@Gpia
Copy link

Gpia commented May 28, 2018

roadhog build很慢,现在已经达到了10分钟的级别。
有没有后续的优化方案呢


后续:
我创建了一个 react-demo 的项目 https://github.com/Gpia/react-demo ,供大家参考,包含常见的项目结构,dva 的使用,webpack的配置,代码检查,代码测试,mock数据等。
不再使用 roadhog,而是直接使用原生的webpack的配置。

@sorrycc
Copy link
Owner

sorrycc commented May 28, 2018

可以参考我写到一半的文章,https://hackmd.io/YHK_yuRtT0ePPVLY0_kUzw

@sunny920406
Copy link

我用antd-pro,之前使用roadhog,build的速度甚至已经达到了40多分钟(webpack直接报编译超时)。没办法只能自己配置webpack,推荐webpack@4,再用hard-source-webpack-plugin这个插件,速度有显著提升。

@Gpia
Copy link
Author

Gpia commented Jun 1, 2018

roadhog 是否能够升级一下底层的依赖,能够使用 webpack4, 并且内置一些高效的插件,来提升编译效率。
期待新版的 roadhog 能够解决

@52flutter
Copy link

@sunny920406 大佬可以发个迁移的demo吗

@sunny920406
Copy link

@YinRenjie1993 https://github.com/sunny920406/roadhogWebpack4 这个是我目前用的配置

@vipcxj
Copy link

vipcxj commented Jun 16, 2018

我也改用webpack4了,据说webpack4比起3,对编译速度做了重大改进,实际用下来也确实比3快多了,并且代码分割也做了巨大的改进。

@Gpia
Copy link
Author

Gpia commented Aug 8, 2018

目前我已经去掉了roadhog,直接使用了webpack4,编译时间由原来的10分钟以上缩短到2分钟以内。

@javahuang
Copy link

@sandwich99 感谢,之前突然 jenkins 编译直接报内存溢出,本地编译也得几分钟,从 rodhog 改成 webpack 之后大概 20几秒就编译完了

@notAugust
Copy link

@sandwich99 感谢,之前突然 jenkins 编译直接报内存溢出,本地编译也得几分钟,从 rodhog 改成 webpack 之后大概 20几秒就编译完了

能分享下roadhog转webpack的经验吗?

@chenhonghui
Copy link

@Gpia 求分享

@haoyinag
Copy link

haoyinag commented Oct 8, 2019

@Gpia @ @javahuang 同求转webpack的经验
现在打包要10分钟,出来的包36M
这如何能忍受

@Gpia
Copy link
Author

Gpia commented Oct 10, 2019

稍后我分享一个我直接切换成 webpack4 的配置,还在整理。

@haoyinag
Copy link

@Gpia cI

@WanderHuang
Copy link

最近也是因为ci构建慢(15 min左右),对工程做了一些改变(减到3 min),可以给大家一点思路。

背景:两年前的项目,基于dva。

方案

  1. webpack4替换了roadhog。这一点主要体现在package减少上,实际上编译速度从3min左右降到1min多,也不是很明显(当时是15min-18min的ci构建)。
  2. 继续深挖。因为ci构建每次都会执行npm install,所以看了一下,主要事件耗费在这了(12min)。但是服务器不应该是这么慢的(用的是内部registry)。因此看了一下package-lock.json,很多包竟然是请求的registry = "https://registry.npmjs.org/,这必然会有问题(最新的npm版本,会先查看package-lock,根据给定的地址和依赖关系去请求下载包或者更新包)。因此强行用内部源为仓库,执行npm install,然后更新package-lock,在去看,时间降低到了2min多一点,已经到了可以接收的地步了。

因此总结一下旧工程改造的方法:

  1. webpack 4,提升在于降低了包,完全用webpack 4大概比用roadhog少了500+个包,实际构建时间有提升,不大。至于构建,可以采用happypack + dllplugin,减少构建时间。用这个方便以后升级到webpack 5,以及更多的构建自由度(业务定制)。
  2. pacakge-lock.json这个文件一定要重视。因为一个团队内开发人员各有各的能力,因此最好是统一开发规范。目前方案是在根目录增加.npmrc文件,用于固定registry,然后要求发布上线的package-lock.json为最新。

效果:

  • 构建时间15min -> 3min
  • 依赖包数量2400 -> 1400(有的人删除包,但是又怕与别人冲突,不更新package-lock.json,造成包冗余)

建议有构建时间问题的兄弟可以看看这两个方向,应该会有点帮助。

@Gpia
Copy link
Author

Gpia commented Oct 17, 2019

我创建了一个 react-demo 的项目 https://github.com/Gpia/react-demo ,供大家参考,包含常见的项目结构,dva 的使用,webpack的配置,代码检查,代码测试,mock数据等。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants