RequireJS进阶:配置文件的学习 - 推酷
RequireJS进阶:配置文件的学习
Requires强大灵活的运用是通过配置文件决定的。通过配置文件我们可以给模块取别名、给模块加上版本标识、设置模块依赖、包装非模块等强大功能。同时RequireJS的优化器也大量使用了配置选项，如果你使用grunt、gulp等构建工具的话，也有必要深入的学习配置文件的使用。
下面通过示例来进行深度的探讨配置文件的使用。
配置文件的位置
配置文件的位置和声明用法是相对于Requires这个脚本文件来决定的。假如配置文件在Requires脚本的下方，则可以这样使用：
&script src=&scripts/require.js&&&/script&
require.config({
baseUrl: &/another/path&,
&some&: &some/v1.0&
waitSeconds: 15
require( [&some/module&, &my/module&, &a.js&, &b.js&],
function(someModule, myModule) {
//This function will be called when all the dependencies
//listed above are loaded. Note that this function could
//be called before the page is loaded.
//This callback is optional.
这种情况一般都是把配置参数写到require.config里面。如果配置文件在Requires脚本的上面，则是另外一种用法了，示例代码如下所示：
var require = {
baseUrl: &/another/path&,
&some&: &some/v1.0&
waitSeconds: 15
&script src=&scripts/require.js&&&/script&
这种情况下由于require.js后加载，那么直接使用require.config就会报错，这时候就只能通过声明一个全局的变量来注入配置参数来实现了。
这时，你可能会发问了，改用那种情况呢？我只能说根据你具体的业务来选择某种场景。配置是活的，人也是活得。业务也是活的，所以这个没有统一的答案，再有甚者，你可以两个结合使用。
除了要注意配置文件的位置要灵活使用之外，以下有几点还是要注意的，这算是最佳实践吧。
配置文件单独成一个文件，不要跟具体的业务模块耦合。
最好使用 var require = {} 的形式而不是 window.require = {}的形式。后者在IE中运行不正常。
在决定配置位置后，下面就是配置文件的参数了，RequireJS包含了大量的参数，这也是配置文件的核心，具体明细如下。
配置文件参数的介绍
所有模块的查找根路径。所以上面的示例中，&my/module&的标签src值是&/another/path/my/module.js&。
当加载纯.js文件(依赖字串以/开头，或者以.js结尾，或者含有协议)，不会使用baseUrl。
因此a.js及b.js都在包含上述代码段的HTML页面的同目录下加载。
如未显式设置baseUrl，则默认值是加载require.js的HTML所处的位置。如果用了data-main属性，则该路径就变成baseUrl。（
所以最佳实践还是推重使用baseUrl
baseUrl可跟require.js页面处于不同的域下，RequireJS脚本的加载是跨域的。唯一的限制是使用text! plugins加载文本内容时，这些路径应跟页面同域，至少在开发时应这样。优化工具会将text! plugin资源内联，因此在使用优化工具之后你可以使用跨域引用text! plugin资源的那些资源。
path映射那些不直接放置于baseUrl下的模块名(这相当于跟冗长的模块名取个简介的名字)。设置path时起始位置是相对于baseUrl的，除非该path设置以&/&开头或含有URL协议（如http:）。在上述的配置下，&some/module&的script标签src值是&/another/path/some/v1.0/module.js&。
用于模块名的path不应含有.js后缀，因为一个path有可能映射到一个目录。
路径解析机制会自动在映射模块名到path时添加上.js后缀
。在文本模版之类的场景中使用require.toUrl()时它也会添加合适的后缀。
在浏览器中运行时，可指定路径的备选(fallbacks)，以实现诸如首先指定了从CDN中加载，一旦CDN加载失败则从本地位置中加载这类的机制。（回调函数，这个可以跟踪脚本加载是否成功。）
ps:paths映射的模块不一定是标准的AMD模块，但是最佳实践推荐是有意义的模块。
为那些没有使用define()来声明依赖关系、设置模块的&浏览器全局变量注入&型脚本做依赖和导出配置。
下面有个示例，它需要 RequireJS 2.1.0+，并且假定backbone.js、underscore.js 、jquery.js都装于baseUrl目录下。如果没有，则你可能需要为它们设置paths config：
requirejs.config({
//Remember: only use shim config for non-AMD scripts,
//scripts that do not already call define(). The shim
//config will not work correctly if used on AMD scripts,
//in particular, the exports and init config will not
//be triggered, and the deps config will be confusing
//for those cases.
'backbone': {
//These script dependencies should be loaded before loading
//backbone.js
deps: ['underscore', 'jquery'],
//Once loaded, use the global 'Backbone' as the
//module value.
exports: 'Backbone'
'underscore': {
exports: '_'
deps: ['bar'],
exports: 'Foo',
init: function (bar) {
//Using a function allows you to call noConflict for
//libraries that support it, and do other cleanup.
//However, plugins for those libraries may still want
//a global. &this& for the function will be the global
//object. The dependencies will be passed in as
//function arguments. If this function returns a value,
//then that value is used as the module export value
//instead of the object found via the 'exports' string.
//Note: jQuery registers as an AMD module via define(),
//so this will not work for jQuery. See notes section
//below for an approach for jQuery.
return this.Foo.noConflict();
//Then, later in a separate file, call it 'MyModel.js', a module is
//defined, specifying 'backbone' as a dependency. RequireJS will use
//the shim config to properly load 'backbone' and give a local
//reference to this module. The global Backbone will still exist on
//the page too.
define(['backbone'], function (Backbone) {
return Backbone.Model.extend({});
RequireJS 2.0.*中，shim配置中的&exports&属性可以是一个函数而不是字串。这种情况下它就起到上述示例中的&init&属性的功能。 RequireJS 2.1.0+中加入了&init&承接库加载后的初始工作，以使exports作为字串值被enforceDefine所使用。
那些仅作为jQuery或Backbone的插件存在而不导出任何模块变量的&模块&们，shim配置可简单设置为依赖数组：
requirejs.config({
'jquery.colorize': ['jquery'],
'jquery.scroll': ['jquery'],
'backbone.layoutmanager': ['backbone']
但请注意，若你想在IE中使用404加载检测以启用path备选(fallbacks)或备错(errbacks)，则需要给定一个字串值的exports以使loader能够检查出脚本是否实际加载了(init中的返回值不会用于enforceDefine检查中)：
requirejs.config({
'jquery.colorize': {
deps: ['jquery'],
exports: 'jQuery.fn.colorize'
'jquery.scroll': {
deps: ['jquery'],
exports: 'jQuery.fn.scroll'
'backbone.layoutmanager': {
deps: ['backbone']
exports: 'Backbone.LayoutManager'
&shim&配置的重要注意事项:
shim配置仅设置了代码的依赖关系，想要实际加载shim指定的或涉及的模块，仍然需要一个常规的require/define调用。设置shim本身不会触发代码的加载。
请仅使用其他&shim&模块作为shim脚本的依赖，或那些没有依赖关系，并且在调用define()之前定义了全局变量(如jQuery或lodash)的AMD库。否则，如果你使用了一个AMD模块作为一个shim配置模块的依赖，在build之后，AMD模块可能在shim托管代码执行之前都不会被执行，这会导致错误。终极的解决方案是将所有shim托管代码都升级为含有可选的AMD define()调用。
&shim&配置的优化器重要注意事项:
您应当使用 mainConfigFile build配置项来指定含有shim配置的文件位置，否则优化器不会知晓shim配置。另一个手段是将shim配置复制到build profile中。
不要在一个build中混用CDN加载和shim配置。示例场景，如：你从CDN加载jQuery的同时使用shim配置加载依赖于jQuery的原版Backbone。不要这么做。您应该在build中将jQuery内联而不是从CDN加载，否则build中内联的Backbone会在CDN加载jQuery之前运行。这是因为shim配置仅延时加载到所有的依赖已加载，而不会做任何define的自动装裹(auto-wrapping)。在build之后，所有依赖都已内联，shim配置不能延时执行非define()的代码。define()的模块可以在build之后与CDN加载代码一并工作，因为它们已将自己的代码合理地用define装裹了，在所有的依赖都已加载之前不会执行。因此记住：shim配置仅是个处理非模块(non-modular)代码、遗留代码的将就手段，如可以应尽量使用define()的模块。
对于本地的多文件build，上述的CDN加载建议仍然适用。任何shim过的脚本，它们的依赖必须加载于该脚本执行之前。这意味着要么直接在含有shim脚本的build层build它的依赖，要么先使用require([], function (){})调用来加载它的依赖，然后对含有shim脚本的build层发出一个嵌套的require([])调用。
如果您使用了uglifyjs来压缩代码，不要将uglify的toplevel选项置为true，或在命令行中不要使用 -mt。 该选项会破坏shim用于找到exports的全局名称。
ps:shim配置是所有配置中最繁琐也是最容易出问题的选项，我一般用来处理css依赖，最佳实践是能不用，尽量不用shim配置。
对于给定的模块前缀，使用一个不同的模块ID来加载该模块。
该手段对于某些大型项目很重要：如有两类模块需要使用不同版本的&foo&，但它们之间仍需要一定的协同。 在那些基于上下文的多版本实现中很难做到这一点。而且，paths配置仅用于为模块ID设置root paths，而不是为了将一个模块ID映射到另一个。
requirejs.config({
'some/newmodule': {
'foo': 'foo1.2'
'some/oldmodule': {
'foo': 'foo1.0'
如果各模块在磁盘上分布如下：
newmodule.js
oldmodule.js
当“some/newmodule”调用了“require('foo')”，它将获取到foo1.2.js文件；而当“some/oldmodule”调用“`require('foo')”时它将获取到foo1.0.js。
该特性仅适用于那些调用了define()并将其注册为匿名模块的真正AMD模块脚本。并且，请在map配置中仅使用绝对模块ID，“../some/thing”之类的相对ID不能工作。
另外在map中支持“*”，意思是“对于所有的模块加载，使用本map配置”。如果还有更细化的map配置，会优先于“*”配置。示例：
requirejs.config({
'foo': 'foo1.2'
'some/oldmodule': {
'foo': 'foo1.0'
意思是除了“some/oldmodule”外的所有模块，当要用“foo”时，使用“foo1.2”来替代。对于“some/oldmodule”自己，则使用“foo1.0”。
提供了统一脚本，不同版本的支持。
常常需要将配置信息传给一个模块。这些配置往往是application级别的信息，需要一个手段将它们向下传递给模块。在RequireJS中，基于requirejs.config()的config配置项来实现。要获取这些信息的模块可以加载特殊的依赖“module”，并调用module.config()。示例：
requirejs.config({
size: 'large'
color: 'blue'
//bar.js, which uses simplified CJS wrapping:
//http://requirejs.org/docs/whyamd.html#sugar
define(function (require, exports, module) {
//Will be the value 'large'
var size = module.config().
//baz.js which uses a dependency array,
//it asks for the special module ID, 'module':
///jrburke/requirejs/wiki/Differences-between-the-simplified-CommonJS-wrapper-and-standard-AMD-define#wiki-magic
define(['module'], function (module) {
//Will be the value 'blue'
var color = module.config().
若要将config传给包，将目标设置为包的主模块而不是包ID:
requirejs.config({
//Pass an API key for use in the pixie package's
//main module.
'pixie/index': {
apiKey: 'XJKDLNS'
//Set up config for the &pixie& package, whose main
//module is the index.js file in the pixie folder.
packages: [
name: 'pixie',
main: 'index'
PS: config在我的项目中没有被用到过，不过值得关注，另外对于第二种情况，本人不太熟悉，后期会开一篇文章介绍。
从CommonJS包(package)中加载模块。参见从包中加载模块。（链接：
PS：目前还没遇到这样的场景，关注中...
nodeIdCompat
Node treats module ID example.js and example the same. By default these are two different IDs in RequireJS. If you end up using modules installed from npm, then you may need to set this config value to true to avoid resolution issues。
(翻译：Node对待模块example.js和example是一样的.默认在RequireJS中有两个不同的标识。如果你通过npm安装且使用模块结束，那么你可能需要设置这个参数为true来避免这个问题。)
waitSeconds
在放弃加载一个脚本之前等待的秒数。设为0禁用等待超时。默认为7秒。
命名一个加载上下文。这允许require.js在同一页面上加载模块的多个版本，如果每个顶层require调用都指定了一个唯一的上下文字符串。想要正确地使用，请参考多版本支持一节。
指定要加载的一个依赖数组。当将require设置为一个config object在加载require.js之前使用时很有用。一旦require.js被定义，这些依赖就已加载。使用deps就像调用require([])，但它在loader处理配置完毕之后就立即生效。它并不阻塞其他的require()调用，它仅是指定某些模块作为config块的一部分而异步加载的手段而已。
在deps加载完毕后执行的函数。当将require设置为一个config object在加载require.js之前使用时很有用，其作为配置的deps数组加载完毕后为require指定的函数。
enforceDefine
如果设置为true，则当一个脚本不是通过define()定义且不具备可供检查的shim导出字串值时，就会抛出错误。参考在IE中捕获加载错误一节。
如果设置为true，则使用document.createElementNS()去创建script元素。
RequireJS获取资源时附加在URL后面的额外的query参数。作为浏览器或服务器未正确配置时的“cache bust”手段很有用。使用cache bust配置的一个示例：
urlArgs: &bust=& +
(new Date()).getTime()
在开发中这很有用，但请记得在部署到生成环境之前移除它。
scriptType
指定RequireJS将script标签插入document时所用的type=&&值。默认为“text/javascript”。想要启用Firefox的JavaScript 1.8特性，可使用值“text/version=1.8”。
skipDataMain
Introduced in RequireJS 2.1.9: If set to true, skips the data-main attribute scanning done to start module loading. Useful if RequireJS is embedded in a utility library that may interact with other RequireJS library on the page, and the embedded version should not do data-main loading.
(翻译：在2.1.9中被引入：如果设置为true,就会跳过data-main属性的扫描启动模块的加载。如果RequireJS嵌入到一个通用的库中以其他页面中的RequireJS交互，且嵌入的版本不会使用data-main加载)
PS:翻译不标准，请告知，另外这个属性用的不多，暂时没什么实践经验。
中文翻译：
ps:翻译不标准、涉及文章侵权、文章有错误的地方请告知。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致requirejs 如何针对不同的页面 加载不同的js? 【新手】 - CNode技术社区
这家伙很懒，什么个性签名都没有留下。
今天刚看requirejs ，想问下，假设两个页面
需要加载的文件
A 页面 ： login.js list.js jquery.js
B页面：update.js jquery.js
请问requirejs 如何针对不同页面加载不同配置（一个配置文件里面)？
只有写两种不同配置文件这种方式吗？
不用任何配置，自动就实现了。你require哪个就加载哪个。
比如b页面只 require了 update.js和 jquery.js， 那B就只加载这2个。
那你的意思不还是需要些两个配置文件吗？ 一个页面一个i
配置文件一般一个就可以了吧，为什么要两个？配置文件就是写写别名呀，依赖呀什么的，使用的时候需要加载哪个require哪个就行了。
楼主解决了吗？ 我也遇到这个问题。
最终你是一个页面，一个js吗？
你在A页面require
login.js list.js jquery.js，B页面require
update.js jquery.js就行
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的2720人阅读
javascipt（36）
前端开发（24）
requirejs、require方法冲突如果加载了多个requirejs脚本，每个requirejs会判断是否浏览器已经实现了require和define方法。如果浏览器已经自带require和define方法，或者之前已经有一个requirejs脚本执行，那么这个requirejs就会立刻停止执行。所以，即使页面上加载了多次requirejs脚本也不会有什么问题。配置Context我把context叫做一个命名空间，因为每一个context都有一个名字，这样同名而功能不同的模块就可以放在不同的context中以防冲突。如果开发人员没有配置context，那么，requirejs还会生成一个默认的context，这个默认的context配置大致如下：requirejs.config({&&& context: &_&,& // default context name&&& baseUrl: &./&,&&& waitSeconds：7, // how long canloading last&&& paths: {},&&& bundles: {},&&& pkgs: {},&&& shim: {},&&& config: {}});注意：在不指定context名称的情况下，任何配置和调用都是针对默认context的修改和调用。空间名称 – context如果requirejs初始化时自定义配置context，那么默认创建的context的name 就是”_”。如果需要添加新的context，只需指定一个新的contextName即可，比如下面这个调用就会创建一个新的context：requirejs({context:”new content name”});同名的context只会有一个，配置同名的context等于修改这个context的属性。加载超时 – waitSeconds每个context都配置了一个加载超时的时间，某个模块如果没有初始化，加载的时间又超过了这个时间，就会被认为加载失败。加载超时是针对整个context下的所有模块而言的，而不是单指某个模块，也就是说这个默认的7秒是指所有模块应该在7秒之内全部加载完成。7秒之后，如果有没有被加载的模块，将抛出error指示哪些模块没有加载。（requirejs每隔50毫秒做一次判断）。基准URL – baseUrl每个context的基准URL默认值是”./”。第一个context的基准URL如果开发人员没有指定context名称，那么这个第一个context就是requirejs默认生成的context，否则就是开发人员自己定义的context。在不指定基准URL的前提下，第一个context的基准URL设定比较特殊，除了标准的设定方法（参考后面的基准URL标准设定方法），还可以使用以下两种特殊方式设置：第一种：通过requirejs或require对象配置在确认requirejs脚本之前没有其它requirejs执行过的前提下：&script&requirejs={baseUrl: './'}&/script&&script data-main=&scripts/app.js&src=&../require.js&&&/script&或&script&require={baseUrl: './'}&/script&&script data-main=&scripts/app.js&src=&../require.js&&&/script&注意：通过这种方式设置基准URL，data-main指定的脚本文件位置也会变成相对于基准URL的路径，因为data-main指定的脚本本身只是依赖的关系之一。而且，data-main指定的脚本也属于第一个context。比如下面这种情况：&script&requirejs={baseUrl: 'scripts/lib'}&/script&&script data-main=&scripts/app.js&src=&../require.js&&&/script&脚本模块app.js的最终路径变成了&scripts/lib/scripts/app.js&，不是原来的&scripts/app.js&，而且它的依赖名称也会变为scripts/lib/scripts/app（requirejs默认会去掉脚本路径的最后一个“.js”，除非data-main的值以“/”开头，或包含“:”，或包含“?”）。第二种：根据script元素的data-main属性指定的脚本路径计算如果没有设定baseUrl，requirejs会根据script元素data-main属性指定的JavaScript文件路径计算出一个基准URL。比如data-main=&scripts/app.js&，那么baseUrl就是&scripts/&：&script data-main=&scripts/app.js&src=&../require.js&&&/script&基准URL标准设定方法除了第一个context可以使用上面的方法，其它自定义的context配置baseUrl就只能使用下面这两种方法。但这两种方法同样也可以用来修改第一个context的属性，在不指定context名称的情况下，其实就是修改第一个context。通过requirejs或require方法（这两个本身就是同一个方法）设置以下两个等于把默认命名空间的基准URL设置成了scripts/lib：requirejs({baseUrl:'scripts/lib'});require({baseUrl:'scripts/lib'});通过requirejs.config方法requirejs.config({baseUrl:'scripts/lib'});require.config({baseUrl:'scripts/lib'});其实config方法调用的就是requirejs方法，所以它们是一样的。模块依赖 – deps模块依赖是指个模块之间的相互依赖关系，脚本运行时，只有当依赖的模块全部加载完成之后，当前脚本才会执行，这就是依赖关系的作用。依赖关系使用数组配置，数组元素为字符串（即模块的名称），一般是相对于baseUrl的路径，只不过没有文件后缀。而且，为了比较方便的获取模块入口，模块一般会通过define方法定义。因为，通过define定义的模块，可以被依赖数组后面的回调函数直接获取并使用。以jQuery为例，在jQuery脚本的末尾一般有下面两行代码：if(typeof define === &function&&& define.amd && define.amd.jQuery) {&&& define(&jquery&, [], function () { return jQ } );}再以underscore为例，在脚本末尾有下面几行代码：if (typeof define === 'function' && define.amd) {& define('underscore', [],function() {&&& return _;& });}模块和模块位置使用require配置依赖模块的时候，只是声明了模块的名称，却不知道模块的具体位置。在没有特殊声明的情况下，requirejs认为模块名和文件名相同，因此，只要两者一致，requirejs就可以正确找到脚本文件。但如果不同，就需要通过path配置：requirejs.config({&&& baseUrl:&scripts/lib&,&&& paths: {&&&&&&& jquery:'jquery-1.7.2'&&& }});这样，requirejs就知道jquery模块位于scripts/lib/jquery-1.7.2.js文件中。第一个context的依赖关系&script&requirejs={deps: ['jquery']}&/script&&script data-main=&scripts/app.js&src=&../require.js&&&/script&其它context的依赖关系与基准URL的方式一样，既可以通过requirejs方法，也可通过requirejs.config方法配置。模块束-bundles如果一个JS文件中有多个模块，就可以使用模块束的方式声明：requirejs.config({&&& baseUrl:&scripts/lib&,&&& bundles: {&&&&&&& jsUtil:['MathUtil', 'DateUtil']&&& }});上面这个例子就是说在scripts/lib/jsUtils.js文件中有MathUtil和DateUtil这两个子模块。JS包– packages如果一个文件夹中有多个JS文件，使用path的方式写全就需要很多行代码，这个时候如果使用包的方式声明就可以省去很多麻烦：requirejs.config({&&& baseUrl:&scripts/lib&,&&& pkgs: [{name:'jqueryui',location: 'jqueryui/',main: 'core'}]});这样定义之后，凡是在scripts/lib/jqueryui/目录下的模块就可以通过这种方式正确找到：require(['jqueryui/button', 'jqueryui/dialog']);上面这个例子就是获取scripts/lib/jqueryui/button.js和scripts/lib/jqueryui/dialog.js的例子。另外，因为jqueryui是一个目录，并不对应一个JS文件，所以又有一个main属性，这个属性一般对应这个JS包中的主程序文件。上面的例子中，jqueryui的主程序就在scripts/lib/jqueryui/core.js中。楔子 – shim并不是所有的JS模块都会像jquery和underscore那样调用define方法定义自己，这样requirejs就不知道你这个模块的入口在哪，该通过哪个对象来调用这个模块，特别是那些早版本的JS模块，因为那是还没有define和require的概念。requirejs.config({&&& baseUrl:&scripts/lib&,&&& shim: {jquery: {deps:[],exportsFn: func, exports：'jQuery',init:func}}});虽然模块没有使用define方法定义自己，但开发人员应该是知道如何获取文件中的模块的，所以，requirejs提供了两种方式让开发人员把模块对象返回给requirejs管理：在exportsFn或init方法中设置，然后作为返回值；使用exports设置，比如”a.b.c”，那requirejs就知道通过window.a.b.c可以获取。映射 – Map先来看问题：一些第三方JS插件的依赖关系是事先设定好的，不太好修改依赖模块的名称，而如果某个模块有多个版本或有其他模块和它同名，则使用上面的配置都无法解决问题。比如path只是解决模块名称到路径的问题，而这个面对的是切换模块名称的问题。于是requirejs提出了映射的概念，根据当前脚本的名称动态修改所依赖模块的ID，是它指向正确的模块。假如在你的硬盘下有以下几个模块：foo1.0.jsfoo1.2.jssome/newmodule.jssome/oldmodule.js在newmodule.js和oldmodule.js中都有require(‘foo’)调用，要解决冲突只需要这样配置即可：requirejs.config({&&& map: {&&&&&&& 'some/newmodule':{&&&&&&&&&&& 'foo': 'foo1.2'&&&&&&& },&&&&&&& 'some/oldmodule':{&&&&&&&&&&& 'foo':'foo1.0'&&&&&&& }&&& }});主程序入口data-main&script data-main=&scripts/app.js&src=&../require.js&&&/script&不管页面上有多少个script元素有data-main属性，requirejs只认最后一个script元素的data-main属性，忽略其他script元素的data-main属性。Requirejs获取data-main属性之后，并没有立即执行data-main指定的脚本文件（因为这个脚本文件可能还依赖了其他模块），而是把它作为了一个被依赖的模块，加入到第一个context的依赖数组中。比如下面这种情况就是把scripts/app这个模块加到一个名叫linus的context中：&script type=&text/javascript&&&&& requirejs={&&&&&&& context: 'linus', &&&&&&& baseUrl:&./&, &&&&&&& skipDataMain: false&&& };&/script&&script data-main=&scripts/app.js&src=&../require.js&&&/script&全局配置忽略script元素的data-main在浏览器中，有一个选项叫skipDataMain，可以让requirejs忽略script元素的data-main。在默认情况下，requirejs成功加载之后，会立马查找页面上所有script元素，并且把最后一个有data-main属性的script元素的data-main最为主程序入口。&script&requirejs={skipDataMain:true}&/script&&scriptdata-main=&scripts/app.js&src=&../require.js&&&/script&模块定义 – define(name, deps, callback)你会发现define方法没有指定context名称，这是因为define方法只调用于被依赖的模块中，而require方法已经为依赖的模块指定了context名称，所以，这个模块被哪个context需要，它就属于那一个context。参数name是模块的名称，deps是该模块所依赖的其他模块的名称，callback一般返回该模块的实际可被使用对象。比如jQuery的模块定义回调函数返回的就是jQuery对象。Error加载Error这种error就是浏览器自带的Error对象，只不过requirejs给它附加了其他属性。message的格式为：msg + '\nhttp://requirejs.org/docs/errors.html#' + id。error.requireType就是就是message后面的id；error.requireModules一般指需要加载却没加载成功的模块名称；error.originalError是指发生其他错误导致模块加载失败的原始error对象。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：605275次
积分：6898
积分：6898
排名：第2477名
原创：143篇
转载：17篇
译文：12篇
评论：84条
(2)(1)(4)(2)(2)(3)(1)(1)(2)(3)(8)(2)(1)(3)(2)(1)(3)(2)(1)(4)(1)(1)(1)(3)(4)(2)(2)(4)(1)(4)(1)(2)(1)(1)(2)(1)(1)(2)(2)(1)(4)(2)(2)(8)(4)(5)(17)(5)(8)(3)(1)(5)(7)(17)(3)(1)(1)