写在前面
在webapck打包的过程中,我们往往需要做代码的兼容,或者打包过程的兼容。比如,我们之前使用的@babel/polyfill
,他所解决的就是打包代码运行在低版本浏览器上时有些api不兼容的问题,比如IE浏览器上不支持的Promise
api,他就会自动的在打包过程中构建这样的兼容低版本的全局变量。这其实就是一种webpack shimming。
当然了,关于webpack的兼容问题不局限于js语法的高低版本兼容,还有可能是下面这样的一些情况,我们一一来过一下
shimming
我们在src下新建一个jquery-ui.js文件,内容如下
export function ui () {
$(‘body‘).css(‘background‘, ‘green‘)
}
在index.js中引入并运行
import _ from ‘lodash‘
import $ from ‘jquery‘
+ import { ui } from ‘./jquery-ui‘
+ ui()
const dom = $(‘div‘)
dom.html(_.join([‘hello‘, ‘world‘], ‘--‘))
$(‘body‘).append(dom)
这段看似能正常运行的代码,实际上会因为$的未定义而报错,因为在webapck打包中,是以模块来划分了,没一个模块都会引入单独的资源,这样就能保证其资源的独立了,所以要想运行上面的代码,我们可能还得在ui.js中引入jquery
,但实际项目开发中,ui.js很可能是一个npm包,我们去修改npm包显然是不合实际的,这个时候,我们就需要用shimming的方式来解决了
我们在webpack.common.js中做如下的配置
const webpack = require(‘webpack‘)
module.exports = {
plugins: [
new webpack.ProvidePlugin({
$: ‘jquery‘
})
]
}
webpack为我们提供了ProvidePlugin
的插件,上面配置的意思是,当我们在模块中遇到‘$’就会去自动的引入jquery
。这样就实现了一个自动的解决兼容的方法,我们起本地server运行一下。有的读者可能心生疑惑了,为什么我们引入的npm可能没有引入‘jquery’呢?因为在一些老版本的插件中,没有考虑到未来技术的发展想webpack这样的打包方式,所以是极有可能存在上面说的这样情况的,这也就是为什么我们管这种方式叫shimming的一种情况
当然了,这个插件的玩法也是比较多,比如我们要对一个lodash方法进行重命名,我们也可以这样做
new webpack.ProvidePlugin({
_join: [‘lodash‘, ‘join‘]
})
后面的数组代表lodash下面的join方法。
写在最后
本篇简单介绍了webpack中shimming的一些场景,其实关于shimming的场景还有很多,我们一般把处理打包过程兼容性的问题叫做shimming,大家积累起来吧!