Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Add optional standardised module support #2102

subtleGradient opened this Issue · 28 comments

8 participants


Wrap each file in an AMD define.



// current code here


Revision in 2012: Use CommonJS modules instead, maybe with conversion for AMD if relevant.


Use AMD by default. Disabled by default in the online builder.


We should also include curl.js or RequireJS in the build when AMD is enabled on the online builder. Maybe allow building in both or neither separately from AMD support.



Seems like we could write a little script that does this for you. No?


I'm still not clear if this definition prescribes directory locations or if mootools-core is an alias that maps to some configured location. For exampe, in the code block above you reference mootools-core/Source/Class/Class - can I configure AMD to go look in /lib/core/Source/Class/Class for that file?


Exactly, yes. It should be relatively trivial to implement.

The tricky part would be when a single file provides multiple things.
For that you'd have to include the optional ID string in your define and then have multiple define statements.
Then you'd either have to use an AMD path config to map them all to the actual file, or else duplicate the file for each path. That would be stupid, but it'd work since requiring any one of them would provide the other and then you'd never actually load both, but that's silly.

I guess the best option would be for the script to add the define statements and generate the AMD config object for you with all the mappings.



@anutron: yes. For example with require.js you can use the paths configuration.


The important thing is that we aggressively stop anyone from bike shedding on the unimportant details.
Just add a comment that the specific paths used in your requires are definitely going to change in 2.0.
Until then it doesn't matter what exactly the require paths are. They can always be remapped with an AMD config later.


Without an AMD config that remaps stuff, the require strings map directly to the filesystem.

A typical project would simply git clone each repo into their script folder. e.g. ...

  • /
    • index.html
    • scripts/
      • require.js
      • main.js
      • mootools-core/
      • mootools-more/
      • mootools-plugin-foo/
      • mootools-plugin-bar/

So, with this structure and no AMD config, the absolute require path 'mootools-core/Source/Class/Class' would map to Class.js from anywhere. However, from inside mootools-core itself, we would use relative require paths. So, Class.Extras.js could use the relative require path ./Class instead.

IMHO, we should NOT change the folder/filename structure of the repos before implementing the script and require paths. Sure, the require paths will be ugly until 2.0, but nobody should really care, it's just not a big deal.


Also, since mootools-more is in a separate repo, it'll be in a separate folder and will need to use all absolute require paths to get to the stuff in mootools-core.


I'd rather if it didn't come bundled with RequireJS or curl.js, or at least give an option to leave it out. I would only ever want a simple mini require/define which basically just inserts and retrieves from a modules object.


Multiple provides in a single file

Core.js provides Core, MooTools, Type, typeOf, instanceOf, Native.

The simplest thing to do would be to split Core.js into separate files that only provide a single thing, and then make Core.js simply require them each and then provide them all for you. That way you can require each one individually or get them all by requiring Core itself.

Alternatively we could add multiple define statements with an ID inside Core.js itself asif they had been separate files that be built into a single file using the RequireJS optimizer.

define('mootools-core/Source/Core/Type', [...], ...)
define('mootools-core/Source/Core/typeOf', [...], ...)
define('mootools-core/Source/Core/instanceOf', [...], ...)

@seanmonstar agreed. These would all be options in the builder...

  • Enable/disable the AMD packager removable blocks
  • Include curl.js
  • Include RequireJS
  • Include simple mini require/define

Ideally we should automatically include one of the AMD implementations in the UI when you manually enable AMD. That should keep people from accidentally downloading a build that won't work and then being annoyed. You'd still be able to manually disable the default or choose a different one.


CJS+AMD is so much more beautiful
-- @cpojer

I generally agree that CJS+AMD is probably the way to go. However, that should not block supporting AMD asap. My goals are...

  1. Implement AMD asap
  2. Minimal changes necessary (code & repo structure)
  3. Allow AMD to be disabled (by default) in the online builder / Packager

We should not do anything else that would distract from, or delay, those goals

So, let's make it work first and make it pretty later. All energy on making things ideal should be focused on Milk and the MooTools.Next.


CJS+AMD allows for littering require statements throughout the body of the module code, making it much much harder to disable with Packager removables.


Then why not just use the dependencies argument, it's more readable and shorter.


If we want to use exports, that's easily doable with something like this...

/*<AMD>*/define(['exports', 'foo', 'bar'], function(exports, foo, bar){(function(){/*</AMD>*/

this.LOL = "yay!" // existing code uses `this` to apply itself to the global object


Also, we need to be sure we're running all our tests against the AMD version of the code and with all the AMD stuff stripped out.


@seanmonstar @arian @cpojer It doesn't matter exactly what the boilerplate is, it only matters how much time and how many code changes are required to make it actually function.
We can debate the details in the thread of a pull request once we have one to talk about.


So for now just use what works (standard AMD :D)


Little update, see / arian@1.5wip...1.5amd

Todo: test it more, use the requirejs optimizer, with !amd compat block (extending stuff into the global object), etc.


woah, looking nice!
I'm very excited to see this moving forward

@arian arian was assigned

Good job I searched for this first rather than going straight ahead with it. I was planning on writing a YAML to AMD converter mainly built for MooTools. It would recurse over a directory reading all files and parsing their provides and requires. Then it would map the requires to the files that provide them and finally write them back.

The result would either be an identical directory structure or a completely flat one. The new copy would have every source file wrapped in the correct define call. It would be a separate project to MooTools so people could convert any version they want into AMD.

I just wondered what your thoughts were on this? Because I would love to write it.


Go nuts.
It'd be nice to convert to CommonJS instead. There are already a million things that can convert that to AMD afterward.


Are there still plans to make 1.x AMD compat?


Yes, within a few weeks I'll try to finish The possible build options will be:


@arian ++ go go go!

@subtleGradient subtleGradient referenced this issue in mootools/mootools-more

Simple AMD #1043


Likely not going to happen anytime soon™.

@ibolmo ibolmo closed this
@timwienk timwienk changed the title from Add optional simple AMD support to Add optional simple module support
@timwienk timwienk changed the title from Add optional simple module support to Add optional standardised module support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.