python模块捆绑器组件

by Adam Kelly

通过亚当凯利

让我们学习模块捆绑器如何工作，然后自己编写 (Let’s learn how module bundlers work and then write one ourselves)

Hello! Welcome, welcome, it’s great to have you here! Today we’re going to be building a really simple JavaScript module bundler.

你好！ 欢迎，欢迎，很高兴你在这里！ 今天，我们将构建一个非常简单JavaScript模块捆绑器。

Before we start, I want to give a few acknowledgements. This article draws heavily on the following resources:

在开始之前，我想先说几句。 本文主要利用以下资源：

• Unbundling the JavaScript module bundler - Luciano Mammino

  取消捆绑JavaScript模块捆绑器 -Luciano Mammino

• Minipack - Ronen Amiel

  迷你包装 -罗恩·阿米尔(Ronen Amiel)

Okay, lets get started with what a module bundler actually is.

好的，让我们开始了解模块捆绑器的实际含义。

什么是模块捆绑器？ (What’s A Module Bundler?)

A module bundler is a tool that takes pieces of JavaScript and their dependencies and bundles them into a single file, usually for use in the browser. You may have used tools such as Browserify, Webpack, Rollup or one of many others.

模块捆绑器是一种工具，用于获取JavaScript片段及其相关性，并将其捆绑到一个文件中，通常在浏览器中使用。 您可能使用过诸如Browserify ， Webpack ， Rollup或其他工具之一。

It usually starts with an entry file, and from there it bundles up all of the code needed for that entry file.

它通常从一个入口文件开始，然后从那里捆绑该入口文件所需的所有代码。

There are two main stages of a bundler:

捆绑器有两个主要阶段：

1. Dependency resolution依赖解析
2. Packing填料

Starting from an entry point (such as app.js above), the goal of dependency resolution is to look for all of the dependencies of your code (other pieces of code that it needs to function) and construct a graph (called a dependency graph).

从入口点(例如上面的app.js )开始，依赖关系解析的目标是查找代码的所有依赖关系(它需要运行的其他代码段)并构建图(称为依赖关系图) )。

Once this is done, you can then pack or convert your dependency graph into a single file that the application can use.

完成此操作后，您可以将依赖关系图打包或转换为应用程序可以使用的单个文件。

Let’s start out our code with some imports (I’ll elaborate on the reason later).

让我们从一些导入开始我们的代码(稍后将详细说明原因)。

依赖解决 (Dependency Resolution)

The first thing we have to do is think up how we want to represent a module during the dependency resolution phase.

我们要做的第一件事是思考在依赖关系解析阶段如何表示模块。

模块表示 (Module Representation)

We are going to need four things:

我们将需要四件事：

• The name and an identifier of the file文件的名称和标识符
• Where the file came from (in the file system)文件的来源(在文件系统中)
• The code in the file文件中的代码
• What dependencies that file needs该文件需要什么依赖

The graph structure gets built up through recursively checking for dependencies within each file.

通过递归检查每个文件中的依赖关系来建立图结构。

In JavaScript, the easiest way to represent such a set of data would be an object.

在JavaScript中，表示这样一组数据的最简单方法是对象。

Looking at the createModuleObject function above, the notable part is the call to a function called detective.

查看上面的createModuleObject函数，值得注意的部分是对名为detective的函数的调用。

Detective is a library that can “find all calls to require() no matter how deeply nested”, and using it means we can avoid doing our own AST traversal!

侦探是可以“找到所有的呼叫需要()无论多么深的嵌套”一库，并利用它意味着我们能够避免做我们自己的AST穿越！

One thing to note (and this is the same in almost all module bundlers) is that if you try to do something weird like:

需要注意的一件事(几乎在所有模块捆绑器中都一样)是，如果您尝试做一些奇怪的事情，例如：

const libName = 'lodash'const lib = require(libName)

It will not be able to find it (because that would mean executing the code).

它将无法找到它(因为这意味着执行代码)。

So what does running this function from the path of a module give?

那么从模块的路径运行此功能会带来什么呢？

Whats next? Dependency resolution.

下一步是什么？ 依赖性解析。

Okay, not quite yet. First, I want to talk about a thing called a module map.

好的，还没有。 首先，我想谈一谈称为模块映射的事情。

模块图 (Module Map)

When you import modules in Node, you can do relative imports, like require('./utils'). So when your code calls this, how does the bundler know what is the right ./utils file when everything is packaged?

在Node中导入模块时，可以进行相对导入，例如require('./utils') 。 因此，当您的代码调用此代码时，打包所有内容后，捆绑程序如何知道正确的./utils文件？

That is the problem the module map solves.

那就是模块图解决的问题。

Our module object has a unique id key which will be our ‘source of truth’. So when we are doing our dependency resolution, for each module, we will keep a list of the names of what is being required along with their id. This way, we can get the correct module at run-time.

我们的模块对象具有唯一的id密钥，它将作为我们的“真理之源”。 因此，当我们进行依赖关系解析时，对于每个模块，我们将保留所需内容的名称及其ID的列表。 这样，我们可以在运行时获取正确的模块。

This also means that we can store all of the modules in a non-nested object, using the id as a key.

这也意味着我们可以使用id作为键将所有模块存储在非嵌套对象中。

依赖解决 (Dependency Resolution)

Okay, so there is a fair amount going on in the getModules function. Its main purpose is to start at the root/entry module, and look for and resolve dependencies recursively.

好的，因此getModules函数中发生了很多事情。 它的主要目的是从root / entry模块开始，并递归查找和解决依赖关系。

What do I mean by ‘resolve dependencies’? In Node there is a thing called the require.resolve, and it’s how Node figures out where the file that you are requiring is. This is because we can import relatively or from a node_modules folder.

“解决依赖关系”是什么意思？ 在Node中，有一个叫做require.resolve的东西，这就是Node找出您需要的文件的位置的方式。 这是因为我们可以相对导入，也可以从node_modules文件夹导入。

Lucky for us, there’s an npm module named resolve which implements this algorithm for us. We just have to pass in the dependency and base URL arguments, and it will do all the hard work for us.

对我们来说幸运的是，有一个名为resolve的npm模块为我们实现了该算法。 我们只需要传递依赖项和基本URL参数，它将为我们完成所有艰苦的工作。

We need to carry out this resolution for each dependency of each module in the project.

我们需要对项目中每个模块的每个依赖项执行此解决方案。

We are also creating the module map named map that I mentioned earlier.

我们还将创建我前面提到的名为map的模块映射。

At the end of the function, we are left with an array named modules which will contain module objects for every module/dependency in our project.

在函数的最后，我们剩下一个名为modules的数组，它将包含项目中每个模块/依赖项的模块对象。

Now that we have that, we can move on to the final step: packing!

现在我们有了这个，我们可以继续进行最后一步：打包！

填料 (Packing)

In the browser, there is no such thing as modules (kind of). But this means that there is no require function, and no module.exports. So even though we have all of our dependencies, we currently have no way to use them as modules.

在浏览器中，没有诸如模块之类的东西。 但这意味着没有require函数，也没有module.exports 。 因此，即使我们拥有所有依赖项，目前也无法将它们用作模块。

模块工厂功能 (Module Factory Function)

Enter the factory function.

输入出厂功能。

A factory function is a function (that’s not a constructor) which returns an object. It is a pattern from object oriented programming, and one of its uses is to do encapsulation and dependency injection.

工厂函数是一个返回对象的函数(不是构造函数)。 它是面向对象编程的一种模式，其用途之一是进行封装和依赖注入。

Sound good?

听起来不错？

Using a factory function, we can both inject our own require function and module.exports object that can be used in our bundled code and give the module its own scope.

使用工厂函数，我们可以注入我们自己的require函数和module.exports对象， module.exports对象可以在我们的捆绑代码中使用，并为模块提供自己的作用域。

填料 (Packing)

The following is the pack function that is used for packing.

以下是用于打包的打包功能。

Most of that is just template literals of JavaScript, so let’s discuss what it’s doing.

其中大多数只是JavaScript的模板文字，因此让我们讨论一下它在做什么。

First up is modulesSource. Here, we are going through each of the modules and transforming them into a string of sources.

首先是modulesSource 。 在这里，我们将遍历每个模块，并将它们转换成一连串的资源。

So what is the output like for a module object?

那么模块对象的输出是什么样的呢？

Now it’s a little hard to read, but you can see that the source is encapsulated. We are providing modules and require using the factory function as I mentioned before.

现在有点难以理解，但是您可以看到源已封装。 我们正在提供modules并且require使用我之前提到的工厂功能。

We are also including the modules map that we constructed during the dependency resolution.

我们还包括在依赖性解析期间构造的模块映射。

Next in the function, we join all of these to create a big object of all the dependencies.

在函数的下一步，我们将所有这些连接起来以创建一个具有所有依赖关系的大对象。

The next string of code is an IIFE, which means that when you run that code in the browser (or anywhere else), the function will run immediately. IIFE is another pattern for encapsulating scope, and is used here so we don’t pollute the global scope with our require and modules.

下一个代码字符串是IIFE，这意味着当您在浏览器(或其他任何地方)中运行该代码时，该函数将立即运行。 IIFE是封装范围的另一种模式，在这里使用IIFE，因此我们不会用我们的require和模块污染全局范围。

You can see that we are defining two require functions, require and localRequire.

您可以看到我们正在定义两个require函数， require和localRequire 。

Require accepts the id of a module object, but of course the source code isn’t written using ids. Instead, we are using the other function localRequire to take any arguments to require by the modules and convert them to the correct id. This is using those module maps.

Require接受模块对象的ID，但是源代码当然不是使用ID编写的。 取而代之的是，我们使用另一个函数localRequire来获取模块要求的任何参数，并将其转换为正确的ID。 这是使用那些模块映射。

After this, we are defining a module object that the module can populate, and passing both functions into the factory, after which we return module.exports.

此后，我们定义了一个module object ，该模块可以填充该module object ，并将这两个函数都传递给工厂，然后返回module.exports 。

Lastly, we call require(0) to require the module with an id of 0, which is our entry file.

最后，我们调用require(0)要求ID为0的模块，这是我们的入口文件。

And that’s it! Our module bundler is 100% complete!

就是这样！ 我们的模块捆绑器已100％完成！

恭喜你！ ？ (Congratulations! ?)

So we now have a working module bundler.

因此，我们现在有了一个工作正常的模块捆绑器。

This probably shouldn’t be used in production, because it’s missing loads of features (like managing circular dependencies, making sure each file gets only parsed once, es-modules, and so on) but this has hopefully given you a good idea of how module bundlers actually work.

这可能不应该在生产中使用，因为它缺少许多功能(例如管理循环依赖项，确保每个文件仅被解析一次，es-modules等)，但这希望可以给您一个很好的想法模块捆绑器实际上可以工作。

In fact, this one works in about 60 lines if you remove all of the source code.

实际上，如果您删除了所有源代码，则此代码行约60行。

Thanks for reading, and I hope you have enjoyed a look into the workings of our simple module bundler. If you did, make sure to clap ? and share.

感谢您的阅读，我希望您喜欢我们的简单模块捆绑器。 如果这样做，请确保拍手？ 和分享。

This article was originally posted on my blog.

本文最初发布在我的博客上 。

Check out the source https://github.com/adamisntdead/wbpck-bundler

查看源代码https://github.com/adamisntdead/wbpck-bundler

翻译自: https://www.freecodecamp.org/news/lets-learn-how-module-bundlers-work-and-then-write-one-ourselves-b2e3fe6c88ae/

python模块捆绑器组件