.1-浅析webpack源码之webpack.cmd

  此系列随时可能断更,毕竟我是解释型源码分析……

  尝试看过Spring的源码,有点烧脑,所以还是重回JS吧!

  在配置完环境变量后,可以通过webpack指令进行打包,需要知道的是,如果当前路径存在webpack.config.js文件,会被默认指定为配置JS文件

  官网原文如下:If a webpack.config.js is present, the webpack command picks it up by default

  也就是说直接执行webpack指令会默认执行webpack webpack.config.js,也可以通过--config自定义

  第一章来点轻松的,比如说webpack.cmd。

  批处理文件源码如下:

REM @代表该行指令不会被显示在界面中
REM IF EXIST/ELSE类似于普通编程语言的if/else
REM %开头的相当于一个占位符
@IF EXIST "%~dp0\node.exe" (
    REM 执行node.exe 并继续执行webpack ...(参数)
  "%~dp0\node.exe"  "%~dp0\..\webpack\bin\webpack.js" %*
) ELSE (
REM 延迟执行
  @SETLOCAL
REM 变量赋值 返回所有系统认为可执行文件类型 排除.JS
  @SET PATHEXT=%PATHEXT:;.JS;=;%
REM 尝试直接执行node webpack ...
  node  "%~dp0\..\webpack\bin\webpack.js" %*
)

  语言是bat命令,花了1个小时入了个门,大概能懂指令的内容。

  这里比较复杂的一个是占位符%,%0在这里相当于当前绝对路径,%~dp0是对内容的格式化,测试代码如下:

REM E:\1-homework\a.cmd
@echo off
echo %0
echo "%~d0"
echo "%~p0"
echo "%~dp0"
pause

  输出为:

  所以第一段IF EXIST指令判断的是在当前路径是否存在node.exe文件,如果有就执行并调用后面的webpack指令。

  指令行最后的%*代表所有接收的参数,参数来自于指令后面自定义的字符了,测试代码如下:

@echo off
echo the params is: %*
pause

  然后在当前路径打开cmd在执行文件名后面加上1 2 3,输出如下:

  也就是在webpack input1.js input2.js指令中,input1.js与input2.js会当成参数替换掉%*。

  

  下面的两个命令可以自己去查,这里暂时看不到作用。

  如果当前路径不存在node.exe,会尝试直接调用node webpack进行打包操作。

  需要注意的是,这里的node并不是一个简单的cmd脚本,而是一个可执行文件,可以在安装的nodejs文件夹中找到npm.cmd:

:: Created by npm, please don‘t edit manually.
@ECHO OFF

SETLOCAL

SET "NODE_EXE=%~dp0\node.exe"
IF NOT EXIST "%NODE_EXE%" (
  SET "NODE_EXE=node"
)

SET "NPM_CLI_JS=%~dp0\node_modules\npm\bin\npm-cli.js"
FOR /F "delims=" %%F IN (‘CALL "%NODE_EXE%" "%NPM_CLI_JS%" prefix -g‘) DO (
  SET "NPM_PREFIX_NPM_CLI_JS=%%F\node_modules\npm\bin\npm-cli.js"
)
IF EXIST "%NPM_PREFIX_NPM_CLI_JS%" (
  SET "NPM_CLI_JS=%NPM_PREFIX_NPM_CLI_JS%"
)

"%NODE_EXE%" "%NPM_CLI_JS%" %*

  这里需要关注的只有第一个SET语句,将node.exe赋值给node_exe,执行node_exe命令也就相当于执行node.exe文件。

  回到webpack指令中,"%~dp0\..\webpack\bin\webpack.js"的webpack并不是主函数,只是预处理,引入了一个叫yargs的命令行框架,并在里面再次引入真正的webpack,并将配置文件的options传入进行打包,源码简化后如下:

var path = require("path");

try {
    var localWebpack = require.resolve(path.join(process.cwd(), "node_modules", "webpack", "bin", "webpack.js"));
    if (__filename !== localWebpack) {
        return require(localWebpack);
    }
} catch (e) {}

// 引入yargs框架
var yargs = require("yargs").usage("...");

// ...

yargs.options({
    // ...
});

yargs.parse(process.argv.slice(2), (err, argv, output) => {
    // ...
    function processOptions(options) {
        // ...
        // 引入真正的webpack
        var webpack = require("../lib/webpack.js");

        Error.stackTraceLimit = 30;
        var lastHash = null;
        var compiler;
        try {
            // 将配置文件的options传入进行编译
            compiler = webpack(options);
        } catch (err) {
            // ...

            throw err;
        }

        // 编译后处理
        // ...
    }
    processOptions(options);
});

  来自于lib文件夹的webpack才是真正的主入口函数。

  这一节内容暂时就到这里,简单过了一下cmd~

时间: 2024-11-09 00:45:58

.1-浅析webpack源码之webpack.cmd的相关文章

webpack源码-依赖收集

webpack源码-依赖收集 version:3.12.0 程序主要流程: 触发make钩子 Compilation.js 执行EntryOptionPlugin 中注册的make钩子 执行compilation.addEntry 执行compilation._addModuleChain Compilation.js 执行moduleFactory.create(this.semaphore.avaiable 初始化为100) Compilation.js 执行this.buildModule

webpack源码分析——配置调试环境

无论是阅读webpack源码,还是编写webpack的plugin和loader,配置调试环境都是很有必要的.weabpack的运行环境是nodejs,调试webpack就是调试nodejs程序.我们平时使用的IDE如eclipse.webstorm都支持nodejs的调试.本文以eclipse(Version: Oxygen.1a Release (4.7.1a))为例,进行讲解. 在这个例子里面,我们使用webpack <entry> [<entry>] <output&

.5-浅析webpack源码之入口函数

从convert-argv出来后,目前进度在这: yargs.parse(process.argv.slice(2), (err, argv, output) => { // ... // 从这里出来 var options = require("./convert-argv")(yargs, argv); // 跟convert-argv中的一样 function ifArg(name, fn, init) { /* ... */ } // 传入返回的options funct

webpack源码分析——参数初始化

webpack比较常见的用法有两种:一.使用配置文件:二.不使用配置文件(用命令 webpack <entry> [<entry>] <output>).这两种方式参数的初始化方式不太一样: 方式一.从配置文件和shell语句中读取并合并参数:方式二.从shell语句从直接读取入口和出口参数.本文会结合源码,分析一下这两种方式的实现.(文章使用的webpack版本是3.10.0) webpack执行的入口文件是bin目录下面的webpack.js,负责参数转换处理的文件

.10-浅析webpack源码之graceful-fs模块

在cachedInput.output.watch三大文件系统中,output非常简单,没有必要讲,其余两个模块依赖于input模块,而input主要是引用了graceful-fs的部分API,所以这节来讲讲graceful-fs. 上一节整理的源码如下: var fs = require('fs') // ...工具方法 module.exports = patch(require('./fs.js')) if (process.env.TEST_GRACEFUL_FS_GLOBAL_PATC

.11-浅析webpack源码之Storage模块

至此已完成NodeJsInputFileSysten模块的讲解,下一步就是实际实用的模块: compiler.inputFileSystem = new CachedInputFileSystem(new NodeJsInputFileSystem(), 60000); 挂载到compiler对象上的输入模块其实是带有缓存的输入模块,源码整理如下(用ES6的class重写): class CachedInputFileSystem { constructor() { // fileSystem

.15-浅析webpack源码之WebpackOptionsApply模块之插件王中王

总体过了一下后面的流程,发现Compiler模块确实不适合单独讲解,这里继续讲解后面的代码: compiler.options = new WebpackOptionsApply().process(options, compiler); 这行代码与之前设置options默认值非常相似,但是复杂程度根本不是一个次元的. 这一节只能简单的看一眼内部到底有多少东西,整理后源码如下: "use strict"; const OptionsApply = require("./Opt

.22-浅析webpack源码之compile流程-事件流compilation总览

呃,终于到了这地方-- newCompilation(params) { // ... this.applyPlugins("this-compilation", compilation, params); // 31 console.log(this._plugins['compilation'].length); this.applyPlugins("compilation", compilation, params); return compilation;

.26-浅析webpack源码之事件流make(1)

compilation事件流中,依然只是针对细节步骤做事件流注入,代码流程如图: // apply => this-compilation // apply => compilation // return compialtion const compilation = this.newCompilation(params); this.applyPluginsParallel("make", compilation, err => { // callback...