Review for package re-org

[subtleGradient]

1. Review all of the things
2. Propose moving some stuff into other MooTools Milk packages
3. Propose splitting off groups of related classes into new Milk packages

Be sure to take into account who tends to work on which things and don't make it unnecessarily difficult to maintain.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/359947-review-for-package-re-org?utm_campaign=plugin&utm_content=tracker%2F22069&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F22069&utm_medium=issues&utm_source=github).

[subtleGradient]

I propose that we go through More and divide it into roughly the following buckets:

MooTools/Base-Extended - this is Array.Extras, String.Extras, Date, URI, Locale, Request.JSONP, etc. Low level utilities that really are core-like in their composition. I think there's wide support amongst the More team to continue supporting these utilities and, indeed, some should move over to the "core" group's ownership.

MooTools/Element-Extended - this is for stuff like Element.Position and Element.Forms. Utilities specific to element. These are often rather heavy-weight (like Element.Position or Element.Measure) as they do a lot of DOM math for you. They aren't UI, but they aren't really Core extensions either.

MooTools/UI-Utilities - maybe the name could be a little better, but I'm reluctant to just call it MooTools/UI - it's not a widget framework. This is basically everything else in More (typically the stuff that Arian, Christoph and others are less enthusiastic about maintaining). Tips, Drag, Form.Validator, Mask, Spinner, Slider, etc. These things are building blocks for building UIs.

This last bunch - the UI-Utils - are the part that Arian and Christoph and others are less interested in maintaining (if I'm reading the other comments here right). Historically, this is the type of stuff I write a lot of (a lot of these came from Clientcide). So I'll continue to maintain these (I would still greatly appreciate help from anyone who has an interest in using them).

-- @anutron, MooTools ML

[subtleGradient]

As for Base-Extended, might it make sense to just move all that stuff to some of the existing Milk repos as separate AMD modules?

[fakedarren]

http://mootools.net/docs/more - See the menu section headings :)

More-Class / More-Types / More-Element / More-Request / More-Fx etc

My ¢2

[arian]

I tend to agree with moving some of Base-Extended in the existing repositories. Preferably as small separate modules so there's no extra weight if you don't use them. But also there is a reduce method in Array.Extras that should go to Milk/Base/Host/Array.

[anutron]

Is there any reason not to have individual js files / modules for each extension? so I can require MooTools/Base/Array* or MooTools/Base/Array.reduce

Is that even possible?

[ibolmo]

Did a quick review, and wildcards are not supported. @jrburke should correct me, though.

The issue with smaller modules (per function, for example) is that you'd have to do:

require(['MooTools/Host/Array.reduce'], function(Array){

   Array.reduce([], ...);

});

Effectively, the modules required gets ridiculously long. We have to consider that there's a practical limit to dividing the modules further and further. We are not the compiler.

It's a zen.

[arian]

Wildcard on the client-side would be pretty impossible if you think about it, because you don't know about the filesystem, you would have to pre-define them, which isn't really the idea about AMD AFAIK.

[ibolmo]

Right @arian. Only possible if you add the dependencies ahead of time. Ala goog.Closure and caldeps.py and the product: deps.js

[jrburke]

@ibolmo and @arian, correct no wildcards. However, relative paths are supported, may reduce typing if things are not too nested, although that does not help for outside consumers of your modules. As @ibolmo indicated, it is a balance between granularity and overwhelming the developer with too much choice.

[anutron]

What I'm not digging about our plans to use this is that our scripts assume a specific directory structure. I.e. require(['MooTools/Host/Array']... implies that my script is in a specific place relative to where MooTools is on the file system. I haven't read up on AMD enough; is there a manifest that lists where these things are or do they have to be relative to the file requiring them?

[ibolmo]

You can define 'MooTools' to be in a specific directory. The path after MooTools, though, has to follow it.

See: https://github.com/ibolmo/mootools-runner/blob/define-2/runner.html#L57-63

I've read, though, that directories is not a great idea. @jrburke could you comment? Are alias the solution?

I'm particular not against Directories. We can keep bc by having a proxy file/directory which requires the new path.

[jrburke]

@ibolmo: correct, normally a loader allows a mapping facility, in requirejs, the paths config can be used to map full parts of the module name to somewhere else on disk:

requirejs.config({
    paths: {
       'MooTools/Host': '../some/dir/Host'
    }
});

In a build, multiple modules are combined into one file, so the module names are just that, names. Similar to how you might expect an API to always be library.area.action(). To avoid a bunch of loader config, the convention is that the names should map nicely onto disk in non-build modes.

MooTools could decide that it is better to have a shallower file structure that could lead to shorter module names, but it depends on the kind of mental map you want to establish for the code.