Add optional standardised module support #2102
Comments
|
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 |
|
Exactly, yes. It should be relatively trivial to implement. The tricky part would be when a single file provides multiple things. I guess the best option would be for the script to add the |
|
👍 @anutron: yes. For example with require.js you can use the |
|
The important thing is that we aggressively stop anyone from bike shedding on the unimportant details. |
|
Without an AMD config that remaps stuff, the require strings map directly to the filesystem. A typical project would simply
So, with this structure and no AMD config, the absolute require path 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 fileCore.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('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...
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. |
I generally agree that CJS+AMD is probably the way to go. However, that should not block supporting AMD asap. My goals are...
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 |
|
Only slightly. Ideally all requires should be at the head of the file, just |
|
Then why not just use the |
|
If we want to use /*<AMD>*/define(['exports', 'foo', 'bar'], function(exports,
8000
foo, bar){(function(){/*</AMD>*/
this.LOL = "yay!" // existing code uses `this` to apply itself to the global object
/*<AMD>*/}).call(exports)}})/*</AMD>*/ |
|
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. |
|
So for now just use what works (standard AMD :D) |
|
Little update, see https://github.com/arian/mootools-core/tree/1.5amd / arian/mootools-core@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! |
|
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 I just wondered what your thoughts were on this? Because I would love to write it. |
|
Go nuts. |
|
Are there still plans to make 1.x AMD compat? |
|
Yes, within a few weeks I'll try to finish https://github.com/arian/mootools-core/tree/1.5cjs. The possible build options will be:
|
|
@arian ++ go go go! |
|
Likely not going to happen anytime soon™. |
Wrap each file in an AMD
define.e.g.
Revision in 2012: Use CommonJS modules instead, maybe with conversion for AMD if relevant.
https://github.com/arian/mootools-core/tree/1.5cjs
The text was updated successfully, but these errors were encountered: