I agree it's not optimal, but the workaround I'm using seems clean enough:
- I create a JS object in a file named lib/00_namespace.js . In there I declare a global object for the app I'm building. For "Example App" it could be "EA" or something.
I add global helpers to this dict - and I actually declare the object keys i'm gonna be using to have the "namespace" contents explicitly declared and documented there as well.
EG:
/**
* Example App Master Namespace
*/
EA = {
// popup helper (added later in code)
popup: undefined
// global helper functions
helpers: undefined
}
---
etc.
Also I actually, because I'm lazy, I put Classes/Types I am using throughout the project in the global namespace with the same prefix, although lowercased, and I put my collections in the global namespace via Coffeescript as well, because they're just too damn useful. I should probably namespace/prefix them as well, I know, but I don't yet - at least not in my current project, maybe in the future.
EG. I do
In notificationMessage.class.litcoffee I do:
class @NotificationMessage
constructor: (doc) ->
_.extend @, doc
In notificationMessages.litcoffee I do:
@NotificationMessages = new Meteor.Collection "notification_messages",
transform: (doc) ->
return new NotificationMessage doc
So I have both NotificationMessage and NotificationMessages available in the global namespaces / objects on both the client and the server.
Note that you can use both NotificationMessage and NotificationMessages without the "@" - prefix as soon as they are available in the "global" context, and that's what I do, even in the same file after defining them.
It's not super-Clean, but I guess if you'd use eaNotificationMessage and eaNotificationMessages instead you could say it's good enough :)
Pro-Tipp I figured out some time ago: Put as much helpers as you can on model objects as shown above, that way you can avoid writing a lot of template helpers while keeping the code clean too. Also IronRouter - Controller - Helpers, but Model Objects can get you far indeed.
There were some more ideas on this in the context of package-only-development, which I moved away from because it was quite a lot to juggle and which would tend to break a lot / was slow for me, and which I can't find anymore right now anyways. Best thing to keep in mind is creating a global object in JS and then grouping everything in there yourself.
Best wishes
Daniel