Re-write Aura as a single-file library

[addyosmani]

Covers Core, Sandbox and Permissions. There will be some tricky plumbing required to get this working but it should be possible.

[addyosmani]

Initial work for this checked in under addyosmani/backbone-aura@4a233fc. I'll continue working in branch on this. Happy for anyone else to pitch it.

Current status is that the demo app renders but we're getting a bunch of type errors. I assume this is related to some breakage occurring in how components are now being pulled in.

[addyosmani]

I'm tempted for us to drop the idea of Aura being a single library. On the contrary I feel like the developers using us are already using RequireJS, like the idea of modularity and pulling in our dependencies isn't a pain point. We could be opinionated in that way and instead focus on providing a great architecture, better support for the feature RequireJS does expose under the sheets (or plugins which help with that).

@sindresorhus @gersongoulart what do you think?

[sindresorhus]

I absolutely agree. There's a good reason jQuery is going the opposite way single-file -> modular.

[addyosmani]

Glad to hear you agree :)

[atesgoral]

I've tackled a similar tricky plumbing for a library that I'm currently working on. If you don't mind, I can take a stab at this for 1.0. The way I've done it is, the library in question works identically minified, or as exploded sources, just as yet another library sitting inside the lib folder from an application's perspective. I think Aura should act like a library instead of a scaffold.

The Aura project can be restructured as follows:

+-- <src>
|   +-- aura.js
|   +-- <aura>
|       +-- base.js
|       +-- core.js
|       +-- sandbox.js
|       +-- permissions.js
+-- <samples>
|   +-- <todos>
|       +-- <css>
|       +-- <js>
|       |   +-- <widgets>
|       |   +-- app.js
|       |   +-- permissions.js
|       |   +-- config.js
|       +-- <lib>
|       |   +-- <requirejs>
|       |   +-- <underscore>
|       |   +-- <backbone>
|       |   +-- ...
|       +-- <nls>
+-- <doc>
+-- <test>

To be honest, I was mildly confused as to what file was for what, and what the boundaries of Aura were, when I first started looking at this project. I think a folder organization like the above could help clear things up.

All the sample application assets would clearly be enclosed inside the samples folder. src would be reserved for Aura code only.

The aim of the redundant aura folder inside src is to allow the modules to be located using the same paths both in minified and non-minified distributions.

I don't have an answer for where the Backbone extensions should reside. Are they a part of Aura? Should they come with the sample todos application? Or should extensions lie inside an entirely different extensions folder, or even their very own repos?

[addyosmani]

Thanks for kickstarting off this discussion again. I think there are a few parts to this.

• I agree that the current folder structure is confusing and do prefer the suggested changes.
• In my mind, the Backbone extension should exist as a separate file (or plugin). That said, I see this as not being as important as most people should be using Aura with a build process.
• If we're able to offer up a single-file 'build' version of the library whilst still offering modularity, that would be the best of both worlds and I'd certainly be up for us landing that.

I have concerns about us trying to tackle this for 1.0, even though I would love that. I remember how long it took me to get the POC put together in a way that many of the parts actually worked sans RequireJS and I'd worry that we might end up spending a lot of time working on this that could be spent landing other 1.0 features, docs or tests.

For now, would we be down for the directory structure changes once incoming PRs for the rest of our milestone land? :)

[atesgoral]

@addyosmani I agree. A change to both the project structure and build process could be very upsetting during the 1.0 crunch. I could still work on a PoC when I find the time...

Off-topic question: Me having direct write access to this repo -- does it mean I can take the liberty to directly make changes for minor, low risk stuff like typos? Or should I always stick to the PR process?

[addyosmani]

Yes! Any minor changes can be made directly. Please feel free to.

[sbellity]

@addyosmani I guess we can close this one now ?

[addyosmani]

Yes!