前言前端模块化主要解决两个问题——“命名空间冲突”和“文件依赖管理”。坑___Namespaceconflicts为什么我自己测试的代码合并后和大家冲突了？页面脚本的变量或函数覆盖公共脚本。坑___文件依赖管理明明项目中需要导入的包都导入了，为什么还报漏包？手动管理依赖，哪天要更换某个插件。需要深入代码，修改如下图所示。关系很复杂。在F.js中，并不清楚一个变量是来自C.js，还是E.js加载同一个模块两次。比如JQ的其他陷阱，介绍了两次。为了实现脚本重用，在每个页面中都引入了一个很大的公共文件，里面的一些函数只供个别页面使用。某个函数的函数组函数与另一个函数的函数组放在一起，用注释分隔。目前的解决方案是：模块化命名空间：每个模块的命名空间都是独立的。模块A的变量x不会覆盖模块B的变量x模块依赖：由webpack/requireJS/browserify等模块管理工具管理模块化的基本原则——解决命名空间冲突的缺陷JavaScript，首当其冲的是全局变量。这让你每次要给变量命名都要三思而后行，生怕上面无限远有同事的代码跟自己冲突。以下是一些预防方法1、使用命名空间代码如下：//Definevarmodule={name:'rouwan',sayName:function(){console.log(this.name)}}//使用vara=module。姓名;console.log(a)总结：直接修改name不会影响module.name，一定程度上保护了命名空间。有两个缺点。首先，模块的属性和方法仍然可以在外部修改。第二，名称空间有时会超出您的想象。适合一些小包，比如一些配置。2、立即执行函数+闭包（实现模块的基本方法）立即函数可以创建作用域，闭包可以形成私有变量和函数//创建varmodule=(function(){varprivateName='inner';//私有变量varprivateFunc=function(){//privatefunctionconsole.log('privatefunction')}return{name:'rouwan',//publicattributesayName:function(){//publicfunctionconsole.log(this.name)}}})()//Usingmodule.sayName();//'rouwan'总结：这是目前常用的模块定义方式，可以区分私有成员和公共成员。公共变量和方法可以像以前一样直接通过module.name修改。私有变量和方法不能被访问，除非给你一个公共方法来修改私有成员。3.在上面的基础上，引入其他模块//Definevarmodule1=(function(mod){varprivateName='inner1';varprivateFunc=function(){console.log('privatefunction1')}return{name:'rouwan1',sayName:function(){console.log(this.name)},anotherName:mod.name,//另一个模块上的公共参数sayAnotherName:mod.sayName//另一个模块上的公共方法}})(anotherModule)//引入了另一个模块//总结使用module1.sayOtherName()：可以在一个模块中引入另一个模块。4.其他方法放大模式等是过去管理大模块和拆分文件的方法。现在webpack等模块化工具已经很完善了，似乎有点落伍了。我就不介绍了。告别刀耕火种的时代——模块化构建工具（解决依赖管理）了解js模块启动即刻执行功能。但是当我真正使用构建工具的时候，我发现业界采用的模块化方案并不是立即函数+闭包形成的集群。相反，使用模块化实现，例如AMD/CMD/CommonJS/ES6模块。这可能有几个原因。第一，闭包的表现。其次，当模块数量增加时，需要解决模块之间的依赖管理问题。关于依赖管理，目前项目有几个不爽的地方：就这一张图，不用说jq在html中引入了两次，导致脚本报错。有一个公共脚本，其中包含N个以上的公共模块。有些页面明明只用了一个模块，还得重新加载一遍。因此，必须使用模块化的管理工具！几个概念性的包管理工具：安装、卸载、更新、查看、搜索、发布包。比如需要安装jq等，通过npm安装。npm中有依赖管理。jq或express升级后，原来的code就不能用了。帮助你的是npm。模块化构建工具：webpack/requireJS/seaJS等都是用来组织前端模块的构建工具（loader）。按需加载是通过使用模块化规范（AMD/CMD/CommonJS/es6）的语法来实现的。例如，如果有一天您不必维护一个很长很长的公共脚本文件，感谢它。模块化规范：AMD/CMD/CommonJS/es6等模块规范，规范你的代码组织方式。一般这样写的代码是浏览器无法识别的，需要模块化的构建工具打包编译成浏览器可以识别的文件。从我的表中，你可以看到我推荐的搭配---npm+webpack+es6module。原因如下：npm和bower对比：原来使用bower的好处是适合前端模块管理，而npm被认为只适合后端管理。但是随着webpack的流行，毫无疑问npm赢了。npm+webpack可以很好的实现前端模块管理。webpack和requireJS比较：几种模块化规范的比较：所以就看你的了！npm+webpack+es6模块。
