[SOLVED] Can third party packages create global variables?


#1

Today I was trying to debug this:

Exception from Tracker afterFlush function:
debug.js:41 TypeError: object is not a function
    at nb (jquery.dataTables.min.js:46)
    at mb (jquery.dataTables.min.js:29)
    at va (jquery.dataTables.min.js:44)
    at HTMLTableElement.<anonymous> (jquery.dataTables.min.js:91)
    at Function.jQuery.extend.each (jquery.js:384)
    at jQuery.fn.jQuery.each (jquery.js:136)
    at p [as dataTable] (jquery.dataTables.min.js:81)
    at h.fn.DataTable (jquery.dataTables.min.js:156)
    at null.<anonymous> (tabular.js:231)
    at view.js:191

It only happens when using meteor-admin and happens on every page. I eventually realised that if I removed this code from my lib/ folder

Option = {}

then everything is fine.

Does this mean that third party packages are creating global variables that can conflict with each other? For now, I’m putting all my constants inside my own namespace (as I should) but it would worrying for potential conflict to occur out of my control re atmosphere packages.

If this is not the case, why is it only happening in the meteor-admin pages?


#2

I have nothing to say about the meteor-admin package which i don’t know.
However, here is how global variables of packages are working.

Each package has his own scope. Actually, like for the main app, each file has his scope.
If you write Option = {} in a package, this will be defined for the whole package
If you export(‘Option’) in package.js and consume the package IN THE MAIN APP (by doing meteor add foopackage), then Option will be global for the app.
The only way (for now) to get rid of all scope/load order issues is to put ALL of your app code in packages.


#3

Thank you for the answer, however I think in this instance, it is me being especially dumb.