[loader] Add support for optional dependencies

[juandopazo]

Optional dependencies are modules that are not in the requires list because they depend on a test passing. Contrary to the current condition option, the test is owned by the optional module itself, not by the required module.

Example:

YUI({
    modules: {
        foo: {
            path: 'foo-min.js',
            test: function () {
                return true;
            }
        },
        bar: {
            path: 'bar-min.js',
            optionalRequires: ['foo']
        }
    }
}).use('bar', function (Y) {
  // ...
});

This is WIP. I'm still figuring out what all the edge cases are and this need changes to Shifter to fully integrate it into YUI.

[caridy]

m might not even exist in the registry, so this might return a falsy value, and the if that follows should take that in consideration as well.

normally, modules with affinity can be deployed to specific runtimes, and optionalRequires will facilitate the edge case where a module that is suppose to run in all runtimes (e.g.: server and client) has an optional require on a module that is suppose to run only on a client, and if you have the proper meta generation process per runtime, you don't need to add tests for those modules, just skip it from the undesired runtimes.

[juandopazo]

Got it.

[caridy]

Note: a module with a test should be analyzed during addModule() call, which is the one deciding whether or not the module is good enough for a runtime, while a module with optionalRequires is just an artifact to require things that might not be available in the runtime, they are not bound, which means we can have optionals with and without tests.

[saw]

Hey what is the status of this PR, are you planning on merging or is this dead?

[caridy]

@saw it is not dead, we just hit some roadblocks while doing the review of the code, and the tests. @juandopazo will continue working on this.

That being said, you have a patch in express-yui so you are not blocked by this one. The patch is essentially the same.

[juandopazo]

@ezequiel just helped me find the issue. The sorting function that sorts the list of modules only looks at moduleInfo[foo].requires and we chose not to modify that list, so it's not sorting optional requires correctly.

[juandopazo]

First pass at a solution. Please do not merge this. I'm experimenting with using the ignore and loaded lists and figuring out if I can avoid mutating moduleInfo[foo].requires.

[juandopazo]

Just to have it on the record, can we write here the reasons why this use case isn´t covered by condition?

[caridy]

Here is the full writeup about this issue:
#1585 (comment)

[yahoocla]

CLA is valid!

[juandopazo]

Reproduced the conflict with patterns. Once #1790 is merged this should be good to go.

[juandopazo]

I'm happy to report this PR is now passing and ready to go. Project building YUI and trying to use this feature would still need Shifter to support the new test property of modules.

[caridy]

is this to support Y.use('optionalModule')?

[juandopazo]

This is to avoid attaching the module to the Y when the module has already been included (maybe in a bundle) and its test fails.

It probably deserves a comment.

[caridy]

yeah, add a comment.

[juandopazo]

Comment added!

[caridy]

This line is misleading. Modules without a test will be consider valid modules and will be attached, at least that's what I can infer from the implementation.

[caridy]

LGTM, although I still see some travis failures happening.

[juandopazo]

@caridy that was just a Promise [slightly] flaky test.