今天运行H5项目遇到报错:
Uncaught TypeError: _interopRequireDefault is not a function
去代码里一搜_interopRequireDefault
,懵逼了,我代码里并没有这个方法。
后来在报错检查里发现,是webpack里面的方法。
更懵逼了,我做了什么?webpack都报错了!
回想一下,我主要是导入了swiper库,做了个自循环轮播图的功能。但是这不是我第一次用swiper,以前也没出现这样的错。
而且奇怪的现象是,我本地运行是没有问题的,通过远程命令打包的方式就报错了。
问题解决方法一
后来发现是本地和远程打包生成的package-lock.json
文件不一致导致的。
一般情况,本地的package-lock.json
文件是不会上传到git的,所以远程打包时会重新生成这个文件,可能是npm源问题,或者是网络问题,导致远程新生成的package-lock.json
与本地生成的不一致。
解决办法是,把本地生成的package-lock.json
文件上传到远程目录进行打包,有了这个文件,远程就不会生成新的文件。
执行
npm run build
(根据实际情况可修改打包命令)
运行成功。
问题解决方法二
用上面的方法本来已经打好包了,不知道是因为我每次都提交package-lock.json
文件,还是服务器打包命令每次npm install
会改变环境。今天想打包给测试验证,发现又不行了。。。
没办法,只好另外开辟路子。
以下是来自前端大佬们的解决方案。
报错的原因是webpack编译出的源码里,_interopRequireDefault()
方法调用放在了初始化之前。因为var的变量提升,var _typeof2 = _interopRequireDefault(__webpack_require_
调用的的时候,_interopRequireDefault
还没有被赋值,是undefined。
var _typeof2 = _interopRequireDefault(__webpack_require__(/*! @babel/runtime/helpers/typeof */
"../../@babel/runtime/helpers/typeof.js"));
__webpack_require__(/*! core-js/modules/es6.number.constructor.js */
"../../core-js/modules/es6.number.constructor.js");
__webpack_require__(/*! core-js/modules/es6.object.prevent-extensions.js */
"../../core-js/modules/es6.object.prevent-extensions.js");
__webpack_require__(/*! core-js/modules/es6.object.seal.js */
"../../core-js/modules/es6.object.seal.js");
__webpack_require__(/*! core-js/modules/es6.weak-set.js */
"../../core-js/modules/es6.weak-set.js");
__webpack_require__(/*! core-js/modules/es6.array.sort.js */
"../../core-js/modules/es6.array.sort.js");
__webpack_require__(/*! core-js/modules/es6.object.is.js */
"../../core-js/modules/es6.object.is.js");
var _interopRequireDefault = __webpack_require__(/*! @babel/runtime/helpers/interopRequireDefault */
"../../@babel/runtime/helpers/interopRequireDefault.js");
__webpack_require__(/*! core-js/modules/es6.set.js */
"../../core-js/modules/es6.set.js");
__webpack_require__(/*! core-js/modules/es6.object.freeze.js */
"../../core-js/modules/es6.object.freeze.js");
这个问题出现,有可能是因为babel版本库最近修改了什么导致版本不兼容。
所以解决方案是寻找一个稳定的babel版本库,来替换掉当前的版本。
用postinstall重置babel库引用
Postinstall官方定义:在开发或发布之前使用Postinstall来转换devDependencies,使用它来部署依赖项。
这是专门针对以上配置混乱的情况下,对依赖库们进行一遍二次梳理,让不合理的配置变得合理。
废话少说,看看本次案例的postinstall的配置。
package.json
{
"scripts": {
"postinstall": "npm i @babel/generator@7.16.7 @babel/helper-compilation-targets@7.16.7 @babel/helper-module-transforms@7.16.7 @babel/types@7.16.7 @babel/helpers@7.16.7 @babel/helpers@7.16.7 @babel/parser@7.16.7 @babel/compat-data@7.16.4 @babel/traverse@7.16.7"
},
"dependencies": {
"postinstall": "^0.7.4",
},
}
配置使用说明:
- 这里指定了babel系列依赖库版本号为:
7.16.7
- 需要注意的是babel库的依赖顺序不能随意更换,按这个顺序配置目前没有问题
- 需要先
npm install postinstall
- 然后在package.json里面配置
script
- 最后在打包编译前运行
npm run postinstall
希望这是最终解决方案,更希望维护babel库的大佬们早日修复bug,万分感谢!
yarn.lock 或 package-lock.json 是必须要传到服务器的
本地node版本, .lock 文件和 服务器的保持一致,可以减少至少90% 莫名其妙的线上问题
正解,为了避免不确定的外部环境因素,应该让本地环境、测试环境和线上环境保持一致。