Using light module development approach for front end leaves a couple of questions open in regards of: How to use it and distribute changes on life systems.

A main problems I see is:

• how to guarantie that the newest changes in light modules are distributed 100% equally trough all instances?
• how can a customer know which node has wich state of resources loaded? (How can I be sure public2 has the same resources as public1 or public3).
• When setting magnolia.develop=false changes in the light modules (file system) are detected, BUT the JS & CSS is still served cached. And we have no mechanism to flush the caceh on public instances (except activating something).

My suggestion:
We could define a simple best practice approach:
They are observed & loaded & managed on the author, and distributed to publics as (JCR) CMS content via the publication mechanism.
Meaning that on the life public instances the resources are not loaded form a light module in the file system, but from a distribution over JCR.

• the author loads the light modules from the file system
• It provides a possibility to create a "live" set of it -> copy them into JCR repo.
  This is in oposite to a "hot fix", its a recursive creation of the whole light module. Of all in it, not just one file.
  Either all or none, not split-able (except by hot-fixing one singly).
• This "live" set would be published.
• A version of the whole tree would be created.

What it solves / advantages:

• All the main mechanisms we already have: Hot fixing for JCR copies. The loading cascading (classpath/filesyste/jcr), Publishing with transactional activation.
  So not that much would have to be developed.
• On public its all within the CMS -> clone one public, you have it.
  No need to think about the file system & resources in scope of public instances.
• Transactional activation ensures that its in sync on all publics.
• JCR versioning would provide:
  • Clear knowledge of what was when active
  • Possibility to roll back
• As its activation of content, Cache will automatically flush -> JS & CSS are re cached.
• Also simplifies for OnDemand, plugging in more Public nodes on the fly.
• It is not contradicting of using on life a file system approach., just remove the activation possibility on the author.

I see the chance of defining a convenient approach which can be easily be understood and sold.
A proper & clear "best practice", rather than that every customer needs to find a way to use it, even all they want is using it a simple/standard way..
And it is not restrictive to anybody, you can still use any file system based approach in combination with Git etc if needed.