node是前端工程化不可或缺的工具,其内部使用commonJS规范的模块化解决方案。虽然esModule是未来的趋势,但时代更替还需一段时间,我们先来了解一下commonJS内部的实现原理。
版权声明:本文为吴孔云博客原创文章,转载请注明出处并带上链接,谢谢。 https://blog.csdn.net/wkyseo/article/details/55670412
先说说什么是模块化,就是将独立的功能代码封装成一个独立的文件,其他模块需要使用,在进行引用。
前一段时间我把webpack源码大概读了一遍,webpack 到4.x版本后,其源码已经比较庞大,对各种开发场景进行了高度抽象,阅读成本也愈发昂贵。
Node程序由许多个模块组成,每个模块就是一个文件。Node模块采用了CommonJS规范。
在计算机程序的开发过程中,随着程序代码越写越多,在一个文件里代码就会越来越长,越来越不容易维护。
在JavaScript发展初期就是为了实现简单的页面交互逻辑,寥寥数语即可;如今CPU、浏览器性能得到了极大的提升,很多页面逻辑迁移到了客户端(表单验证等),随着web2.0时代的到来,Ajax技术得到广泛应用,jQuery等前端库层出不穷,前端代码日益膨胀,此时在JS方面就会考虑使用模块化规范去管理。 本文内容主要有理解模块化,为什么要模块化,模块化的优缺点以及模块化规范,并且介绍下开发中最流行的CommonJS, AMD, ES6、CMD规范。本文试图站在小白的角度,用通俗易懂的笔调介绍这些枯燥无味的概念,希望诸君阅读后,对模块化编程有个全新的认识和理解!
上例子通过jquery方法将页面的背景颜色改成红色,所以必须先引入jQuery库,就把这个库当作参数传入。这样做除了保证模块的独立性,还使得模块之间的依赖关系变得明显。
简介 在最开始学习前端的时候只需要一个js文件就能玩转一个小的练手应用,但是随着自己不断的学习,ajax、jQuery等广泛应用,使得我们的代码量变得巨大,代码变得格外的混乱。现在迫切的需要我们将大段的代码分离开来。 前端最开始并没有像java中package概念以及import那样的引包工具。JavaScript源生代码是在ES6的时候才正式的引入import这个API,来调用其他文件。在这之前也同样出现了很多社区来实现模块化开发。 ---- 发展历程 注意下面会讲历史上面出现的一些类库,有一些现在已经没
Node.js 遵循 CommonJS规范,该规范的核心思想是允许模块通过 require 方法来同步加载所要依赖的其他模块,然后通过 exports 或 module.exports 来导出需要暴露的接口。CommonJS 规范是为了解决 JavaScript 的作用域问题而定义的模块形式,可以使每个模块它自身的命名空间中执行。
Node.js是由ECMAScript及Node 环境提供的一些附加API组成的,包括文件、网络、路径等等一 些更加强大的API。
一个功能就是一个模块, 多个模块可以组成完整应用,抽离一个模块不会影响其他功能的运行。
为了让nodejs开发过程中,为了让Node.js的文件可以相互调用,Node.js提供了一个简单的模块系统,模块是Node.js 应用程序的基本组成部分,文件和模块是一一对应的。换言之,一个 Node.js 文件就是一个模块,这个文件可能是JavaScript 代码、JSON 或者编译过的C/C++ 扩展。
nodejs中,模块的概念很重要。所有功能都是基于模块划分的。每个模块都是JavaScript脚本,核心模块中主要是由js写成,部分是由C/C++编写,内建模块多是由C/C++编写。
正如当年为了统一 JavaScript 语言标准,人们制定了 ECMAScript 规范一样,如今为了统一 JavaScript 在浏览器之外的实现,CommonJS 诞生了。CommonJS 试图定义一套普通应用程序使用的 API,从而填补 JavaScript 标准库过于简单的不足。CommonJS 的终极目标是制定一个像 C++ 标准库一样的规范,使得基于 CommonJS API 的应用程序可以在不同的环境下运行,就像用 C++ 编写的应用程序可以使用不同的编译器和运行时函数库一样。为了保持中立,CommonJS 不参与标准库实现,其实现交给像 Node.js 之类的项目来完成。
exports和module.exports的适用误区
node 模块化 JS 诞生的时候,仅仅是为了实现网页表单的本地校验和简单的 dom 操作处理。所以并没有模块化的规范设计。 项目小的时候,我们可以通过命名空间、局部作用域、自执行函数等手段实现变量不冲突。但是到了大一点的项目,各种组件,各种第三方插件和各种 js 脚步融合的时候,就会发现这些技巧远远不够。 模块化的演变 为什么要有 JS 模块化呢?在浏览器中,顶层作用域的变量是全局的,所以项目稍微复杂点,如果引用的 js 非常多的时候,很容易造成命名冲突,然后造成很大意想不到的结果。 为了避免全局污染,J
每一个文件就是一个模块,拥有自己独立的作用域,变量,以及方法等,对其他的模块都不可见。CommonJS 规范规定,每个模块内部,module 变量代表当前模块。这个变量是一个对象,它的exports属性(即module.exports)是对外的接口。
今天我们来深度分析一下 Commonjs 和 Es Module,希望通过本文的学习,能够让大家彻底明白 Commonjs 和 Es Module 原理,能够一次性搞定面试中遇到的大部分有关 Commonjs 和 Es Module 的问题。
时至今日,Node.js 的模块仓库 npmjs.com ,已经存放了15万个模块,其中绝大部分都是 CommonJS 格式。
模块是Node.js里面一个很基本也很重要的概念,各种原生类库是通过模块提供的,第三方库也是通过模块进行管理和引用的。本文会从基本的模块原理出发,到最后我们会利用这个原理,自己实现一个简单的模块加载机制,即自己实现一个require。
只是改变了形参exports的引用(/指向),而实际的module.exports还是指向空对象{}
模块化这个问题并非一开始就存在,WWW 刚刚问世的时候,html,JavaScript,CSS(JS 和 CSS 都是后来在网景被引进浏览器的)都是极其简单的存在,不需要模块化。
2009年,Node.js 项目诞生,所有模块一律为 CommonJS 格式。 时至今日,Node.js 的模块仓库 npmjs.com ,已经存放了15万个模块,其中绝大部分都是 CommonJS
Webpack 是一个模块化打包工具,它被广泛地应用在前端领域的大多数项目中。利用 Webpack 我们不仅可以打包 JS 文件,还可以打包图片、CSS、字体等其他类型的资源文件。而支持打包非 JS 文件的特性是基于 Loader 机制来实现的。因此要学好 Webpack,我们就需要掌握 Loader 机制。本文阿宝哥将带大家一起深入学习 Webpack 的 Loader 机制,阅读完本文你将了解以下内容:
在nodejs,exports 是 module.exports的引用,初始化时,它们都指向同一个{}对象。
我们都知道,webpack作为一个构建工具,解决了前端代码缺少模块化能力的问题。我们写的代码,经过webpack构建和包装之后,能够在浏览器以模块化的方式运行。这些能力,都是因为webpack对我们的代码进行了一层包装,本文就以webpack生成的代码入手,分析webpack是如何实现模块化的。
学了JS并且用过Node.js后,对模块化应该是有所了解和使用了,那么一定见过以下两种模块导入导出的方式
ES6标准发布后,module成为标准,标准的使用是以export指令导出接口,以import引入模块,但是在我们一贯的node模块中,我们采用的是CommonJS规范,使用require引入模块,使
ES6标准发布后,module成为标准,标准的使用是以export指令导出接口,以import引入模块,但是在我们一贯的node模块中,我们采用的是CommonJS规范,使用require引入模块,使用module.exports导出接口。
随着前端复杂度的不断提升,诞生出很多打包工具,比如最先的grunt,gulp。到后来的webpack和Parcel。但是目前很多脚手架工具,比如vue-cli已经帮我们集成了一些构建工具的使用。有的时候我们可能并不知道其内部的实现原理。其实了解这些工具的工作方式可以帮助我们更好理解和使用这些工具,也方便我们在项目开发中应用。
在平时的工作和学习过程中,webpack 是一个重要的知识点,本文通过分析 webpack 的打包原理,最终带大家实现一个简易版的 webpack。
module.exports和exports是属于 CommonJS 模块规范,export和export default是属于ES6语法。
Node.js 的出现使得前端工程师可以跨端工作在服务器上,当然,一个新的运行环境的诞生亦会带来新的模块、功能、抑或是思想上的革新,本文将带领读者领略 Node.js (以下简称 Node) 的模块设计思想以及剖析部分核心源码实现。
无论是前端开始后端,总会有很多概念。就拿这个前端模块加载机制来说,随着语言的发展,各种概念。
为了让node.js的文件可以相互调用,node.js提供了一个简单的模块系统。模块是node.js应用程序基本的组成部分,文件和模块是一一对应的。换言之,一个node.js文件就是一个模块,这个文件可能是javascript代码、json或者编译过的c/c++扩展。
在上一节中我们初步了解了webpack可以利用内置静态模块类型(asset module type)来处理资源文件,我们所知道的本地服务,资源的压缩,代码分割,在webpack构建的工程中有一个比较显著的特征是,模块化,要么commonjs要么esModule,在开发环境我们都是基于这两种,那么通过webpack打包后,如何让其支持浏览器能正常的加载两种不同的模式呢?
JavaScript 语言最初是为简单的表单操作而发明的,没有诸如模块或命名空间之类的内置功能。多年以来发明了大量的术语、模式、库、语法和工具来模块化 JavaScript。本文讨论了 JavaScript 中的所有主流模块系统、格式、库和工具,包括:
就在这个周末,npm 超过了 cpan ,成为地球上最大的软件模块仓库。 npm 的模块都是 JavaScript 语言写的,但浏览器用不了,因为不支持 CommonJS 格式。要想让浏览器用上这些模
上一篇《前端科普系列(2):Node.js 换个角度看世界》,我们聊了 Node.js 相关的东西,Node.js 能在诞生后火到如此一塌糊涂,离不开它成熟的模块化实现,Node.js 的模块化是在 CommonJS 规范的基础上实现的。那 CommonJS 又是什么呢?
学习Seajs时,看到了exports.doSomething和module.exports,想对这两者的区别一探究竟。 [1486958877980_3135_1486958879213.png]
前端模块化在近几年层出不穷,有Node的CommonJs,也有属于client端的CMD/AMD模式,而ES6本身也出现了Modules,再加上Webpack以及babel的普及,虽然在代码中经常使用到这些用法,但是如果不去深入研究,总觉得是一个黑魔法,无法探测一些问题的根源。
http://www.ruanyifeng.com/blog/2012/10/asynchronous_module_definition.html 阮一峰博客
目前主流的有两种模块语法,一是Node.js专用的CJS,另一种是浏览器和Node.js都支持的ESM,在ESM规范没有出来之前,Node.js的模块编写使用的都是CJS,但是现在ESM已经逐渐在替代CJS成为浏览器和服务器通用的模块解决方案。
npm 的模块都是 JavaScript 语言写的,但浏览器用不了,因为不支持 CommonJS 格式。要想让浏览器用上这些模块,必须转换格式。
这是最原始的 JavaScript 文件加载方式,如果把每一个文件看做是一个模块,那么他们的接口通常是暴露在全局作用域下,也就是定义在 window 对象中,不同模块的接口调用都是一个作用域中,一些复杂的框架,会使用命名空间的概念来组织这些模块的接口,典型的例子如 YUI 库。
javascript语言实现,ES6规范(使用babel编译器将es6转换为es5,webpack只支持部分es6):
作为前端开发,模块化我们已经耳熟能详,我们平时接触到的 ES6 的 import,nodejs中的require他们有啥区别?
领取专属 10元无门槛券
手把手带您无忧上云