记一次服务端打包：cannot read properties of undefined (reading ‘nodes‘)

排了两个小时的队，眼看就要轮到我做核酸了，然后微信群里测试大佬来了一句话：你不在没法搞下去了。

打开微信一瞅，一个截图，红彤彤的文字告诉我，这尼玛报错了。

cannot read  properties of undefined (reading 'nodes')

我们开发总共有三个环境：

测试环境

预发布环境

生产环境

因为在测试和预发布均不存在这个问题，到了生产环境才出现的，我的第一直觉是：后端数据不正确的原因，可能是生产还没来得及提供相关字段或者数据格式不对导致，但是看到这个bug又有点不确定，因为给我的感觉像是node打包的问题。但我又不在位置上，无法准确定位，所以开始使用排除法来解决了。然后开始了远程指挥：我都排队俩小时了。。。

我：“测试大哥看看接口有没有报错”
测试：“没有报错，正常返回”

我：“看这个有点像node的问题，运维大佬看看node版本”

运维：“node版本12”

我：“12啊，升个级看看，然后清掉所有文件再打包”（内心os：感觉也不是升不升级的问题，如果真的是版本问题，打不开全站那还差不多，就这么一个地方报错…）

升级后。。。

测试：“还是不行啊兄弟”

预料之中。。。

回到家准备开启远程，考！“十巷二号那个坏房东剪断了网线”，在我想房东抱怨咋没网的时候，房东一脸委屈的回了我。

第二天一大早回到公司，拎着大包小包的行李。开始排查（丫的搞不完就回不去了！）

1. 借助Ajax Interceptor谷歌插件排查是不是接口某个数据的问题，发现某个数据返回值为null，但是这个值是要被map遍历的，是不是它？把它改成空字符串试试，诶不报错了！爽，兼容性修改，提交，通告全群，搞定！

测试：还是不行啊
我：？？？

2. 继续琢磨，为啥不行？关闭Ajax Interceptor，再试，仔细看看发现，每个接口数据返回了，然后界面上相关的弹框也打开了，按理说都打开了应该没事啊，但就是在打开的那一瞬间，报错了，白屏了。嗯~~~摸摸小胡渣，头上飘动的三根发丝随风起舞，是不是没定位准？页面上三大块内容，接口返回三块，借助Ajax Interceptor我一块一块删掉接口数据看看是哪个的问题，恩找到了，级联地址的问题，但是几个环境的地址数据完全一样啊，这是为么事啊？知道是你了，继续挖。自定义组件一行一行看下去，没问题啊，难道是antd组件有问题？是不是antd级联组件不兼容啊？package都是一样的啊！仔细思考（跟媳妇聊个天）。

3. 想起当初那个月黑风高的夜晚，想起某个兄弟吼了一句：package-lock文件的不一致导致服务端打包与本地打包差异问题，我就有点这个想法了，不管如何还是让服务端于我本地的node版本先同步再说，然后本地打包让运维发上去，哟呵！不报错了！那八九不离十了，创建git的时候。package-lock是默认不上传的，所以服务端每次install的时候生成的package-lock与本地的不一致，而且两次版本发布的时间差不多都有半年了，加了很多东西，估计因为区别太大，package-lock差别也大吧。

解决：

1. 修改.gitignore文件，去掉/package-lock，允许上传

2. 提交新代码

3. 通知运维发版

4. 搞定（回家希望大大的有）

然后群通告一声：因为…所以…然后…现在…

package.json

该文件通常用于npm识别项目信息以及处理项目的依赖关系。也包含了别的数据例如，项目描述，项目特定发布的版本，许可信息，甚至是对npm包或者最终用户重要的配置数据。

package-lock.json

package-lock.json 在执行 npm i 的时候生成，用来记录实际安装的 npm 包的来源和版本。可以锁定安装时的包的版本，需要上传到 git，确保大家使用的包版本一致。

当npm有任何修改node_modules tree或者package.json的动作时，都会自动生成package-lock.json。他描述了要生成的具体的依赖树，因此不管中间的依赖项怎样更新，都能确保之后的安装都能生成相同的树。

该文件目的是被提交到源仓库中，并且有一下多种用途：

• 描述了一个单独表达的依赖树，因此确保你的队友，部署和持续集成能安装完全相同的依赖。
• 为用户提供了一个便利，使其“时间旅行”到node_modules之前的状态而不用提交本身目录。
• 通过可读的源代码控制差异而更好的看到树的变化。
• 允许npm跳过之前安装的软件包的重复数据解析，从而优化安装过程。

当执行npm install的时候，如果项目中有package-lock.json，那么就会从中解析所需安装的依赖，而不是通过package.json。参考

cnpm不支持依据package-lock.json文件安装模块，默认依赖package.json进行安装。

总结：

1. 平时没啥事的时候记得要摸鱼，摸摸别人的鱼，业务开发中自己不曾遇到的问题可能别人遇到过很多次了，不说全部记住知识点，但是在关键时候能有一个印象，能够找到方向去尝试解决，比自己没头绪的使用排除法要快得多。这次多亏自己摸鱼时候看到的文章（不是上面那个参考，不记得原文标题了），否则不知道要处理多久。

2. 项目中package-lock要Git提交跟着仓库走

3. 以后遇到相同类似的问题，可以先看看是否package-lock没同步的原因