We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
模块对于node来说是不可或缺的一部分,是服务端编程的基础。趁着整理模块之际,先将node部分的模块的封装等做一个总结。希望能够切实的帮助到你。本篇将对CommenJS规范,node的文件模块和核心模块等做一个综合的整理。如果你喜欢我的文章,欢迎评论,欢迎Star~。欢迎关注我的github博客
我觉得模块的出现是js进步最大的地方。因为有了模块,才使得很多优秀的东西可以真正被共享出来,而不用去担心变量污染、命名空间的问题。
node作为一门服务端的javascript,它借鉴了CommonJS的规范,形成了一套易用的模块规范。
首先,看看下面这个最常见的例子:
//circle.js const { PI } = Math; exports.area = x => PI*x**2; exports.circle = x => 2*PI*x;
//main.js const circle = require('./circle'); console.log(circle.area(4)); //50.26548245743669
其实,我们可以清晰地看到两个文件中,模块规范部分可以分成三部分:
这三块内容可以使用一张图片概括:
如图:
从这幅图中,我们可以看到,模块之间可以通过exports将接口暴露出来,然后通过require来对另一个模块内的内容进行引入。
这样我们就大概懂得了模块的定义。它主要分为三部分:模块的引用、模块定义和模块标识。
然而,整个模块部分我们最需要去了解的是require机制。node对于require实现,有很多的东西可以去欣赏。
首先,需要明白的是整个模块引入的步骤。从上面的例子中,可以看出这三部分:
有的时候,情况是特殊的。模块本身就分成核心模块和文件模块。而核心模块在node源代码编译的时候。就被编译成二进制文件。并且部分核心模块会在node进程启动时,直接加载到内存中,因此这一部分的核心模块引入是不需要经过文件定位和编译执行的步骤的。
还有特殊就是在缓存部分。每个模块首次加载之后,node会缓存其编译执行后的对象,方便二次加载。所以,二次加载时,是以缓存优先的,从缓存中加载的模块也是不需要文件定位和编译的。
单从路径分析说起,可以分成三种不同的方式:
查找方式: 1. 从当前目录下面的node_modules中查找是否具备相应的模块 2. 若具备,则直接加载使用,否则,会去查找父目录下的node_modules目录,直至查找到根目录下的node_modules中。这种方式是最慢的。
再来分析文件定位:
第一个例子中的标识符是'./circle'。可以发现,这个文件标识符是没有后缀名的。那么,node是如何来进行定位的呢?其实,node有一个默认的定位顺序:js、node、json。这里会最先识别js,之后一次对json和node的文件进行识别。因此,这里有个小技巧:在识别.node和.json的文件的时候,带上文件后缀名会快一点, 为什么呢?是因为,node是使用fs同步阻塞的方式,逐一去尝试,该文件是否存在,存在着直接加载;不存在的话,尝试下一个后缀名。
还有对于那些自定义的模块,如npm包。node的定位方式也是不同的。通常来说,npm包中都会具备package.json文件,这个文件中有个main属性,这指向的就是整个包的入口文件;如果没有这些条件,node会去默认加载index.js、index.json和index.node
最后就是模块编译部分的分析了:
首先,编译执行也可以通过上面的三类后缀文件名来进行分析:
javascript文件编译
在使用fs读取文件之后,读取出来的内容node会如何去处理呢?会造成变量污染吗?很显然是不会的。node是根据CommonJS的规范,对读取进入的内容,在头部和尾部进行包装,包装成function(exports, require, module, __dirname,__filename){ ...读取内容 }。这样子,就起到了一个作用域隔绝的作用,不会对现有模块中的内容污染。而__dirname、__filename是node中存在的。
然后将这个函数代码使用vm原生的模块runInThisContext()方法执行(类似eval => 将字符串转化成可执行的js的代码)。然后返回一个具体的对象,供现有模块中的内容进行使用。
C/C++模块的编译
这个编译主要是依靠node的process.dlopen()方法进行执行,同时node使用libuv对windows和*nix平台做了兼容性的处理。这种模块的性能相对于普通文件模块来说较高,但是编写成本也会相应地提高。
json文件编译
json文件编译会比较简单,就是通过fs读取文件,然后通过JSON.parse方法进行编译,最终将内容给予现有模块中命名的那个变量。
至此我们对node的模块整体的机制,大致已经整理清楚了,从模块的导出,到引入,以及标识符的分析。均可从CommonJS中找到影子,但是node对其进行的加工又相对比较完美。
如果你对我写的有疑问,可以评论,如我写的有错误,欢迎指正。你喜欢我的博客,请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客
The text was updated successfully, but these errors were encountered:
19 things I learnt reading the node docs
Sorry, something went wrong.
希望多些点node的基础文章啊...
No branches or pull requests
前言
模块对于node来说是不可或缺的一部分,是服务端编程的基础。趁着整理模块之际,先将node部分的模块的封装等做一个总结。希望能够切实的帮助到你。本篇将对CommenJS规范,node的文件模块和核心模块等做一个综合的整理。如果你喜欢我的文章,欢迎评论,欢迎Star~。欢迎关注我的github博客
正文
我觉得模块的出现是js进步最大的地方。因为有了模块,才使得很多优秀的东西可以真正被共享出来,而不用去担心变量污染、命名空间的问题。
node作为一门服务端的javascript,它借鉴了CommonJS的规范,形成了一套易用的模块规范。
首先,看看下面这个最常见的例子:
其实,我们可以清晰地看到两个文件中,模块规范部分可以分成三部分:
这三块内容可以使用一张图片概括:
如图:
从这幅图中,我们可以看到,模块之间可以通过exports将接口暴露出来,然后通过require来对另一个模块内的内容进行引入。
这样我们就大概懂得了模块的定义。它主要分为三部分:模块的引用、模块定义和模块标识。
然而,整个模块部分我们最需要去了解的是require机制。node对于require实现,有很多的东西可以去欣赏。
首先,需要明白的是整个模块引入的步骤。从上面的例子中,可以看出这三部分:
有的时候,情况是特殊的。模块本身就分成核心模块和文件模块。而核心模块在node源代码编译的时候。就被编译成二进制文件。并且部分核心模块会在node进程启动时,直接加载到内存中,因此这一部分的核心模块引入是不需要经过文件定位和编译执行的步骤的。
还有特殊就是在缓存部分。每个模块首次加载之后,node会缓存其编译执行后的对象,方便二次加载。所以,二次加载时,是以缓存优先的,从缓存中加载的模块也是不需要文件定位和编译的。
单从路径分析说起,可以分成三种不同的方式:
再来分析文件定位:
第一个例子中的标识符是'./circle'。可以发现,这个文件标识符是没有后缀名的。那么,node是如何来进行定位的呢?其实,node有一个默认的定位顺序:js、node、json。这里会最先识别js,之后一次对json和node的文件进行识别。因此,这里有个小技巧:在识别.node和.json的文件的时候,带上文件后缀名会快一点, 为什么呢?是因为,node是使用fs同步阻塞的方式,逐一去尝试,该文件是否存在,存在着直接加载;不存在的话,尝试下一个后缀名。
还有对于那些自定义的模块,如npm包。node的定位方式也是不同的。通常来说,npm包中都会具备package.json文件,这个文件中有个main属性,这指向的就是整个包的入口文件;如果没有这些条件,node会去默认加载index.js、index.json和index.node
最后就是模块编译部分的分析了:
首先,编译执行也可以通过上面的三类后缀文件名来进行分析:
其他后缀名的文件,都会被当成是js文件进行处理。同时,我们需要的细致地分析一下javascript文件编译的一些具体过程。
javascript文件编译
在使用fs读取文件之后,读取出来的内容node会如何去处理呢?会造成变量污染吗?很显然是不会的。node是根据CommonJS的规范,对读取进入的内容,在头部和尾部进行包装,包装成function(exports, require, module, __dirname,__filename){ ...读取内容 }。这样子,就起到了一个作用域隔绝的作用,不会对现有模块中的内容污染。而__dirname、__filename是node中存在的。
然后将这个函数代码使用vm原生的模块runInThisContext()方法执行(类似eval => 将字符串转化成可执行的js的代码)。然后返回一个具体的对象,供现有模块中的内容进行使用。
C/C++模块的编译
这个编译主要是依靠node的process.dlopen()方法进行执行,同时node使用libuv对windows和*nix平台做了兼容性的处理。这种模块的性能相对于普通文件模块来说较高,但是编写成本也会相应地提高。
json文件编译
json文件编译会比较简单,就是通过fs读取文件,然后通过JSON.parse方法进行编译,最终将内容给予现有模块中命名的那个变量。
总结
至此我们对node的模块整体的机制,大致已经整理清楚了,从模块的导出,到引入,以及标识符的分析。均可从CommonJS中找到影子,但是node对其进行的加工又相对比较完美。
The text was updated successfully, but these errors were encountered: