HarmonyOS NEXT应用开发，关于useNormalizedOHMUrl选项的坑

起因是这样的：我这库打包发布出问题了，这个有遇到的吗？

 源码里面就没有 request .d.ts,这打包后哪来个这文件？且漏掉了其他文件。

@猫哥csdn.yyz_1987 为啥我打包的har里面，只有接口，没有具体实现呢？

最后发现有个配置，改下就行了：useNormalizedOHMUrl配置为true.

具体实现应该打进了二进制包里面了,点ABC ， 后缀的那个文件。

原因解释：

新版本的devstudio在打包时默认这个选项为true,打出来的是字节码包，不在包含源文件。

之前版本的devstudio这个选项默认是fasle.

文档地址：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/ide-hvigor-build-har-V5

设置为fasle，这样打出来的包，默认不会被压缩编译为字节码。

发布HAR库，搞成字节码确实性能会好一点，且省去了编译步骤，就是调试想进去看源码费事点。我的准备打包为带源码的方面看。但字节码这个有个要求，就是使用者，也需要把useNormalizedOHMUrl设置为true.但好在后续新的devstudio默认这个值就是true。

useNormalizedOHMUrl表示是否使用标准化的OHMUrl（OHMUrl的定义参考以下说明）格式，标准化的OHMUrl统一了原有OHMUrl的格式。使用集成态HSP和字节码HAR需使用标准化的OHMUrl格式。
true：使用标准化的OHMUrl格式。
false（缺省默认值）：不使用标准化的OHMUrl格式。

因此，设置"useNormalizedOHMUrl": true后，对项目的检查比较严格，不能相同资源出现不同引入方式，需要资源统一。

具体属性说明可以查看文档：
build-profile.json5：文档中心
构建字节码格式的HAR：文档中心

所以当hvigor错误：当useNormalizedOHMUrl不为true时，不支持字节码HARs:[@cashier_alipay/cashiersdk]。

尝试以下操作：

请检查项目级build-profile.json5文件中使用的Normalized OHMUrl。

解决方案：

在项目根节点的编译配置build_profile.json5中，添加
caseSensitiveCheck
useNormalizedOHMUrl 为true

  "products": [{"name": "default","signingConfig": "default","compatibleSdkVersion": "5.0.0(12)","runtimeOS": "HarmonyOS","buildOption": {"strictMode": {"caseSensitiveCheck": true,"useNormalizedOHMUrl": true}}}

作者：猫哥 blog.csdn.net/qq8864，转载请注明出处。

团队：坚果派 团队介绍：坚果派由坚果等人创建，团队拥有12个华为HDE带领热爱HarmonyOS/OpenHarmony的开发者，以及若干其他领域的三十余位万粉博主运营。专注于分享HarmonyOS/OpenHarmony、ArkUI-X、元服务、仓颉。团队成员聚集在北京，上海，南京，深圳，广州，宁夏等地，目前已开发鸿蒙原生应用，三方库60+，欢迎交流。

其他资源

华为开发者问答 | 华为开发者联盟

鸿蒙 ArkTS 应用快速上手手册-w3cschool

https://atomgit.com/nutpi_tpc/bmi-calculator

华为开发者问答 | 华为开发者联盟

文档中心--常见编译报错指南