What about adoption to AMD?

[qfox]

I don't see much changes in modules.require vs System.import, except in AMD dependencies can be file names.

But there are some differences in define:

modules.define(
  {String} moduleName,
  [{Array.<String>} dependencies,]
  {function (
    {function ( resolution, [{Error} error] )} provide,
    {Array.<*>} ...imports,
    [{*} prev]
  )} declarationFunction
);

What if we will compare dependencies.length with declarationFunction arity and decide with mind on that how to call declarationFunction?

It will help us to use modules as AMD module loader.

Is there any other problems or differences between current ym functionality and AMD standard?

Why I ask? Because ES6 modules comes to us. And I think about using ymodules for ES6 modules.

[dfilatov]

What if we will compare dependencies.length with declarationFunction arity and decide with mind on that how to call declarationFunction?

What does it mean? Could you provide an example?

[qfox]

> declarationFunction = function (provide, import1, prev) {}
[Function]
> declarationFunction.length
3

And somewhere inside modules.define:

if (dependencies.length === declarationFunction.length) {
  // AMD with declarationFunction.call(...);
} else {
  // currentBehaviour
}

[dfilatov]

We sometimes specify some kind of dependencies which isn't used directly then within declarationFunction. It will be broken in such cases.

[qfox]

You mean something like:

function (provide) {
  provide(arguments); // that?
}

I don't see it's conflicting somehow. By default it will use the current behavior.

But anyway we have setOptions to set the default approach.