commonjs

/** * CommonJS 模块化规范 * CommonJS规范加载模块是同步的，也就是说，只有加载完成，才能执行后面的操作 */ /*-------Node.js遵循Commonjs规范---------*/ //写法1. var exports=module.exports; exports.name="leyi"; exports.fn=function(){ return 'hello world!' }; //写法2. module.exports={ "name":'leyi', "fn":function(){ return 'hello world!' } }; //写法3. module.exports=function(){ this.name='leyi'; this.fn=function(){ return 'hello world!' } }; /** * AMD 模块化规范 -推崇依赖前置 * AMD规范则是非同步加载模块，允许指定回调函数。由于Node.js主要用于服务器编程，模块文件一般都已经存在于本地硬盘， * 所以加载起来比较快，不用考虑非同步加载的方式，所以CommonJS规范比较适用。 * 但是，如果是浏览器环境，要从服务器端加载模块，这时就必须采用非同步模式，因此浏览器端一般采用AMD规范。 */ /*-------require

对于那些正在构建大型应用程序，而对JavaScript不甚了解的开发者而言，他们最初必须要面对的挑战之一就是如何着手组织代码。起初只要在 <script> 标记之间嵌入几百行代码就能跑起来，不过很快代码就会变得一塌糊涂。而问题是，JavaScript没有为组织代码提供任何明显帮助。从字面上看，C#有 using ，Java有 import ——而JavaScript一无所有。这迫使JavaScript编写者试验不同的约定，并使用现有的语言创建了一些切实可行的方法来组织大型JavaScript应用程序。 各种模式（patterns）、工具（tools）及惯例（practices）会形成现代JavaScript的基础，它们必将来自于语言本身实现之外。 —— Rebecca Murphy 模块模式（The Module Pattern） 用于解决组织代码问题、使用最为广泛的方法之一是 模块模式（Module Pattern） 。我尝试在下面解释一个基本示例，并讨论其若干特性。要想阅读更精彩的说明，并了解用尽各种不同方法的怪人，那么请参阅Ben Cherry的帖子—— JavaScript Module Pattern: In-Depth（深入理解JavaScript模块模式） 。 (function(lab49) { function privateAdder(n1, n2) {

到目前为止，已经实习了3个月的时间了。最近在面试，在面试题里面有题目涉及到模块循环加载的知识。趁着这个机会，将CommonJS模块与ES6模块之间一些重要的的区别做个总结。语法上有什么区别就不具体说了，主要谈谈引用的区别。 转载请注明出处：CommonJS模块与es6模块的区别 CommonJS 对于基本数据类型，属于复制。即会被模块缓存。同时，在另一个模块可以对该模块输出的变量重新赋值。 对于复杂数据类型，属于浅拷贝。由于两个模块引用的对象指向同一个内存空间，因此对该模块的值做修改时会影响另一个模块。 当使用require命令加载某个模块时，就会运行整个模块的代码。 当使用require命令加载同一个模块时，不会再执行该模块，而是取到缓存之中的值。也就是说，CommonJS模块无论加载多少次，都只会在第一次加载时运行一次，以后再加载，就返回第一次运行的结果，除非手动清除系统缓存。 循环加载时，属于加载时执行。即脚本代码在require的时候，就会全部执行。一旦出现某个模块被"循环加载"，就只输出已经执行的部分，还未执行的部分不会输出。 ES6模块 ES6模块中的值属于【动态只读引用】。 对于只读来说，即不允许修改引入变量的值，import的变量是只读的，不论是基本数据类型还是复杂数据类型。当模块遇到import命令时，就会生成一个只读引用。等到脚本真正执行时，再根据这个只读引用

前言 在前文中，我说过本系列文章的受众是在现代前端体系下能够熟练编写业务代码的同学，因此本文在介绍 webpack 配置时，仅提及构建一个库所特有的配置，其余配置请参考 webpack 官方文档。 输出产物 构建一个库与构建一个一般应用最大的不同点在于 构建完成后输出的产物 。 一般应用构建完成后会输出： 一个 html 文件 一个 js 入口 chunk 、若干子 chunk 若干 css 文件 若干其它资源，如图片、字体文件等 虽然输出的资源非常多，但实际上所有的依赖、加载关系都已经从 html 文件开始一层一层定下来了，换句话说，这个 html 文件实际上就是整个应用的入口。 一个库构建完成后会输出： 一个 CommonJS 格式的 js 文件 一个未压缩的 UMD 格式的 js 文件 一个已压缩的 UMD 格式的 js 文件 可能包括若干的 css 文件 可能包括若干的其它资源文件 库的入口分别是上面罗列的 js 文件；你可能会奇怪，一个库怎么会有3个入口文件呢？莫急，且听我一一道来。 CommonJS CommonJS 是 Node.js 推行的一种模块化规范，主要语法包括 module.exports 、 require() 等；而我们在使用 webpack 引入 npm 包时，实际上是处于 Node.js 环境，由此可知，这个 CommonJS 格式的入口 js 文件

vs Code配置import@路径提示 1、 安装 Path Intellisense插件 2、打开设置 3、添加 "path-intellisense.mappings": { "@": "${workspaceRoot}/src" } 4、在项目package.json所在同级目录下创建文件jsconfig.json： { "compilerOptions": { "target": "ES6", "module": "commonjs", "allowSyntheticDefaultImports": true, "baseUrl": "./", "paths": { "@/*": ["src/*"] } }, "exclude": [ "node_modules" ] } 来源： oschina 链接： https://my.oschina.net/yuantao/blog/3156053

打一个通用 UMD 包 有这样一个场景，客户端运行很久，但是法务部和数据部需要收集用户的一些信息，这些信息收集好之后需要进行相应的数据处理，之后上报到服务端。客户端提供一个纯粹的 JS 执行引擎，不需要 WebView 容器。iOS 端有成熟的 JavaScriptCore、Android 可以使用 V8 引擎。这样一个引擎配套有一个 SDK，访问 Native 的基础能力和数据运算能力，可以看成是一个阉割版的 Hybrid SDK 额外增加了一些数据处理能力。 问题结束了吗？处理逻辑的时候还需要用到2个库： cheerio 和 sql 。因为都是 Node 工程，所以纯粹的 JS 环境是没办法直接执行。所以需求就进行了转变 ———— 将 Node 项目打包成 UMD 规范。这样就可以在纯粹的 JS 环境下运行。接下来的文章就分析下各种规范。其实也就是前端模块化的几种规范。 前端模块化开发的价值 随着互联网的飞速发展，前端开发越来越复杂。本文将从实际项目中遇到的问题出发，讲述模块化能解决哪些问题，以及以 Sea.js 为例讲解如何进行前端的模块化开发。 恼人的命名冲突 我们从一个简单的习惯出发。我做项目时，常常会将一些通用的、底层的功能抽象出来，独立成一个个函数，比如 function each(arr) { // 实现代码 } function log(str) { //

PyJs JavsScript Framework 项目地址： https://github.com/demix/PyJs 文档地址: http://demix.github.com/pyjs/ 这里的PyJs，不是已有的 Pyjamas ， 暂不具体说PyJs是个神马东东，只说一句：PyJs是依赖于python的一个符合commonjs规范的浏览器端JavaScript Framework。所以，不喜欢写js有环境依赖的，可以点浏览器的x了，不好意思占用各位时间。 继续看的童鞋门，我们先来说一下commonjs。 Commonjs模块 wiki地址 http://wiki.commonjs.org/ module 1.1.1规范 http://wiki.commonjs.org/wiki/Modules/1.1.1 commonjs 的目标是定义一套普通应用程序使用的API，从而填补原生JavaScript标准库过少的缺点。终极目标是实现一个像python,java中含有的标准库。现在非常火爆的nodejs实际上就是commonjs的一个实现。 commonjs的module 1.1.1基本设计思路如下： Module上下文中，有一个require的函数。require接受一个module标志量，返回一个目标模块的api接口； Module上下文中，有一个exports变量

一、模块化概念 将一个复杂的程序依据一定的规则(规范)封装成几个块(文件), 并进行组合在一起； 块的内部数据与实现是私有的, 只是向外部暴露一些接口(方法)与外部其它模块通信。 二、模块化作用 为什么要用模块化的JavaScript？ 因为在实际的开发过程中，经常会遇到变量、函数、对象等名字的冲突，这样就容易造成冲突，还会造成全局变量被污染； 同时，程序复杂时需要写很多代码，而且还要引入很多类库，这样稍微不注意就容易造成文件依赖混乱； 为了解决上面的的问题，我们才开始使用模块化的JS，所以说模块化的作用就是： 1、避免全局变量被污染 2、便于代码编写和维护 三、模块化历程 1、普通写法（全局函数及变量） 其实只要是不同的函数或变量放一起就是简单的模块，这样弊端很明显，就是变量容易被污染； var name = '卡卡'; function cat1(){ name = '年年'; } function cat2(){ name = '有鱼'; } 2、对象封装 将整个模块放在一个对象里面，外部访问时直接调用对象的属性或者方法就行 var cat = { name:'卡卡', cat1:function(){ var name = '年年'; console.log(name); }, cat2:function(){ var name = '有鱼'; console.log

什么是模块化 模块化其实是一种规范，一种约束，这种约束会大大提升开发效率。将每个js文件看作是一个模块，每个模块通过固定的方式引入，并且通过固定的方式向外暴露指定的内容。 按照js模块化的设想，一个个模块按照其依赖关系组合，最终插入到主程序中。 模块化的方法 普通方法 优点：可以直接调用。 缺点：变量可能会出现重复造成的污染，并且无法进行结构性分类。 function a ( ) { console . log ( "a" ) ; } function b ( ) { console . log ( "b" ) ; } a ( ) ; b ( ) ; 对象的写法 优点：变量不会被直接污染，并且易于分类描述内容。 缺点：会暴露所有成员，内部状态可以被外部改写。 var obj = { _a : false , a : function ( ) { console . log ( "a" ) ; } , b : function ( ) { console . log ( "b" ) ; } } ; obj . a ( ) ; obj . b ( ) ; obj . _a = 3 ; 立即执行函数 优点：外部代码无法读取到里面的_num变量，保证了变量不被污染。 var obj = ( function ( ) { var _num = 3 ; return { a :