Version 0.6.5 of Meteor introduced major changes regarding its package system. I’m still working on a package to provide full text search and I’m using CoffeeScript as the language of choice. After updating to the new version of Meteor, I learned a few things that are worth sharing with you, in case you are in a similar situation.
Packages now have their own namespace. This reduces the chance of unintended shadowing of symbols (variable names) from the global namespace. To make package functionality accessible in an app, you need to export those symbols explicitly. You do this in the package definition file: package.js. In the Package.onUse function you do this by calling:
You might want to provide a second parameter to control the visibility on the server and the client
Client and server is the default, though, and might be omitted. A third parameter might be passed to limit the visibility to the test execution:
In your packages sources (in CoffeeScript) you have to consider the following rules:
- Plain root level symbols are file-scoped, i.e. not visible in other files of the package
- Symbols starting with @ are package globals, i.e. visible in all files of the package.
- Exported symbols are visible in all files of the package and in the application code. But must not start with a @-character.
So in case you want to have a package-global symbol and want to export it anyway you must omit the @. In case you want to have an always visible package-global variable and want to export it, only when testing, you need to do something like this:
@Length = (string) -> string.length
Length = @Length
And export Length like shown above in package.js.
And of course, don’t forget to add CoffeeScript to the build chain. Again in package.js, add:
to enable Meteor to read and interpret your package sources written in CoffeeScript.
Meteor’s internal package system is still very much in flux and more changes are to be expected. So stay tuned for further revelations.