Add support for multiple apps

[paulmillr]

It would be nice to unify brunch approach to building very complex apps, modularity etc.

• app/ should no longer be created by default. Instead, there should be a directory, that has the same name as <app>. E.g. forum for brunch new forum.
• Load paths for everything should start from paths.root instead of paths.app. There should be no special case for app/.
• assets/ and vendor/ directories of every app should have special meaning, like they have today. Of course, their presence should be absolutely optional.
• Changing of paths.assets / paths.vendor should be prohibited.
• paths.app should be deprecated, instead, apps or perhaps paths.apps should be added.
• Because it will be probably backwards-breaking, it would require version bump to 2.0.

Still not sure:

• What if user has many (10+) apps? Root directory will be very dirty. Maybe there should be an apps directory for this and other use cases (and no config param at all).
• Where should default skeletons contain app files? <app name>/app or <app name>?

Example of new structure

apps/
  forum/
    assets/
    controllers/
    models/
    views/
    vendor/
  admin/
    assets/
    controllers/
    models/
    views/
    vendor/
  chaplin/
    controllers/
    models/
    views/
config.coffee
node_modules
package.json
public/
README.md
vendor/ (optional)

[paulmillr]

/cc @saiwong @alexeyPetrushin

[saiwong]

how would it work if I wanted to build just one app?

should we support syntax like:

brunch build forum

[jokull]

Are you thinking that 3rd party apps could be shipped to include in your project?

[paulmillr]

@jokull yes. Just like in Django.

[paulmillr]

@saiwong perhaps. This requires prototyping.

[jokull]

IMHO the Django app approach never worked out that well. Then again Django has no app object to work with. An app object is crucial for a successful extension community. It should define how extensions register and interact.

Could it be that we need more from Chaplin to do this nicely? Maybe better to keep brunch an assembler, not a framework. Chaplin defines an app object and a structure for other apps to follow.

Just brainstorming, don't take the criticism too seriously ;)

[al6x]

Agreed, these changes allows great flexibility and at the same time shouldn't make API & config more complex.

I personally prefer a little different structure (code below), but it seems that proposed API will support both, so it's not a problem.

forum/
  assets/
  controllers/
  models/
  views/
  vendor/
admin/
  assets/
  controllers/
  models/
  views/
  vendor/
chaplin/
  controllers/
  models/
  views/
config.coffee
node_modules
package.json
public/
README.md
vendor/ (optional)

how would it work if I wanted to build just one app?

Hmm, but why do You may want to build just one module? If there's performance considerations - maybe it's better to solve it via incremental cache & compilation?

What if user has many (10+) apps? Root directory will be very dirty. Maybe there should be an apps directory for this and other use cases (and no config param at all).

It seems that this use case can be also supported by the same API (without introducing special apps folder) using following config:

paths.apps [
  'apps/forum'
  'apps/site'
  ....
]

or just

# paths.apps (and every other paths) can accept both single value or array.
paths.apps:  'apps'

[jokull]

+1 on not having a special apps folder.

[chrismcv]

If we're making a wish list, some form of incremental loading per module would be really nice in this context... e.g the browser defers loading of forum until required, or once main app is loaded...

[paulmillr]

Yep, brunch don't want to become a framework. Just looking for good ways of modularity.

@alexeyPetrushin

incremental cache & compilation

This is already done, brunch watcher / compiler caches everything that can be cached (well, except GeneratedFile).

[al6x]

If we're making a wish list, some form of incremental loading per module would be really nice in this context... e.g the browser defers loading of forum until required, or once main app is loaded...

As far as I know You already can do this by splitting Your code into different files:

      joinTo:
        'app.js'    : /^app/
        'vendor.js' : /^vendor/

You can implement different loading strategies with it.

[damassi]

+1 to keeping Brunch as simple and bare-bones as possible with an optional plugin architecture for extensions (e.g., Chaplin). Enthusiasm so quickly leads to needless bloat, and I can see it on the horizon.

[paulmillr]

Since 1.4 (β):

• assets/ and vendor/ directories of every app have special meaning. No more need to use config.paths.assets.
• app/, test/ and vendor/ became sort of applications directories.

[blaine]

Just voicing my support for this feature; I'd like to have a separate app for administrative tools, so that unprivileged users can't go digging around in my code to discover those tools. At the same time, I'd like it to be easy to use the existing code in my (already managed by brunch) app, and have everything deployable as a single package.

[blaine]

Actually, just after posting my comment here, I've found a workaround.

What I've ended up doing is:

joinTo:
  'javascripts/app.js': /^app(\/|\\)(?!admin)/
  'javascripts/admin.js': /^app(\/|\\)(?=admin)/

which achieves the "multiple app" effect I was looking for. Hope that helps others.

[markmarijnissen]

If you want multiple apps, use multiple brunch instances.

Unless you want to share code, assets or vendor files.

In which case, you can configure config.coffee to bundle files as you please, no need for special tricks that bloat brunch.
(Use a function in config.coffee to automatically bundle javascript-source-files in seperate output files)

Sometimes, you want conditional packaging; i.e. use "audio-ipad.js" on ipads and "audio-web" on browsers.
It would be convenient if you could set global variables in the config; i.e.

globals
   platform: "ios"

Then you could do the right require based on this variable.

Alternatively, you could have rename-rules in your config; i.e. ignore all "-ipad.js" and rename ".*-web.js" to "$1.js" but this seems clumsy. (Although it keeps your actual code more clean).

Or, using AMD and require.js, you could create "main configs" that alias modules depending on which version you need.

[paulmillr]

So I think brunch 1.4 apps fit greatly for multiple app env already, as per latest comments.