把自己的js模块兼容到AMD CMD CommonJS

为了让同一个模块可以运行在前后端,在写作过程中需要考虑兼容前端也实现了模块规范的环境。为了保持前后端的一致性,类库开发者需要将类库代码包装在一个闭包内。以下代码演示如何将hello()方法定义到不同的运行环境中,它能够兼容Node(CommonJS),AMD,CMD以及常见的浏览器环境中:

(function (name, definition) {
    //检测上下文环境是否为AMD或CMD
    var hasDefine = typeof define === ‘function‘;
    //检查上下文环境是否为Node
    var hasExports = typeof module !== ‘undefined‘ && module.exports;

    if(hasDefine) {
        //AMD环境或CMD环境
        define(definition);
    } else if(hasExports) {
        //定义为普通Node模块
        module.exports = definition();
    } else {
        //将模块的执行结果挂在window变量中,在浏览器中this指向window对象
        this[name] = definition();
    }
})(‘hello‘, function () {
    var hello = function () {};
    return hello;
});

兼容原理和我们平常做浏览器兼容的原理是一样的,无非就是能力检测和怪癖检测。

时间: 2024-09-29 16:32:03

把自己的js模块兼容到AMD CMD CommonJS的相关文章

浅析JS模块规范:AMD,CMD,CommonJS

随着JS模块化编程的发展,处理模块之间的依赖关系成为了维护的关键. 模块化 AMD,CMD,CommonJS是目前最常用的三种模块化书写规范. CommonJS CommonJS规范是诞生比较早的.NodeJS就采用了CommonJS.是这样加载模块: var clock = require('clock'); clock.start(); 这种写法适合服务端,因为在服务器读取模块都是在本地磁盘,加载速度很快.但是如果在客户端,加载模块的时候有可能出现"假死"状况.比如上面的例子中cl

了解JS模块规范:AMD,CMD,CommonJS

随着JS模块化编程的发展,处理模块之间的依赖关系成为了维护的关键. AMD,CMD,CommonJS是目前最常用的三种模块化书写规范. CommonJS CommonJS规范是诞生比较早的.Node.js(是一个Javascript运行环境(runtime))就采用了CommonJS.是这样加载模块: // foo.js module.exports = function(x) { console.log(x); }; // main.js var foo = require("./foo&qu

FW: AMD, CMD, CommonJS和UMD

javascript 我是豆腐不是渣 4月5日发布 推荐 2 推荐 收藏 32 收藏,486 浏览 今天由于项目中引入的echarts的文件太大,requirejs经常加载超时,不得不分开来加载echarts的各个图表.但是使用echarts自带的在线构建工具生成的支持AMD 标准的模块报错,所以不得不使用echarts的全局函数,使用requirejs的shim进行加载.借此机会学习一下AMD, CMD, CommonJS和UMD各自的规范,和它们之间的区别. Javascript模块化 在了

AMD/CMD/CommonJs的区别

AMD/CMD/CommonJs是js模块化开发的标准,目前对应的实现是RequireJs/SeaJs/nodeJs. CommonJs 主要针对服务器端,AMD/CMD 主要针对浏览器端. 服务器端和浏览器端有什么区别呢? 服务器端一般采用同步加载文件,也就是说需要某个模块,服务器便停下来,等待它加载再执行,而浏览器要保证效率,需要采用异步加载,这就需要一个预处理,提前将说需要的模块并行加载好. AMD和CMD的区别,虽然都是并行加载文件,但还是有所区别,AMD是预加载,在并行加载js文件同时

AMD,CMD.CommonJs和UMD还有es6的模块化对比

CommonJS CommonJS是服务器端模块的规范,Node.js采用了这个规范. 根据CommonJS规范,一个单独的文件就是一个模块.加载模块使用require方法,该方法读取一个文件并执行,最后返回文件内部的exports对象. 例如: // foobar.js //私有变量 var test = 123; //公有方法 function foobar () { this.foo = function () { // do someing ... } this.bar = functi

amd cmd commonjs 模块规范 和 es6 的 module 语法

js的模块化 在前端开发的原始时期,只要在script标签中嵌入js代码就能实现一些基本的交互效果,但是随着时代的进步.js扮演的角色变得重要起来,js应用的场景页越来越复杂,.然而,js都没有类的概念,更不用说模块了. 为什么要有模块化 当一个项目变得复杂的时候,会出现问题,比如:命名冲突:开发中重复命名,导致命名冲突.文件依赖:项目开发中,依赖的js文件,引入遗漏,引入顺序错误. 使用模块化开发可以避免类似情况,而且利于项目的维护:提升开发效率:代码方便重用,能直接引入,避免重复开发.方便后

插件兼容CommonJS, AMD, CMD 和 原生 JS

模块标准 CommonJS CommonJS 有三个全局变量 module.exports 和 require.但是由于 AMD 也有 require 这个全局变量,故不使用这个变量来进行检测. 如果想要对外提供接口的话,可以将接口绑定到 exports (即 module.exports) 上. function MyModule() { // ... } if(typeof module !== `undefined` && typeof exports === `object`) {

JS模块加载器加载原理是怎么样的?

路人一: 原理一:id即路径 原则.通常我们的入口是这样的: require( [ 'a', 'b' ], callback ) .这里的 'a'.'b' 都是 ModuleId.通过 id 和路径的对应原则,加载器才能知道需要加载的 js 的路径.在这个例子里,就是 baseUrl + 'a.js' 和 baseUrl + 'b.js'. 但 id 和 path 的对应关系并不是永远那么简单,比如在 AMD 规范里就可以通过配置 Paths 来给特定的 id 指配 path. 原理二:crea

前端模块规范AMD/UMD/CommonJs

.babelrc文件中的:module设置为false,为什么会要设置成false? 解释:使ES6模块语法转换到另一个模块类型(默认启用“commonjs”). 设置为假则不变换模块.或者传入(“amd”.“umd”,“systemjs”.“commonjs”). 什么是模块? Javascript的组件生态在最近几年的发展很给力,我们的可选性更加广泛了.这本是一件好事,但是当多个第三方Javascript在一起混合使用的时候,我们可能会遇到一个很尴尬的问题,那就是不是所有的组件都能在一起很愉