webpack打包兼容之shimming(垫片)

gogo.jpg

写在前面

在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，大家积累起来吧！

漫思