When I’m creating a package, I find it to be a pain to export every variable I want to expose. However, I’ve noticed that if assign the variable to this, then you dont need to export it.
Is this a valid way of doing things?
Short Answer: No
Long Answer:
Moving forwards the whole meteor community is moving towards an ES6/7 style scheme with modules and proper classes. Littering the global scope is just going to become more and more problematic.
If this is a collected set of utilities or something you could probably create an Object assign all your stuff as members of that object and then just export that one object.
Like PackageName.Feature.method();
2 Likes
No.
If you have a look at the generated package code. For example the random package:
(function () {
/* Imports */
var Meteor = Package.meteor.Meteor;
var _ = Package.underscore._;
/* Package-scope variables */
var Random;
// Package code...
/* Exports */
if (typeof Package === 'undefined') Package = {};
Package.random = {
Random: Random
};
})();
You see that package exports are exported to the Package.random namespace, not the global namespace. When you assign something to this in the global package context, you assign it to window (the global context in the browser).
Are you suggesting this changes in production environments?
Most packages export correctly to the client or server though 
1 Like
Yeah, thats a valid option. But i feel like it makes my code really messy having MyApp.utils.shallowClone(x) rather than shallowClone(x). I could use destructuring assignment, to get the values I want. idk, its just more overhead and leave the codebase less clean.
Well, it works by simply assigning variables to this