关于项目更新与封装

[pincman]

首先感谢作者的无私奉献，目前已经投入两个项目的生产使用，毋庸置疑，在速度,ui适配和使用体验来说已经远远超过蚂蚁的antd pro。所以后续我们打算把所有产品的中后台使用vben重构。
但是在使用中遇到一个比较棘手的问题，提出一些建议

因为已经投入生产环境，但是当前仓库一经更新，我们本地项目的代码就跟不上了，也需要同步更新。比如日前客户需要暗黑主题在线切换，前面我们是直接整个antd打包两个css文件的方式实现。等到作者放出更好的通过css变量的方案来实现我们打算全面更换，但是要更改的地方就非常多，并且无论查看仓库还是官方文档都没有一个有效的更新说明，花了非常多的时间去修改才搞定。
以上只是一个例子，还有从beta版开始，我们非常多的精力都花在跟着仓库同步更新上，因为官方仓库没有任何更新说明，差不多每天代码都在更新，使用者也必须至少两三天查看commit来更新，这个非常不方便

并且目前vben的代码碎片化也比较严重，很难统一管理

所以提出更改方案的几项建议，希望可以供作者参考

关于src运行时代码：

• 类似Antd pro那样把布局和一些常用的hooks等抽出来做成monorepo发布,比如单独一个vben-components，包括vben-layout,vben-card,vben-table,vben-charts等到库，需要更新时，只要pnpm update vben-xxx,然后改几个api就行
• 对于非远程加载的数据,比如settings等，抽出单独的组件,使用类似react中useContext,useRedcuer这样的hooks封装,而不要用vuex统一管理

关于build开发代码: 尽量把所有的插件和配置等都提取出来打包到一个仓库里，只要在vite.config.ts里引入一个import vbenconfig函数就行,接着放出几个自定义配置的选项就行

关于文档: 尽量把每次更新和调整的API写进去，这样方便升级

最后再次感谢作者提供这么好的后台，让管理系统开发工作量减少很多

[M69W]

估计没有关注最新的更新
vuex 已经被 pinia 替换了
其他的不了解，楼下继续

[anncwb]

抱歉，给你们造成了麻烦。

• 在更新上面，这个我一直没有好的办法，我看了很多别的开源框架，基本都是不能同步更新，所以更新这块一直是个问题，文档提供了一种方式来合并代码。但也不是最好的方式。后面我在看看有没有别的方式来，或者是按你说的只更新项目依赖这样。
• 对于src组件抽取成第三方依赖这种，可能会等项目在稳定点，且我有时间优化组件后在来抽取，现在的组件对我来说只能说是比较粗糙，自我感觉达不到组件抽取的程度，依赖可能也会比较耦合。所以可能会在3.0做一次抽取，时间也暂未定。
• 关于文档，后续的更新我会尽量写详细

这个问题我开着，有什么建议可以提出来

[pincman]

现在就管理面板本身功能而言已经几乎完美，该有的都有了，平时用着挺舒服的，一更新就头大，所以代码还是暂时别更新了，有空更新更新文档，修复修复bug就行，等到3.0直接发布好了，就让我们没有心智负担的去用吧😄，大神，千万别再每日一更，正常人吃不消啊😅

xxx名言

最可怕不是vben出bug,是vben又开始更新了^v^

[teaka-xss]

git 可以创建一个上流 来同步vben代码吧，我现在就是这么用。

[pincman]

@teaka-xss 这样团队使用很容易出现问题的

[M69W]

要求合并代码的人熟悉项目吧，
同名文件对比差异，
底层的合并要注意一下。

正常都是改业务层代码

[fhmsha]

2.0到现在感觉还行，更新没遇到太大的问题，希望有更多功能和相应文档

[opamine]

还没用上，准备下个项目体验一把

[M69W]

文档再完善一些估计就好用了😅

[linjiacheng]

我现在是文档里的方式，参考代码用admin，开发基于thin，开新分支，同步到自己的git，有更新时从main合并，需要解决一下冲突。如果改动多，冲突多就要考虑cherry-pick了。还好作者代码整洁，提交规范，目前还没遇到什么麻烦。

[zhangfugui727]

大力开发中项目的思考

Commit频繁我觉得是个好事，vue3生态库都还没有稳定（甚至vue2to3的文档还在更新中，有的也只是提案状态），很多第三方库大多数处于beta中，甚至兼容性都达不到要求，相关问题解决方案选择很多，也没有固定下来，来回变动肯定的。如果现在不修改，以后很容易埋下技术隐患，产生技术债，影响到一大批将要采用的用户（当前还只是vue3的开始，后续vue3正式版后，将会有一大批用户进入），后面再修改，影响相当大，甚至需要考虑兼容。

照顾现有生产用户

不过为了照顾已经进行生产开发的用户，文档只可能尽量详细。同时建议熟悉项目的人员合并新功能，不用团队每个人都做这个工作，这样会好得多，特殊冲突可以查看Commit手动处理问题不大。相信大多数用户修改的也只是业务代码，公用代码可能只会客户化的时候修改一次，理论大多代码合并都非常简单，因此持续维护的项目，建议定期同步，避免以后重构工作量大，至于那种开发了不管的项目，其实更新不更新意义都不大。

另外对拆组件做依赖库的思考

感觉拆组件做依赖库确实有点早了，很多组件比较零碎，有的可能非常简单，就几行代码，有的通用性又不够强，达不到拆分的条件，有的组件交互又太强，不像antpro那种result通用性特别强的组件，甚至拆分组件后维护和修改相对来说成本更高，就像刚才说的那样，它可能几行代码。拆分组件将产生数十个新项目，对作者维护来说真的成本太高了，价值回报低，更新好文档相比拆分来说更有价值。

下一个版本

类似做成vben.config.js的方式来说，更复杂，等vue和基础代码以及组件大规模使用稳定后修改也是可以的。

以上只是自己的个人想法，仅供参考，另外谢谢作者的辛苦付出。

[pincman]

@zhangfugui727
已经放弃vue3,滚回React了,vue3的写法一言难尽，还是React的TS支持完美，写起来纯粹，畅快。。。尤其我们这样的团队，分工通过服务来分而不是前后端来分，也就是每个人都是在用ts写前后端，后端除了少量cpu密集的场景用golang外大部分是用的nestjs这种纯ts框架，所以前端需要TS支持非常好的框架，vue3目前来看真的难以胜任ts全栈开发，还是合适spring boot/laravel+vue这样的组合。
但vben项目的价值还是非常大的，样式可以拿来枪，各种vben作者写好的vite插件可以用(尤其vite-theme简直神了)，感谢作者的贡献。

目前我在尝试搭建一个
vite+pro components+windicss+antd+antd charts+
vben的所有插件样式的通用后台,
再套上react router,rematch,swr等然后加上各种hooks，那写起来是真的爽。

建议如果觉得vue3的生态目前不够成熟，可以尝试一下React+vite+pro components,然后抄袭vben的各种vite插件和样式😄
为什么还是用React写东西好？因为不需要在组件里写hooks还要加个setup👍🏻
最后等vben3发布的时候再去尝试，作者加油💪🏻

[zhangfugui727]

@NanGongMo 祝贺，各个团队有各个团队的历史积累，适合就好，React也不错，NPM下载量长期也是居高不下，生态成熟稳定。

Vben也是我见过各种问题解决方案最完善，代码质量高，综合最好的前台模板，作者绝对是个对行业技术有敏锐感知，对项目功能质量及自己有所要求的人，现在的更新频率和MIT免费开源的精神，绝对可以期待一下。

感谢作者的开源贡献，加油。

[carl-jin]

估计没有关注最新的更新
vuex 已经被 pinia 替换了
其他的不了解，楼下继续

自从这次 Breaking changes 之后, 现在手中正在开发得项目, 就放弃了和vben-admin上游版本的同步.

因此再也不用担心作者更新了

[tomgao365]

@anncwb 这个项目相当的赞👍🏻，第一眼看到就很喜欢🤩，感谢作者。
看了看代码，和antd pro早期版本类似，所有的公共代码都在项目里，怕不方便迭代升级。
以前用react技术栈时，用antd pro做过一些项目，删除示例代码，然后开发。N个项目之后，放弃了公共代码的同步升级，如果赶上break升级会更痛苦😱。
期待作者能将项目拆分封装成类似pro-layout这样的组件，方便大家升级迭代，不知道作者有没有组件化的时间表？🤓

[tky753]

包管理器在V2.8.0 改用pnpm了，它自带了monorepo解决方案，
那下一步是不是就会把vben的组件转到一个独立项目，以monorepo的形式来管理项目？

[Aimumu]

@anncwb 感谢作者提供优秀的项目平台👍🏻
咨询一下，electron-main 分支会随着主版本更新吗，看到另一个分支是更新了的

[i7eo]

期待 components/layout 等文件的抽离，目前更新确实不方便

[kongsiyu]

@Aimumu 感觉就算抽离出公共的组件在升级上也难以避免大量的merge，毕竟为了契合自己的项目难以避免会修改一些基础框架和页面。可以考虑下在两个仓库开三个分支来合并两边的代码，这样虽然首次更新依然比较麻烦，但后续更新会容易很多。
大致思路：基于官方分支创建一个合并分支，并与当前项目代码分支进行合并，三个工作分支：官方分支，合并分支，开发分支（A、B、C表示），首次A copy B 然后 C merge into B解决主要冲突，后续更新只需要A merge into B，然后C merge into B，最后从 B pick 合并结果到 C就OK，这样保证了合并分支在pull 官方代码时候不存在冲突的同时保证了自己的开发分支C不会被官方commit污染

[anncwb]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days