实用webpack插件之ProvidePlugin

ProvidePlugin.png

现代化前端的全局引入是一个颇有趣的东西。
先来看下如下几个场景:前端

  • 在webpack中,咱们能够在resolve的alias中定义一个层级较高的目录为一个自定义变量。例如resolve: { alias: { '@': path.join(__dirname, '..', 'src') }}
  • 在webpack中,咱们也能够经过DefinePlugin将配置文件按照环境变量进行区分,高效的完成配置文件的按环境引入,不管是开发构建仍是生产构建,都十分有用。
  • 在vue中,咱们能够将一个经常使用的方法或者库定义在Vue.ptototye上,能够经过直写属性,也能够经过vue中的plugin install上去。例如Vue.prototype.$_ = lodash,在应用了vue的应用上下文中,能够经过this.$_得到对lodash的引用。
  • 在vue中,还有mixins,inject以及vuex等等这些全局绑定或者叫混入、注入方式的全局引入的实现。

来思考一个问题:vue

若是咱们再Vue.prototype上绑定了太多,太大的第三方库,会不会致使root vue过大?
答案是确定的。

有没有办法解决这个问题?
你可能会说,我不用this.xxx。用到的vue单文件组件直接import或者require就行了。

若是数以百计,数以千计甚至是数以万计的.vue文件中用到了呢?一直引入吗?
能够一直引入。可是会形成没必要要的工做量。

有没有更加优雅的解决办法?webpack

再来思考一个问题:web

若是我要在一个webpack打包覆盖的地方的xxx.js文件中用到lodash,该怎么作?
一般来说,咱们会直接`import _ from' lodash'`或者`const _ = require('lodash')`。

若是和.vue同样,有不少不少js文件须要引入呢?一直引入吗?
能够一直引入。一样会形成没必要要的工做量。

有没有更加优雅的实现方式?vuex

看一张一直引入moment,引了99次的图先来感觉一下:ide

image.png
虽然个人项目中是在优化moment的引入,可是为了直观明了,我将以引入lodash为例。函数

  • 使用ProvidePlugin的三种方式
  • 为什么一直引入形成没必要要工做量
  • 使用ProvidePlugin引入实践
  • 思考优化

    • 使用ProvidePlugin后会比一直引入减少打包体积吗?
    • 使用ProvidePlugin有哪些注意事项?

使用ProvidePlugin的三种方式

// 语法
new webpack.ProvidePlugin({
  identifier: 'module1',
  // identifier: ['module1', 'property1'],
});
  • module.exportsui

    • 直接引入
    • 引入某个函数
  • export default

module.exports

直接引入
new webpack.ProvidePlugin({
  $_: 'lodash',
});
引入某个函数
new webpack.ProvidePlugin({
  $_uniqBy: ['lodash','uniqBy']
});

export default

new webpack.ProvidePlugin({
  Vue: ['vue/dist/vue.esm.js', 'default']
});

为什么一直引入形成没必要要工做量

加入咱们有a~z,a.js到z.js总结26个js文件,每一个文件都须要引入lodash。this

// a.js
import $_ from 'lodash';
// b.js
import $_ from 'lodash';
// c.js
import $_ from 'lodash';
// d.js
import $_ from 'lodash';
// e.js
import $_ from 'lodash';
// f.js
import $_ from 'lodash';
...
// z.js
import $_ from 'lodash';

这样作有如下几个弊端

  • 要乖乖引入26次
  • import进来以后的自定义名称可能会不统一,致使全局搜索困难

好比说下面这种场景,对于代码可读性是很很差的。

// a.js
import $_ from 'lodash';
// b.js
import _ from 'lodash';

使用ProvidePlugin引入实践

  • webpack的plugins中增长$_的配置
  • eslint的globals增长$_的配置
  • 页面中如何使用$_

webpack的plugins中增长$_的配置

// webpack.base.config.js
plugins: [
    new webpack.ProvidePlugin({
      $_: 'lodash',
    }),
],

eslint的globals增长$_的配置

// .eslintrc.js
globals: {
    $_: 'readonly', // 或者true
},

配置为readonly是由于咱们不会改写lodash,仅仅是调用其方法。

页面中如何使用$_

假设在a.js中。
删除单独的lodash引入 :import from 'lodash'
直接使用$_ :$_.uniqBy(...)

思考

使用ProvidePlugin后会比一直引入减少打包体积吗?

不会。
这是我本身对比使用ProvidePlugin前使用ProvidePlugin后打包文件体积大小得出的结论。
至于具体缘由还有待探索。

使用ProvidePlugin有哪些注意事项?

这些注意事项其实主要是为了加强代码可读性和可维护性。

  • 尽可能定义出惟一性高的全局变量,例如$_,$moment
  • 同一个前端小组的成员都采用全局变量的方式引入
  • 最好是能维护一个全局变量的文档,在新人入职时特殊强调

看到这里,文章开头Vue.prototype.xxx和import和require重复引入的问题”有没有更加优雅的实现方式?“就迎刃而解啦。

快到你的项目中试试ProvidePlugin吧~

相关文章
相关标签/搜索