HarmonyOS鸿蒙Next中最后一次针对ohpm的提问
HarmonyOS鸿蒙Next中最后一次针对ohpm的提问 这是我最后一次针对ohpm这个东西的提问,愿意改也好不愿意改也好以后都无所谓了。我从2023年API9开始鸿蒙开发,中间走过无数的坑。我见证了单框架从一个完全不能用的垃圾系统变成了现在这样至少还有一定可用性的系统。
关于ohpm相关的问题在这期间,我通过各种渠道反馈过不下于五次。每次的回答都是:
- 我们处于安全考虑,不放开xxx。
- 为了可用性,xxx
- 审核错误,请重新提交。
我不理解的点主要有两个:
- ohpm publish的命令为什么强制要走用户交互,不允许通过参数传入跳过用户交互。
这导致在开源社区发布必须经由人工发布,无法跟CI环境集成。 - ohpm发包为什么要有审核机制?
审核标准不统一,相同的内容有人通过,有人不通过。
部分无研发背景,很多逻辑从开发的角度来说配置没问题,但是审核不通过。
节假日审核员休息,新包无法上线。
包发布审核存在时间差,无法及时获取新包。
我到现在没有看到有一个操作系统或者语言的社区在核心仓发布一个包需要这么复杂。我很难想象这个社区要如何做才能变大。
劳烦相关团队看看以上问题应该如何解决?如果有必须的理由来做这些事情,是否可以提供相关理由,以及从开始到现在这样设计收到的实际正向反馈?
更多关于HarmonyOS鸿蒙Next中最后一次针对ohpm的提问的实战教程也可以访问 https://www.itying.com/category-93-b0.html
我感觉一个负责任的公司都会要求严格审查代码吧。毕竟是新兴的操作系统,扎实的基础库很重要。
更多关于HarmonyOS鸿蒙Next中最后一次针对ohpm的提问的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
如果能给出来这些问题的答案,我也没什么其他说的。
找HarmonyOS工作还需要会Flutter的哦,有需要Flutter教程的可以学学大地老师的教程,很不错,B站免费学的哦:https://www.bilibili.com/video/BV1S4411E7LY/?p=17
我们公司就搭建了ohpm私仓,非常的好用。
支持
支持
支持,官方需要给一个让开发者信服的理由!
额,
鸿蒙Next中ohpm是OpenHarmony包管理器,用于管理HarmonyOS应用开发中的依赖和共享包。它支持项目配置、依赖解析和资源分发,通过oh-package.json5文件定义项目信息。开发者可使用ohpm命令安装、更新或移除第三方库,确保项目模块化管理。该工具与HarmonyOS SDK集成,适用于ArkTS和JS开发,不涉及Java或C语言。
作为长期关注HarmonyOS生态的开发者,我理解你对ohpm工具链的反馈。针对你提出的两个核心问题:
-
关于ohpm publish强制交互问题
这确实影响了CI/CD流程的自动化。从工程角度看,交互式发布本意可能是防止误操作,但缺乏参数化选项确实限制了开源协作效率。建议团队考虑提供类似--non-interactive的参数,同时通过数字签名等机制保证安全性。 -
关于包审核机制
审核机制在生态建设初期确实有助于质量管控,但当前暴露的标准不统一、节假日停滞等问题确实存在。建议:- 公开明确的审核标准文档
- 建立自动化基础检查流程
- 设立紧急发布通道
- 组建技术背景更强的审核团队
生态建设需要在开放与管控间找到平衡点。目前这种强度的管控确实会影响开发者体验,希望团队能收集更多社区反馈,持续优化发布流程。开源社区的繁荣离不开高效的工具链支持,期待ohpm能尽快完善这些基础能力。

