https://replit.com/@pedrolucaslimas/AMD-e-INTEL?s=app

I'm reading the common config documentation at CommonConfig.md and couldn't find the definition for 'Absolute Module ID'. It's used quite a bit and I have not been able to deduce what it means exactly, only that it has been explicitly distinguished from a module prefix ID.

My main concern is determining what module ID's in the loader configuration is resolvable via the paths config item.

I have an extensive background in writing software specifications (I wrote the gzip and zlib RFCs) and would like to help tighten up the AMD API documentation to a solid interoperable spec. Here are the issues I have noted.

1. What value does 'define' return? Proposal: The 'undefined' value. (I do not consider it acceptable to leave this unspecified.)

2. The doc says the module id should default to "the id of the module that the loader was requesting for the given response script." This introduces the concepts of "loader" and "response script" that are neither part of the JS specification nor of the AMD specification. JS code is normally loaded simply by virtue of appearing in a "script" element on a HTML page: the "loader" is built into the browser, and there is no module id involved, only a file name. Proposal: Start by clarifying what the doc means.

3. In "module id format", the documentation says "Relative identifiers are resolved relative to the identifier of the module in which 'require' is written." Proposal: Clarify that this only applies to the 'require' callback passed to the factory function, and that the global 'require' does not allow relative identifiers.

4. What is the value of a module (the value returned by 'require')? Proposal: If the factory is an object, or if the factory function returns a value that tests as true, it is that object/value; otherwise, it is the value of 'exports', even if 'exports' was not passed to the factory function (in which case it is an empty object). (The former is in the doc already, but the latter is not.)

There are also issues shared by 'define' and 'require' related to module ids:

5. MAY or MUST 'define' and 'require' normalize the module name by (1) removing embedded '.' parts and (2) removing '..' parts where there is a preceding part? E.g., a/./b normalizes to a/b, a/b/../c/d normalizes to a/c/d, and a/../../d/e normalizes to ../d/e. Proposal: they MUST normalize.

6. Are module names starting with '..' after normalization allowed? E.g., If module 'a/b' asks for '../../d', the normalized form is '../d'. Proposal: they are not allowed (MUST throw an error).

7. MAY or MUST 'define' and 'require' throw an error if a module identifier does not have the proper syntax? Proposal: they MUST throw an error.

I may have missed some further details: these are the ones I encountered in the process of doing my own implementation of the API.

Regarding discussion, please note that I will not participate in any Google service such as Google Groups, given Google's stated goal of annihilating meaningful individual privacy and information autonomy.

AMD is not really asynchronous

The only thing which is asynchronous is the loading of dependencies.

But the definition itself is not really asynchronous. According to the specification the module is defined when factory function is executed and exports is detected.

Bad example:
A module depends on a module which provides only a method to call your callback on a delayed ready state, but your module also wants to provide a ready state.

And what if an other module depends on my example module?
We will run in a crazy chain of such modules ...

define(["domReady"], function (domReady) {
    var isReady = false,
        cbStack = [];

    domReady(function () {
        isReady = true;
        while (cbStack.length >= 1) {
            (cbStack.unshift())();
        }
    });

    return function (callback) {
        if (isReady) {
            callback();
        } else {
           cbStack.push(callback);
        }
    });
});

Asynchronous definition

So the module should be able to say: I'm done.

The defined status of a module should be asynchronous according to the factory function.

The idea of an asynchronous definition is, to delay the detection of exports. If the detection of exports is done, the definition of the module is done too.

Two known implementations

Currently there are 2 pull requests on RequireJS with implementations of asynchronous exports. Both are closed because we should discuss this on the amdjs-api first.

@demurgos - #1078 - A new distinct resolution dependency named delay

define(["delay"], function (delay) {
    var Module = {};

    setTimeout(function () {
        delay(Module);
    }, 1000);
});

pro:

• simply to use, just set this dependency, the exports is defined as asynchronous

contra:

• the name of a new distinct resolution dependency could cause conflicts in existing projects
• current implementation doesn't take care for exports priority

@evanvosberg - #1075 - A new property on the module dependency

define(["module"], function (module) {
    var asynchronousExports = module.async(),
        Module = {};

    setTimeout(function () {
        asynchronousExports(Module);
    }, 1000);
});

pro:

• low risk of conflicts in existing projects by providing a method on the existing distinct resolution dependency module

contra:

• one more call within the factory function to get the asynchronous exporter

Priority of different exports (low - high):

If factory is a function:

• if ["exports"] is in the dependencies list exports will be exported
• if ["module"] is in the dependencies list module.exports will be exported, note that module.exports and exports are the same object if module.exports is not reassigned within the factory
• if the call of asynchronousExports hands over one parameter (an object, function, or any value that coerces to true) it will be exported
• if factory function returns a value (an object, function, or any value that coerces to true) it will be exported

If factory is an object

• factory itself will be exported

Indication of support

Additional property on the define.amd object. Name should be discussed, here is one suggestion.

define.amd = {
    async: true
};

Is there a cogent reason that parameter id is optional?

I would prefer, that it would be required.

If so, the implementation of define could be run free of file specific context and would be easy and resource load could be done with better performance.

If not, define have to get the default id from the requested script filename and so it needs for every loaded module a own context.

From the API Wiki:

This specification reserves the global variable "require" for use by module loaders.
Module loaders are free to use this global variable as they see fit. They may use the
variable and add any properties or functions to it as desired for module loader
specific functionality. They can also choose not to use "require" as well.

And also in the Module Specification we have a function require. But this both functions with the same name, are very different.

So I would suggest, that you do not take the same name for two different function. That is confusing and provokes misunderstandings.

Maybe you could call the global "require" instead "use" or "load".

I don't think that the definition of a module's "id" is very clear. It appears that it can be anything (good), but in the absence of a module having declared its id then anonymous ids appear to be derived from a module's path with no ".js" extension (you show an example of this).

Using paths for anonymous modules makes sense, but I wonder if we can have this clarified in the specification.

Thanks.

Script loaders should execute the factory function for CommonJS-style modules regardless of whether all dependencies were successfully resolved. Any errors in resolution should instead be thrown by the local require function. This would more closely mimic the behavior of CJS environments and enable module authors to handle unsatisfied dependencies. Authors could then specify "optional" dependencies (which currently cannot be expressed with AMD):

define(function(require) {
  var Backbone = {};
  var _ = require('underscore');

  try {
    Backbone.$ = require('jquery');
  } catch(err) {}

  // etc.
});

Hi,

Coming from GitHub, it is not very easy to get to the AMD page in the Wiki. And the Home page is not informative.

I would suggest to make AMD the Home page; it is possible to rename the title in the Home page to make it AMD. The issue is that the URL would become https://github.com/amdjs/amdjs-api/wiki instead of https://github.com/amdjs/amdjs-api/wiki/AMD.

As a temporary/alternate fix, I added a link to the API Specification in the Home page.

Cheers,

Eric Bréchemier

There are several advanced loaders, like require.js, curl, bdLoad.
Besides that there are several smaller synchronous loaders, like almond or there are different optimizers.

I don't know all of them, and I couldn't find a wiki page listing them. Maybe it's a good idea to have a list of all compatible libraries/loaders/builders?

In the Loader Plugins spec, I would find it useful to spell out what
happens when multiple plugins are chained.

For example, consider a dependency of the form,

define(['foo!bar!../resources/thing'], function(thing) { /* ... */ });

My first question is, is this allowed?

If it is allowed, what order should the plugin load() and normalize()
methods be called and what should be given as the resource id in each
invocation? It seems to me that there are a few possibilities:

Option A, plugins are applied from right-to-left and the normalized
dependency name is passed to the next plugin:

1. bar.normalize('../resources/thing', fn);
2. bar.load('/root/resources/thing', require, load);
3. foo.normalize('bar!/root/resources/thing', fn);
4. foo.load('bar!/root/resources/thing', require, load);

Option B, plugins are applied from right-to-left and each plugin gets
the original resource id:

1. bar.normalize('../resources/thing', fn);
2. bar.load('/root/resources/thing', require, load);
3. foo.normalize('../resources/thing', fn);
4. foo.load('/root/resources/thing', require, load);

Option C, the leftmost plugin is applied and is responsible for
interpreting the other plugin applications:

1. foo.normalize('bar!../resources/thing', fn);
2. foo.load('bar!/root/resources/thing', require, load);

In my personal option Option A is the way to go. I think that Option
B does not make much sense and that Option C, while providing the most
flexibility, pushes unnecessary work onto plugin implementations.

There is a complication with Option A though, which is that the Plugins
API does not appear to allow a loaded dependency to be passed from
plugin to plugin - only the dependency name can be forwarded. That
could make it difficult to implement a dynamic, chainable plugin.

Is there precedent for one of these options in the RequireJS
implementation?

Not sure if there's a better place to ask this, but this repo/issues tracker seemed as good as any.

I have to admit to not having much experience playing with some of the popular AMD implementations. It's not clear from the spec how things like requirejs's config.path fit into the big picture. I guess there's some allowance in the AMD spec to allow implementations to have flexible means of resolving module references to actual modules.

I'd like to expand on this. I am currently more or less familiar with node.js's module search algorithm, which involves things like rooting through relevant node_module directories, looking for relevant package.json files, etc. I would actually like to be able to use exactly this lookup scheme in AMD.

A little more; it needs to also work with "built" AMD runtimes like almond.

I don't necessarily want to "bake this into" an AMD implementation; I would prefer it to be a pluggable strategy that I can provide to AMD before it's gears start grinding away.

Not sure how closely related this is - it might be the answer to my feature request - is to provide a hookable function like node's require.resolve() - this is the only reference I could easily find to this function. The basic idea is to allow someone else to provide the name/module lookup, presumably given the 1) module executing the require(), 2) the string value of the module being require()d.

Perhaps there's some other way of accomplishing this.

My use case here is to be able to take a directory full of js files being used in node, and be able to run them unchanged, in the same way, as node, but using AMD. I'm willing to pay a price of creating some "fake" modules for directories, package.json file contents, etc, to make this happen. And again, end of the day, and all I really care about anyway, is being able to run this with a "built" runtime like almond.

See definejs for an example implementation and usage

I'd like to request that the AMD 'define()' have the following signatures:

define(module value | module factory)
Defines an anonymous module, extracting its ID from the module's path. If a module factory is specified then the factory is called and the module's value will be equal to its return value.

define({/* properties of the module */});

define(function() {
  return {
    /* module properties */
  };
});

define([dependency array of module IDs], module value | module factory)
Defines an anonymous module, extracting its ID from the module's path. If a module factory is specified then the factory is called with the values of each dependent module loaded from the dependency array, and the module's value will be equal to the factory's return value. The module factory will only be called after each dependency has loaded and the dependcies wil be passed to the factory in the same order as the dependency array.

define(['a', 'b'], {/* module properties */});

define(['a', 'b'], function(a, b) {
  return {
    /* module properties */
  };
});

define(module ID, [dependency array of module IDs], module value | module factory)
Defines a named module, where the specified module ID is used for caching instead of the modules path. If a module factory is specified then the factory is called with the values of each dependent module loaded from the dependency array, and the module's value will be equal to the factory's return value. The module factory will only be called after each dependency has loaded and the dependcies wil be passed to the factory in the same order as the dependency array.

define('myModule', ['a', 'b'], {/* module properties */});

define('myModule', ['a', 'b'], function(a, b) {
  return {
    /* module properties */
  };
});

define({imports}, module value | module factory) [new signature]
Where 'imports' is an object where each key is the name of an import and whose value is a dependent module ID. Defines an anonymous module, extracting its ID from the module's path. If a module factory is specified then the factory is called with an object where each key from the imports object equals the corresponding loaded module. The module's value will be equal to the factory's return value. The module factory will only be called after each dependency has loaded.

define({a: 'a', b: 'b'}, {/* module properties */});

define({a: 'a', b: 'b'}, function(imports) {
  return {
    /* imports.a and imports.b are the module values from loading 'a' and 'b' */
    /* module properties */
  };
});

define(module ID, {imports}, module value | module factory) [new signature]
Where 'imports' is an object where each key is the name of an import and whose value is a dependent module ID. Defines named module, where the specified module ID is used for caching instead of the modules path. If a module factory is specified then the factory is called with an object where each key from the imports object equals the corresponding loaded module. The module's value will be equal to the factory's return value. The module factory will only be called after each dependency has loaded.

define('myModule', {a: 'a', b: 'b'}, {/* module properties */});

define('myModule', {a: 'a', b: 'b'}, function(imports) {
  return {
    /* imports.a and imports.b are the module values from loading 'a' and 'b' */
    /* module properties */
  };
});

The following signatures are not so import to include, but offer an object-literal technique, so that the arguments are
are explicitly named and easier to understand when reading code.

define({module: module value | module factory})

define({id: module ID, module: module value | module factory})

define({imports: {imports}, module: module value | module factory})

define({id: module ID, imports: {imports}, module: module value | module factory})

NOTES:

At the very least I'd would love to see the addition of the import object. The advantage of using an import object is that the import name of each module being imported is given at the same location where the dependency is specified and not in the module factory signature. This permits a module factory to have one formal paramter for all imports which much easier to read for modules that have several dependencies.

I think it would be great to standardize some methods of RequireJS. For example, require.defined gives bool (if module was already loaded), and I don't think this is too specific to include it into AMD.

I've recently became very interested in AMD and decided to implement a pure, 100% to spec, no reliance on jQuery implementation; a no-frills-pure-to-the-bone implementation if you will.

I've gotten almost the complete specification implemented except for plugins at the moment. It seems that the plugin tests, offered via a link on this wiki, depend on a 'fromText()' function to be present on the 'load()' function that is passed in via a plugin's own 'load()' method. The 'fromText()' is not actually specified in the AMD spec for plugins.

I did in fact find it in the Plugins section on the RequireJS website however. Can you update the AMD spec to include this new function or simply rewrite the tests to not rely on this function?

Thanks,
Darren

I was looking at https://github.com/amdjs/amdjs-api/blob/67486d6b199cd026f5e66151566836c8ba149099/LoaderPlugins.md and couldn’t find anything obviously sticking out on how a loader plugin should communicate load failure. It doesn’t seem like load() should be called when there is an error. Should there be a new error callback or something?

I would like to implement a subset of AMD for Static Module Definition (SMD).

I have two use cases in mind:

• static loading of optimized scripts combining several modules
• static loading of one module per script file during development in platforms that do not support dynamic loading

I have developed a partial implementation of AMD for the first use case here:
https://github.com/eric-brechemier/lb_js_scalableApp/blob/master/src/amd/define.js

I plan to develop a more limited implementation for the LIME Starter Kit project, using a subset of JavaScript, for TV sets:
https://github.com/eric-brechemier/lime-starter-kit

I feel like 3 areas of the code are oversized for a basic implementation:

• management of optional arguments of define() from line 84 to 102
• management of relative dependency identifiers from line 114 to 165
• management of reserved dependency identifiers from line 189 to 204

I would suggest to define a property, define.amd0 or define.smd, for basic implementations that claim only support for:

• define(id, dependencies, factory) with all arguments included, with their types fixed to string, array and function
• absolute identifiers in id and dependencies
• no reserved module identifiers: "module", "exports", "require"

Modules using the basic syntax may still be loaded by full-featured AMD script loaders. It may be possible to convert (most of) existing modules to the basic syntax in optimization tools.

The wiki states that an AMD loader only needs to provide one global: The “define” function.

It’s unclear what the main entry point of a program that uses multiple modules is.

E.g., when writing a program that uses modules “a”, “b”, and “c”, how would that look like?

I assume that

define(['a', 'b', 'c'], function(a, b, c) {
  // main functionality here
});

would never be executed.

Hello everyone,

i stumbled about these two methods on stackoverflow

are these part of the standard? Or will they become part of the standard?

Thank you very much
Philipp

https://github.com/amdjs/amdjs-api/blob/master/CommonConfig.md#config-

While reading through the CommonConfig file, I noticed that modules can have special configuration options set. What's the use case for this? Are developers actively using this feature now? I ask because I've never seen it used in production or any third-party AMD code I've come across.

My worry is that this feature makes the baseline configuration more convoluted and pollutes the Simplified CommonJS form.

If a module needs a configuration, why not expose a mechanism within the module itself to receive such configuration? Why is this a concern of the module loader? So many questions, is there a resource I can read to get more background on this feature?

If the plugin has a dynamic property set to true, then it means the loader MUST NOT cache the value of a normalized plugin dependency, but instead call the plugin's load method for each instance of a plugin dependency.

How does this work in the case where you are using CJS wrapper syntax?:

define(function (require) {
  var foo = require('dynamic-plugin!foo');
});

With the spec as written, this would be valid:

1. Loader runs RegExp against the factory function to collect dependencies
2. Loader loads 'dynamic-plugin!foo', but discards the result because the plugin is dynamic
3. Loader executes the factory function
4. Synchronous call to require('dynamic-plugin!foo') fails because the result was not cached

I would suggest an update to the spec stating that the value of the dependency should be cached until after the factory function holding the dependency has executed.

I'm thinking about a potential evolution in the AMD spec that could be thought of a semantic version major upgrade. I want to be able to break the parts that may not work as well anymore, and implement new ideas that may work better. If you've had any thoughts on this as well and would like to vet them, please join the discussion in the issue below:

tbranyen/amd-next#1

Any strings containing multiple paths, or URLs, like the dependencies in AMD:

• Should be separated by a character that is not valid in the most common file systems
• Or there should be a way of escaping the separator character(s).

The current spec prevents the module paths from being correctly resolved when any of them contains an exclamation mark.

Problematic part

If Loader Plugins are supported in the AMD implementation, then "!" is used to separate the loader plugin's module id from the plugin's resource id. Since plugin resource ids can be extremely free-form, most characters should be allowed for plugin resource ids.

Suggestions

• Change the separator to | - which is not valid in a path in all of the file systems I know (many code changes)
• Have a way to escape ! in a path. even as simply as doubling it up: !!
• Have a way to enclose full paths, akin to how CSV cells are enclosed

I think that the "dependencies" section is missing some details. What is special with the dependency name "exports"? What should happen if a module definition lists the "exports" dependency, and at the same time its factory function returns a value? Here is an example of that behavior:

https://github.com/Reactive-Extensions/RxJS-DOM/blob/921c35a28265466cda7fc2dcdbacfe688efcd456/rx.dom.js#L25

Should the return value of the factory function be used in this case, or should you save the "exports" object as the module value?

I think the section "Transporting more than one module at a time" is missing some details. Can you have multiple define calls made within a single script if you don't specify the id argument?

The "commonConfig" document defines a set of configuration options that AMD script loaders should support. It does not specify how these options can actually be specified.

The AMD specification is incomplete without this detail. Consumers are forced to find and use a custom, non-standard API in order to specify standardized information. This makes application code less portable generally.

As a strawman proposal, consider a new config method defined on the global define function. Example usage:

define.config({
  baseUrl: './foo/bar'
});

If the specification were hosted in the project repository (as opposed to the wiki), discussion could occur through issues and pull requests, and they could reference specific line numbers.

cookies.js:21 Uncaught ReferenceError: define is not defined at cookies.js:1

cookies.js
define('cookies',function (){ var docCookies = { getItem: function (sKey) {.... }, setItem: function (sKey, sValue, vEnd, sPath, sDomain, bSecure) {..... }, removeItem: function (sKey, sPath, sDomain) {... }, hasItem: function (sKey) {... }; return { 　　　docCookies: docCookies 　　}; });
也就是当我通过define函数去定义一个AMD规范的模块的时候，页面信息提示define函数未定义
https://developer.mozilla.org/en-US/docs/DOM/document.cookie 即为我希望按照AMD规范定义的cookies模块

The example code for global require looks wrong for me:

https://github.com/amdjs/amdjs-api/wiki/require#requirearray-function-

define(function (require) {
      require(['a', 'b'], function (a, b) {
          //modules a and b are now available for use.
      });
  });

If I am right, the require inside the factory function is the local require (got it as argument) and not the global require. Example should be something like this:

define(function (require) {
          // local require
          var a = require('a'); 
});

// global require
require(['a', 'b'], function (a, b) {
          //modules a and b are now available for use.
});

Hi Team,

Could you please explain us why in the require.js file the below define.amd is set to jquery.

define.amd = {
jQuery: true
};
I could not understand why it is set as true the above lines of code by default, when I download the require.js file from the official website.

Thanks in advance.

However, if the factory function's arity (length property) is less than 3, then the loader may choose to only call the factory with the number of arguments corresponding to the function's arity or length.

This optional loader behavior for factory arity < 3 is unnecessary and introduce potential inconsistency.

Prior ES6, arguments can be used to get actual arguments; and in ES6+, the arity of function (a, b = 0, c) is 1. In both cases, the loaders which choose or not choose this behavior will have different results.

This paragraph also make some misunderstanding of allowing loader not call factory if arity == 0, like babel/babel#3620 try to solve.

Suggestion: Just remove it.