/Born/一转眼，入职5年，一直在做开发与银行客户服务业务相关的中后台应用；日复一日相似度高的开发工作难免枯燥乏味，于是思考如何以更智能的方式全面优化和提升中后台应用开发效率。从以往的工作中提炼出三个要点，第一是Fast，需要极其敏捷的开发经验；然后是Easy，简单易上手，学习成本低；最后是Strong，代码健壮性更强，性能更优；by这构建了Fes.js，一个基于Vue3的前端应用程序解决方案。约定化、配置化、组件化的设计思路，让用户只关心用组件构建页面内容。技术曲线平缓，上手容易。经过多个项目的打磨，趋于稳定。丰富的Vue3生态和Fes.js插件让业务开发更加敏捷顺畅。/growth/Fes.js最初是在2020年开源的，定位只是中后端应用解决方案。现在增加了开发H5的功能，进化为一个通用的前端应用解决方案。接下来，我将和大家分享一下，Fes.js经历了哪些蜕变，完成了这次的迭代升级。希望可以作为大家的参考，也期待大家试用升级后的Fes.js。v1中大部分的后台和前端应用都要处理这些东西：构造、dev构建入口index.html入口main.js、初始化vue实例路由相关权限相关页面布局接口请求...当时CLI工具当时很流行，比如Vue-CLI和团队内部的mn，他们处理构建相关的事情，而其他的事情需要项目自己处理。那么开发新项目的步骤就是先复制旧项目，然后修改代码，再添加新功能。随着时间的推移，发现了一些问题：继承了“待优化”的代码。升级很费力，不如自己新建一套请求工具函数，十种写法，维护起来很累。然后提供一个框架，把这些通用功能封装起来，统一代码规范和代码组织，把代码的优化和升级交给框架。用户完全不必担心，v1版本可以完成所有这些事情。设计思路模块划分fes-cli是一个命令行工具，提供预编译、项目创建、开发调试、打包发布等能力。fes-core是一个运行时框架，提供固定的页面布局和API，用于权限管理、存储管理、路由管理、接口管理、状态管理、数据字典管理和环境管理。运行时扩展作为插件提供。fes-ui是一个组件库，包括30+个PC端组件库，可以快速构建增删改查等页面。使用全局安装命令wnpmi@webank/fes-cli-g在项目中声明依赖{"dependencies":{"@webank/fes":"^1.0.0"}}并运行根目录下的fes安装dependenciesdev后的项目从v1版本开始就诞生了。如果把开发应用程序比作盖房子，那么使用fes.js就相当于给你一个毛坯房。你只需要装饰v2。v1版本迭代运行一段时间后，遇到了一些问题：模块划分不合理v1版本对用户屏蔽了fes-ui的概念。用户不需要知道如何安装和注册这些组件。他们只需要在package.json中声明对@webank/fes的依赖，在代码中使用组件即可。理想很完美，现实却很骨感。fes-ui更新频繁，fes-core更新不频繁。当fes-ui不兼容更新升级大版本号时，由于@webank/fes依赖fes-ui，@webank/fes也必须升级大版本，这给@webank/的可用性和稳定性带来了挑战非斯。v1版本的全局fes命令希望用户在本地全局安装fes命令，在构建平台也可以全局安装fes命令，这样可以为不同的项目节省大量的安装时间。如果fes-cli很稳定，很少更新，那是可行的。然而现实是fes-cli也需要更新迭代。同时fes-cli提供的pre-build和mock能力需要项目配合。不同的项目可能需要使用不同版本的fes-cli。准备在v2版本解决以上问题。设计思路和运行思路与v1版本相同，需要做两处改动：1.将@webank/fes拆分为@webank/fes-core和@webank/fes-ui，将两个模块解耦2.将fes-cli改为Project启动，非全局安装。模块划分的用法在项目中声明依赖{"dependencies":{"@webank/fes-core":"^2.0.0","@webank/fes-ui":"^2.0.0",},"devDependencies":{"@webank/fes-cli":"^2.0.0",}}安装依赖后，运行项目根目录下的fesdevV2版本，将Vue从1.0升级到2.0，将webpack升级到4.0，带来更好的开发体验。v3在V2版本运行一段时间后，遇到了一些问题：扩展能力弱，V2版本封装了Vue的插件能力提供扩展。Vue插件在运行时做事，不能在构建时做事。比如我想从src/icons文件夹下的svg文件自动生成并注册Vue组件，Vue插件是做不到的。它需要在构建阶段扫描图标文件夹并根据文件名生成额外的代码。把fes.js用得太扎实，就像装修毛坯房，布局固定，加各种东西。时代在变，用户想要更好的居住体验，不满足于毛坯房的格局，但是fes.js无法改变格局。为了解决这些问题，fes.js首先需要加强扩展能力，让插件支持runtime和buildtime。二是不再固定毛坯房的布局，而是将毛坯房的房间抽象成一个插件，让用户自由选择使用什么插件来组成毛坯房。V3以插件机制重写所有代码。设计思路webpack等构建器在执行编译前，每个插件可以读取文件、配置、环境变量，执行相应逻辑后，将运行时代码写入.fes临时目录，然后添加运行时代码依赖到入口文件fes.js。通过这种方式，插件可以支持构建时和运行时的可扩展性。在这个架构下，核心逻辑是插件的生命周期管理。插件机制执行fesdev的运行过程：模块划分fes内置包preset-build-in和runtime，包括构建、路由、入口文件、runtime插件机制内容，不包含任何业务相关内容，于是fes.js从此变成了通用的前端应用解决方案。虚线包含的插件根据业务需要自由选择。比如后台应用的开发，布局可以使用fes-plugin-layout，权限设置可以使用fes-plugin-access。插件使用方法在项目中声明依赖{"dependencies":{"@fesjs/fes":"^2.0.0"}}安装好依赖后，运行项目根目录下的fesdevV3版本，将Vue升级到3.0和webpack到5.0，进一步优化了开发体验。同时发布了全新的基于Vue3的组件库FES-Design。FES-Design的设计体系还在不断探索中。希望通过未来更多的积累，为用户提供更好更专业的企业级产品设计系统。.V4在开发v3版本的时候，webpack刚刚发布了5.0.考虑到webpack生态，我们继续使用webpack作为builder，围绕webpack构建相关逻辑。近一年前端圈涌现出各种构建器解决方案，esbuilder、vite、tsc等，体验过vite后，感觉真??香，webpack根本打不过，如果你打不过吧，加入吧！设计思路v3版本中webpack相关的构建逻辑在包@webank/preset-built-in中，从中分离出来形成一个新的模块fes-builder-webpack，和一个新的模块fes-builder-vite是基于vite开发构建逻辑形成的。fes-builder-开头的包是一组负责处理构建逻辑的插件，会被优先加载，实现逻辑的方式还是基于插件机制。如何在项目中使用Declaredependencies{"dependencies":{"@fesjs/fes":"^3.0.0","@fesjs/builder-vite":"^3.0.0"}}在安装依赖后项目根目录运行fesdev/future/futurefes.js会变成，我不知道，我知道的是fes.js顺应潮流，变得适合它。fes.js和fes-design均开源，欢迎体验！fes.js:地址:https://github.com/WeBankFinT...文档:fesjs.mumblefe.cn/nextfes-design:地址:https://github.com/WeBankFinT...文档:fes-design.mumblefe.cn
