webpack 提出babel相关代码作为独立文件1

最新推荐文章于 2025-09-11 09:44:20 发布

weixin_33809981

最新推荐文章于 2025-09-11 09:44:20 发布

阅读量140

点赞数

CC 4.0 BY-SA版权

文章标签： webpack json javascript ViewUI

原文链接：https://segmentfault.com/a/1190000011924744

本文探讨了在Webpack配置中如何使用Babel进行JS代码转换，重点介绍了.babelrc文件的配置方法及其对最终编译文件的影响。文章还对比了使用与不使用transform-runtime插件时的代码差异。

webpack配置中对js的编译一般都用的babel-loader.

我们可以建立一个.babelrc文件，在根目录下，和pakeage.json平级。babel-loader会自动去读取其中的代码。
webpack配置：

......
rules: [{
   test: /\.(js|jsx)$/,
   use: [{
       loader: 'babel-loader',
   }],
   exclude: /node_modules/
},
......

.babelrc文件:(具体可以去babel官网了解一下)

{
    "presets": ["react", "es2015", "stage-0"],
    "plugins": [
        ["transform-runtime",{
             "helpers": true, // defaults to true; v6.12.0 (2016-07-27) 新增;
             "polyfill": false, // defaults to true
             "regenerator": true, // defaults to true
             // v6.15.0 (2016-08-31) 新增
             // defaults to "babel-runtime"
             // 可以这样配置
             // moduleName: path.dirname(require.resolve('babel-runtime/package'))
             "moduleName": "babel-runtime"
        },"lodash"],
        "transform-decorators-legacy"
    ],
    "env": {
        "development": {
            "presets": ["react-hmre"]
        }
    }
}

babel-loader源码：(可以看就在读取babelrc)

var defaultOptions = {
    metadataSubscribers: [],
    inputSourceMap: inputSourceMap,
    sourceRoot: process.cwd(),
    filename: filename,
    cacheIdentifier: JSON.stringify({
      "babel-loader": pkg.version,
      "babel-core": babel.version,
      babelrc: exists(userOptions.babelrc) ? read(userOptions.babelrc) : resolveRc(path.dirname(filename)),
      env: userOptions.forceEnv || process.env.BABEL_ENV || process.env.NODE_ENV || "development"
    })
  };

看源码的时候可以先去看包下的package.json文件，找main属性，会有当前包的入口文件，从入口文件看起，默认是index.js

关于.babelrc的pulgins可以去看babel-polyfill和babel-runtime，现在回到正题

当不配置transform-runtime,打包后生成的文件，比如你创建一个类，他就会创建一个_createClass函数，所以当你有很多类时，重复代码就太多了。所以我们选择使用transform-runtime,它包含了babel-runtime,在这种情况下，打包出来就又是很大，直接在当前文件内部就引入了babel-runtime相关的modules.(QAQ 表达的不太好...)

不配置transform-runtime时：
打包后app.js大概5KB
文件内部会有对应的函数，类似代码块比较多的时候就不好了。

配置transform-runtime时：
文件打包大概60多KB:
文件内部有很多babel-runtime core-js的module

大概这就是区别吧。然后把这些babel-runtime提出去，让编译后文件更加易读，更加有分类。

原理：
compilation 监听 optimize-chunks，会返回一个chunks，包含了所有已经处理好的chunks，然后通过compilation添加一个chunks，名字就叫babel吧，就有个新的空的chunks。

遍历所有的chunks的modules,查看每个模块的来源名称，匹配相关babel-runtime和core-js的路径，(我目前找不到属性能表明当前module属于babel的)，然后存放到一个modules数组里。
判断modules数组是否不为null，在不为null的情况下，创建一个新的chunks，名字你可以自己起啊，我就先叫babel了，现在就有一个空的babelchunk和modules数组。
先删除chunk里面的modules,再把modules数组里的module放入babelchunk里面。
处理依赖，babelchunk相当于是父亲节点了。之前含有modules数组里的module的usedchunk的parents添加babelchunk,babelchunk的chunk添加usedchunk。顺便处理下编译文件输出的路径位置。用entrypoint属性决定的。

(完了代码还没交，万一有更好的解决方案呢)