automate dependency configuration

[springuper]

Nowadays, YUI3 has lots of modules, and the same as our project. A problem is becoming more and more obvious: configuration of module dependencies is very annoying, some times missing some modules, sometimes overloading some modules, and the latter occurs frequently.

So, why not let machine do this complicated job?

Our team is now trying to automate dependency configuration. The simple idea is to build a API-module map, so that a new module dependency can be determined through parsing code and API calculation. But we find out that, some YUI modules don't expose APIs, instead, they just mix some properties to prototype, like node-event-delegate. In such situation, manual intervention is necessary.

Maybe there are other better ways to automate dependency configuration, any idea is appreciated.

Do YUI team has any plan to automate dependency configuration? Can you help us make the API-module map more accurate?

[hojberg]

At Swipely we are using a grunt plugin I built for this: https://github.com/hojberg/grunt-yui-config.

I don't think this is something that belongs in core, but tools like yogi might be a good spot?

[tivac]

At ArenaNet we've been using https://github.com/tivac/yui-configger to build our config objects. Agree that this doesn't need to be in core.

@davglass's fabled grifter project should help with this, someday.

[juandopazo]

@ipeychev of AlloyUI has a tool that uses Esprima for figuring out which classes are used and generate requirement lists from that https://github.com/ipeychev/yui-modules-explorer

[springuper]

Thanks to all of you!

This tool should not belong in core, but I think YUI should make API-module map more clearly. IO module is a bad case:

// require 'io-base' module
Y.io(url, {
    data: ...,
    on: { ... }
});

// require 'io-form' module
Y.io(url, {
    form: { id: ndForm },
    on: { ... }
});

// require 'io-xdr' module
Y.io(url, {
    xdr: { ... },
    on: { ... }
});

[ipeychev]

Mapping modules by properties is not (yet) handled. In addition to the example above, in which Modules explorer currently will discover only 'io-base' module, here is another common case, copied directly from YUI examples:

Y.one('#ac-input').plug(Y.Plugin.AutoComplete, {
    resultFilters    : 'phraseMatch',
    resultHighlighter: 'phraseMatch'
});

Here we have to match again properties to modules and in addition to 'autocomplete-plugin', two more modules have to be loaded.

I definitely think the approach I've chosen - to parse the AST and extract the info about the modules from YUI data.json file is the right one. Modules explorer is not finished, more work have to be done there, so if your team is interested - welcome.