出于某些考虑，koca前端框架未在项目中保留package-lock.json, 这导致底层依赖默默升级后，会引发一系列奇怪的问题，此类问题影响深远，通常出现问题后，会导致严重的后果，排查起来又非常浪费时间且没有规律，在此系列文档中，我们将对这些问题进行统一记录，希望以后再发生类似问题时能从中获取一些灵感。
日期：2022.06.08
问题发现方：港荣科技
问题描述：
升级KOCA-UI, KOCA-TEMPALTE版本后，导致调试时，工程src目录下的部分文件无法正常sourcemap
升级前：
szkingdom.yf.koca-template@3.1.0-1
szkingdom.yf.koca-ui@3.2.0-22
升级后：
szkingdom.yf.koca-template@3.2.1
szkingdom.yf.koca-ui@3.2.0
第一步，复现问题。
脚手架创建 以szkingdom.yf.koca-template@3.2.1，szkingdom.yf.koca-ui@3.2.0为基础依赖的工程项目，npm install，npm run serve, 问题复现，说明升级后sourcemap的问题确实存在。
第二步，分析问题
- 对于不能正常sourcemap的情况，我们初步推断有两个原因：
①KOCA-TEMPLATE,KOCA-UI开发的某些功能导致，另外值得关注的一点，在此期间对vue版本做了一次小升级vue, vue-template-compiler由2.6.11升级到2.6.14；
②底层的某些依赖偷偷的升级了。
前者比较好确定，验证起来也很简单，如果是后者，那我们又将再次面临排查比对哪些依赖偷偷升级了，排查难度对比前者会高很多。
第三步，解决方案的验证
- 对于第一点原因的验证：
①通过脚手架创建以升级前的框架版本为模板的项目，保证koca-template,koca-ui和升级前的版本一致。
npm install
npm run serve
发现同样无法正常的sourcemap.
除此之外，我们使用升级前的package-lock.json文件安装依赖，可以正常sourcemap
至此，基本可以断定是第二种原因。
-
如何排查底层依赖版本升级导致的问题。
比较两次package-lock.json 文件不同，这次还比较顺利很快找到，发现升级后的package-lock.json文件，多了一个
@ampproject/remapping的包。
关于此包的定义在npm有这样一段话：Remap sequential sourcemaps through transformations to point at the original source code. 可以参考npmjs
猜想是否由此包导致。
package.json无此包的显式声明，且升级前并没有此包，从依赖此包的上层包入手，阻断此包的安装，查找依赖此包的包，
升级后，
第一层，@vue/cli-plugin-babel@4.5.17， 升级前后此包版本一致,
第二层，@babel/core@7.17.10， 升级前为 @babel/core@7.15.8，
在package.json 中固定@babel/core@7.15.8
测试验证，解决问题。