웹팩 모듈의 기본 원리에 대한 심층 설명

이 글은 주로 webpack 구성 모듈의 원리를 소개하고 있습니다.

이제 Webpack을 사용하여 프론트엔드에서 JS 및 기타 파일을 패키징하는 것이 주류가 되었으며, Node의 인기와 맞물려 프론트엔드 엔지니어링 방식도 백엔드와 점점 유사해지고 있습니다. 모든 것이 모듈화되어 결국 함께 컴파일됩니다. Webpack 버전의 지속적인 업데이트와 다양하고 복잡한 구성 옵션으로 인해 사용 중에 알 수 없는 오류가 발생하여 종종 사람들을 혼란스럽게 만듭니다. 따라서 Webpack이 컴파일된 모듈을 구성하는 방법과 생성된 코드가 실행되는 방법을 이해하는 것은 매우 유익합니다. 그렇지 않으면 항상 블랙박스가 됩니다. 물론 저는 프론트엔드 초보자이고 최근에 Webpack의 원리를 공부하기 시작했기 때문에 여기에 몇 가지 메모를 하겠습니다.

컴파일된 모듈

"컴파일"이라는 단어는 매우 첨단 기술처럼 들리며, 생성된 코드는 종종 이해할 수 없는 일들로 뒤죽박죽이어서 사람들을 놀라게 하는 경우가 많지만 사실 그 안에 담긴 핵심 원칙은 무엇입니까? 어려운. 소위 Webpack 컴파일은 실제로 Webpack이 소스 코드를 분석하고 특정 수정을 가한 후 모든 소스 코드를 하나의 파일로 구성하는 것입니다. 마지막으로, 브라우저나 다른 Javascript 엔진에 의해 실행되고 결과를 반환하는 대규모 번들 JS 파일이 생성됩니다.

다음은 Webpack 패키징 모듈의 원리를 설명하는 간단한 사례입니다. 예를 들어, mA.js

var aa = 1;

function getDate() {
 return new Date();
}

module.exports = {
 aa: aa,
 getDate: getDate
}

라는 모듈이 있는데, 저는 변수 aa와 함수 getDate를 정의한 후 CommonJS를 사용하여 이를 내보냈습니다.

그런 다음 app.js를 CommonJS 스타일로 기본 파일로 정의합니다.

var mA = require('./mA.js');

console.log('mA.aa =' + mA.aa);
mA.getDate();

이제 Webpack을 사용하여 패키징된 두 개의 모듈이 있습니다. 항목 파일은 mA.js 모듈에 따라 달라집니다. , Webpack 할 일이 몇 가지 있습니다:

1. 항목 모듈 app.js에서 시작하여 모든 모듈의 종속성을 분석하고 사용된 모든 모듈을 읽습니다.

2. 각 모듈의 소스코드는 즉시 실행되는 함수로 정리됩니다.

3. 모듈 코드에서 require 및 내보내기와 관련된 구문과 해당 참조 변수를 다시 작성하세요.

4. 최종 생성된 번들 파일에 사용된 모듈을 런타임 시 동적으로 로드할 수 있는 모듈 관리 시스템을 구축합니다.

위의 예를 보면 Webpack 패키징 결과를 볼 수 있습니다. 최종 번들 파일은 일반적으로 즉시 실행되는 큰 기능입니다. 조직 수준이 상대적으로 복잡하고 많은 이름이 상대적으로 모호하므로 여기서는 다음과 같이 간단하고 이해하기 쉽게 만들기 위해 일부를 다시 작성하고 수정했습니다. 가능한.

먼저, 사용된 모든 모듈을 나열하고 해당 파일 이름(일반적으로 전체 경로)을 ID로 사용하여 테이블을 만듭니다.

var modules = {
 './mA.js': generated_mA,
 './app.js': generated_app
}

핵심은 위의 generate_xxx가 무엇인가요? 각 모듈의 소스코드를 내부에 래핑하여 내부 변수가 노출되지 않도록 로컬 스코프(Local Scope)로 만들고, 실제로 각 모듈을 실행 함수로 만들어주는 함수입니다. 그 정의는 일반적으로 다음과 같습니다:

function generated_module(module, exports, webpack_require) {
  // 模块的具体代码。
  // ...
}

여기서 모듈의 특정 코드는 Webpack이 생성된 코드라고 부르는 생성된 코드를 나타냅니다. 예를 들어 mA를 다시 작성하면 결과는 다음과 같습니다.

function generated_mA(module, exports, webpack_require) {
 var aa = 1;
 
 function getDate() {
  return new Date();
 }

 module.exports = {
  aa: aa,
  getDate: getDate
 }
}

얼핏 보면 소스 코드와 완전히 똑같아 보입니다. 실제로 mA는 다른 모듈을 요구하거나 가져오지 않으며 내보내기도 전통적인 CommonJS 스타일을 사용하므로 생성된 코드에는 변화가 없습니다. 그러나 마지막 module.exports = ...라는 점은 주목할 가치가 있습니다. 여기서 모듈은 외부에서 전달된 매개변수 모듈입니다. 이는 실제로 이 함수가 실행될 때 모듈 mA의 소스 코드가 실행될 것임을 알려줍니다. , 그리고 마지막으로 내보낼 내용은 외부에 저장됩니다. 이는 mA 로딩이 완료되었음을 의미하며, 외부적인 것은 실제로 나중에 논의할 모듈 관리 시스템입니다.

다음으로 생성된 app.js 코드를 살펴보세요.

function generated_app(module, exports, webpack_require) {
 var mA_imported_module = webpack_require('./mA.js');
 
 console.log('mA.aa =' + mA_imported_module['aa']);
 mA_imported_module['getDate']();
}

require/exports인지 ES6 스타일 import/인지에 따라 가져온 모듈 mA에서 app.js의 소스 코드가 수정되었음을 알 수 있습니다. 내보내기는 JavaScript 인터프리터에 의해 직접 실행될 수 없습니다. 이러한 추상 키워드를 구체화하려면 모듈 관리 시스템에 의존해야 합니다. 즉, webpack_require는 모듈 mA를 동적으로 로드하고 결과를 앱에 반환할 수 있는 require의 특정 구현입니다.

이 시점에서 당신은 점차적으로 모듈 관리 시스템에 대한 아이디어를 마음 속에 구축했을 것입니다. webpack_require 구현을 살펴보겠습니다.

// 加载完毕的所有模块。
var installedModules = {};

function webpack_require(moduleId) {
 // 如果模块已经加载过了，直接从Cache中读取。
 if (installedModules[moduleId]) {
  return installedModules[moduleId].exports;
 }

 // 创建新模块并添加到installedModules。
 var module = installedModules[moduleId] = {
  id: moduleId,
  exports: {}
 };
 
 // 加载模块，即运行模块的生成代码，
 modules[moduleId].call(
  module.exports, module, module.exports, webpack_require);
 
 return module.exports;
}

끝에서 두 번째 문장의 모듈은 모든 모듈에 대해 생성됩니다. 우리는 이전에 코드를 정의했습니다:

var modules = {
 './mA.js': generated_mA,
 './app.js': generated_app
}

webpack_require의 로직은 매우 명확하게 작성되었습니다. 먼저 모듈이 로드되었는지 확인하세요. 그렇다면 캐시에서 직접 모듈의 내보내기 결과를 반환하세요. 새로운 모듈인 경우 해당 데이터 구조 모듈을 생성하고 이 모듈에서 생성된 코드를 실행합니다. 이 함수가 전달하는 것은 우리가 만든 모듈 개체와 해당 내보내기 필드입니다. 이는 실제로 CommonJS의 내보내기 및 내보내기 필드입니다. .모듈의 유래. 이 함수를 실행하면 모듈이 로드되고 내보내야 하는 결과가 모듈 개체에 저장됩니다.

所以我们看到所谓的模块管理系统，原理其实非常简单，只要耐心将它们抽丝剥茧理清楚了，根本没有什么深奥的东西，就是由这三个部分组成：

// 所有模块的生成代码
var modules；
// 所有已经加载的模块，作为缓存表
var installedModules；
// 加载模块的函数
function webpack_require(moduleId);

当然以上一切代码，在整个编译后的bundle文件中，都被包在一个大的立即执行的匿名函数中，最后返回的就是这么一句话：

return webpack_require(‘./app.js');

即加载入口模块app.js，后面所有的依赖都会动态地、递归地在runtime加载。当然Webpack真正生成的代码略有不同，它在结构上大致是这样：

(function(modules) {
 var installedModules = {};
 
 function webpack_require(moduleId) {
   // ...
 }

 return webpack_require('./app.js');
}) ({
 './mA.js': generated_mA,
 './app.js': generated_app
});

可以看到它是直接把modules作为立即执行函数的参数传进去的而不是另外定义的，当然这和上面的写法没什么本质不同，我做这样的改写是为了解释起来更清楚。

ES6的import和export

以上的例子里都是用传统的CommonJS的写法，现在更通用的ES6风格是用import和export关键词，在使用上也略有一些不同。不过对于Webpack或者其它模块管理系统而言，这些新特性应该只被视为语法糖，它们本质上还是和require/exports一样的，例如export：

export aa
// 等价于:
module.exports['aa'] = aa

export default bb
// 等价于:
module.exports['default'] = bb

而对于import：

import {aa} from './mA.js'
// 等价于
var aa = require('./mA.js')['aa']

比较特殊的是这样的：

import m from './m.js'

情况会稍微复杂一点，它需要载入模块m的default export，而模块m可能并非是由ES6的export来写的，也可能根本没有export default，所以Webpack在为模块生成generated code的时候，会判断它是不是ES6风格的export，例如我们定义模块mB.js:

let x = 3;

let printX = () => {
 console.log('x = ' + x);
}

export {printX}
export default x

它使用了ES6的export，那么Webpack在mB的generated code就会加上一句话：

function generated_mB(module, exports, webpack_require) {
 Object.defineProperty(module.exports, '__esModule', {value: true});
 // mB的具体代码
 // ....
}

也就是说，它给mB的export标注了一个__esModule，说明它是ES6风格的export。这样在其它模块中，当一个依赖模块以类似import m from './m.js'这样的方式加载时，会首先判断得到的是不是一个ES6 export出来的模块。如果是，则返回它的default，如果不是，则返回整个export对象。例如上面的mA是传统CommonJS的，mB是ES6风格的：

// mA is CommonJS module
import mA from './mA.js'
console.log(mA);

// mB is ES6 module
import mB from './mB.js'
console.log(mB);

我们定义get_export_default函数：

function get_export_default(module) {
 return module && module.__esModule? module['default'] : module;
}

这样generated code运行后在mA和mB上会得到不同的结果：

var mA_imported_module = webpack_require('./mA.js');
// 打印完整的 mA_imported_module
console.log(get_export_default(mA_imported_module));

var mB_imported_module = webpack_require('./mB.js');
// 打印 mB_imported_module['default']
console.log(get_export_default(mB_imported_module));

这就是在ES6的import上，Webpack需要做一些特殊处理的地方。不过总体而言，ES6的import/export在本质上和CommonJS没有区别，而且Webpack最后生成的generated code也还是基于CommonJS的module/exports这一套机制来实现模块的加载的。

模块管理系统

以上就是Webpack如何打包组织模块，实现runtime模块加载的解读，其实它的原理并不难，核心的思想就是建立模块的管理系统，而这样的做法也是具有普遍性的，如果你读过Node.js的Module部分的源代码，就会发现其实用的是类似的方法。这里有一篇文章可以参考。

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

vue iview组件表格 render函数的使用方法详解

微信小程序实现换肤功能

nodejs实现解析xml字符串为对象的方法示例

위 내용은 웹팩 모듈의 기본 원리에 대한 심층 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!