ko在数栈中的应用
引言
一项技术能得以广泛运用,其中的一个关键点在于工程化。前端从最开始的简单写写网页和样式,发展为需要处理复杂的逻辑,伴随而来的是问题是相关文件越来越多,简单在网页中引用已经解决不了问题,需要相关的工程化工具来处理和优化这个流程。前端社区也涌现了较多的解决方案,例如rollup,parcel,webpack,esbuild等,在不同情况下都能较好的处理问题。这其中webpack因其微内核架构,在核心功能稳定且优秀的发挥情况下,开发者可以灵活的控制各个流程,使得其周边生态趋于多样和较为完善,逐渐成为各解决方案中的首选。
但是正是基于其微内核架构的灵活性,以及生态的多样性,使得其复杂度直线上升。缺乏经验的工程师往往对其配置等不太了解,浪费了较多时间解决配置问题,影响开发效率;同时如何更好的优化打包效率,也需要一定的积累。数栈前端团队基于webpack封装了ko,并在数栈指标管理,业务中心,消息管理中心等产品线陆续实践和优化,最终使得配置等问题更为简化,同时打包效率相比于之前有2倍以上的提升,较为完美的解决了如上问题。
整体架构
ko的整体架构如下所示:
整体上是一个monorepo,借助lerna与yarn workspace方便对包进行管理,其中:
- babel-preset-ko-app是针对于ko的babel preset,供babel-loader使用
- ko-config集成了eslint,prettier,stylelint等lint相关的配置和依赖,供ko-lints使用
- ko-lints集成了eslint,prettier,stylelint等lint相关的工具
- ko作为整个工具的入口,集成了ko-lints,并整合了dev与build相关核心功能
在数栈中的应用
从整体架构上来说,目前ko集成了打包和格式化相关的功能,那么ko在数栈中是如何应用的呢?我们以数栈产品业务中心的整个研发流程来举例。
develop
首先是开发流程,ko dev相关的可配置项如下所示:
- -p, --port <port>: 配置端口号
- --host <host>: 配置host
- -t, --ts: typescript支持
- -a,--analyzer: 使用webpack-bundle-analyzer进行打包结果分析
另外与之相关的是ko的配置文件ko.config.js,我们只需要在配置文件中添加如下内容:
module.exports = {
entry: ['./src/app.tsx'],
devServer: {
proxy,
host: '127.0.0.1',
port: 8082,
},
};
指定开发阶段的几个必要配置,并执行ko dev -t命令,就可以在http://127.0.0.1:8082看到程序正常运行
code review
在整个数栈的研发体系中,code review这个环节会先借助eslint来对代码写法等进行检测,检测通过之后再进行后续的review步骤,借助工具进行代码检测这个功能也被集成进了ko。
ko eslint相关的可配置项如下所示:
- -f, --fix: 开启自动修复
- -c, --config <path>: eslint自定义配置路径
- --ignore-path <ignorePath>: eslint需要忽略的文件配置路径,默认为.koignore
我们只需要执行ko eslint或者ko es就可以对代码格式等进行检测。ko默认集成了比较合理的eslint配置项,同时也可以使用-c, --config <path>配置项来自定义配置项。
与ko eslint类似的还有ko prettier和ko stylelint,分别是借助prettier和stylelint来对相关代码进行检测和格式化,使用方式和ko eslint基本相同
build
开发和code review结束并通过测试之后,我们可以将当前的版本内容发布到线上环境了,这时候就需要使用ko build将当前版本内容进行打包。
ko build相关的可配置项如下所示:
- --hash: 打包文件名添加hash
- -t,--ts,--typescript: typescript支持
- -e,--esbuild: esbuild支持,目前只使用了esbuild压缩相关功能
执行ko build -t命令 ,等待一小段时间后,打包结果会输出到当前目录的dist文件夹下
至此,整个研发流程结束,可以看到ko在数栈的整个研发流程中有着较高的参与度,涉及到了develop,code review与build三个重要的阶段。
效率提升
在保证整个研发流程稳定的情况下,ko在版本迭代的同时也对打包流程进行了优化,优化结果如下所示:
可以看到目前5.x版本的ko相比于4.x版本的ko在首次打包和二次打包的速度上有较为明显的提升
未来方向
前端目前还处于高速发展的阶段,社区中也涌现了如Vite,Rome等新的解决方案,ko在迭代的过程中也会不断的尝试新的技术运用与新的方向。在2022年,ko会尝试着针对以下几点内容进行发力,争取效率的提升与易用性的提升:
- 依托于webpack 5新增的module federation,尝试打包速度的提升与微前端的实践
- 更多的尝试esbuild相关功能,提升打包效率
- 制定更加细节的eslint等规则,服务于数栈各个产品线乃至社区
期待2022年ko做的更好,为数栈前端团队乃至开源社区贡献属于自己的一份力量

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
百度可观测系列 | 采集亿级别指标,Prometheus 集群方案这样设计
【百度云原生导读】在前一篇《基于 Prometheus 的大规模线上业务监控实践》中,我们为大家介绍了针对大规模业务监控场景,百度云原生团队基于 Prometheus 技术方案的一些探索,包括基于 Prometheus 进行指标降维、Prometheus 的自动分片采集、以及基于 Flink 流式计算构建的预计算。 本文将深入采集专题,为大家介绍如何构建采集亿级别指标的高可靠Prometheus 集群。 采集亿级别指标,通常会面临三大类问题:一是网络带宽打满、Prometheus大内存、Prometheus计算 CPU 利用率高等一系列资源类问题;二是如何构建高可用、高可靠的集群,如何确保监控数据的不丢不重等高可用类问题;三是集群的自动弹性扩缩,如何进一步降低运维成本等运维类问题。只有解决好这三类核心问题才能构建出一套理想的 Prometheus 采集集群。 为此,百度云原生团队针对 Prometheus 提出了“流计算加速”、“高可用HA”、“感知采集压力的自动分片管理”等多项“外科手术式打击”般的精准解决方案,最终实现了亿级别指标的采集。 下文将从“资源、高可用、运维”三个方...
-
下一篇
MASA Framework - DDD设计(2)
Clean Architecture 国内对于Clean Architecture的翻译很多,干净/整洁/清晰。但无论哪一种都说明了它简洁、清晰的特性。 早期它长这样 看到这张图的同学可能会对另外一张图有印象 洋葱架构(Onion) 现在长这样 看起来好像是亲戚,它们的确也有着千丝万缕的关系 分析Clean Architecture 这部分主要是根据explicit architecture文章的理解整理的,有翻译也有自己理解消化的。如有错漏欢迎指正,谢谢 三大构建块 用户界面 基础设施 应用核心 控制流 用户界面 应用核心 基础设施 应用核心 用户界面 工具 左右两侧形成鲜明对比,动机不同 HTTP/CLI:告诉应用要做什么 SMS/Mailing Server/Search Engine...:应用告诉它们要做什么 链接工具和交付机制到应用核心 将工具连接到应用程序核心的代码单元称为适配器(端口和适配器架构)。 告诉我们的应用程序做某事的适配器称为主适配器或主动适配器,而我们的应用程序告诉我们做某事的适配器称为从适配器或被动适配器。 端口 这些适配器为了适应应用核心的一个非常特定的...
相关文章
文章评论
共有0条评论来说两句吧...