You can get away with the problem of namespace in your lightning components by crafting your own wrapper class structure for your data attributes.
The blog post here describes how to create message or wrapper class
https://medium.com/@mohitkumarsrivastav/transitioning-from-a-visualforce-developer-to-a-lightning-developer-c23c269157bf#.jviqi965l
So in short for every component that binds directly to the UI layer via attributes you will have your class structure to completely avoid namespace issues .
A simple wrapper class will look like below
public with sharing class TaskMsg {
public TaskMsg() {
this.isCompleted = false;
this.istaskDue = false;
}
@AuraEnabled
public String name {get;set;}
@AuraEnabled
public Date dueDate {get;set;}
@AuraEnabled
public String directions {get;set;}
@AuraEnabled
public String comments {get;set;}
@AuraEnabled
public Boolean isCompleted {get;set;}
@AuraEnabled
public String status {get;set;}
@AuraEnabled
public Integer noOfDaysSinceDue {get;set;}
@AuraEnabled
public Boolean istaskDue {get;set;}
@AuraEnabled
public String taskId {get;set;}
@AuraEnabled
public String sitePrefix {get;set;}
@AuraEnabled
public String URL {get;set;}
@AuraEnabled
public String templateId {get;set;}
}
Now the question on do we need to namespace the helper.js , component.cmp and controller.js ,please note we do not need any namespace explicitly specified for it to get it working .You can simply use c as default namespace and it will work .
If you are using lighnting out then in your Javascript code that sits inside your vf you might need a namespace but you can get it dynamically inside the vf from the apex .
The answer to this is to use Salesforce DX, which will be released any day now. DX allows you to create new dev orgs that all share the same namespace as the packaging org. This makes it a lot easier to deal with the namespace, since all orgs you develop and test in will have the correct namespace.
If you don't want to move DX, your next best choice is to develop exclusively only in non-namespaced dev orgs, and use a code versioning system to deploy code from the developer orgs to the packaging org. In other words, never develop in the packaging org, and only dev orgs.
Q: What about Formulas
Write the formulas in your non-namespaced orgs, and do not use the namespace in any of your formulas. They should be properly fixed up when deploying to your packaging org when you deploy to it.
Q: Is there are any easy way of doing development in multiple dev orgs with namespace in mind?
Preferably, use DX. DX will be available any day now. If you can't or won't use DX, you can do this using normal dev orgs, but it requires some strict development practices.
For example, instead of new PageReference('/apex/mypage')
in Apex Code, you must use Page.myPage
instead. For @RemoteAction, use {!$RemoteAction.className.methodName}
instead of className.methodName
. And so on, and so forth. Use only namespace-aware functions instead of non-standard "hacks."
Q: Is it possible to achieve something similar now?
Yes, it is possible. However, you must strictly avoid using anything that will break. This means doing your research on what works and what's broken, and avoiding what's broken. For example, inline queries are generally safe without the namespace, as are most class, field, and object references, etc. It just requires more work and more diligence than it would take for a non-namespaced package.
Best Answer
Thats a current limitation of the platform .The Javascript file does not get namespace added unlike visualforce pages for managed package .
I wrote a blog post on this .
The best way would be to create a message layer or a wrapper class like your second approach and that avoids the problem .The only caveat is you end up writing bunch of classes .