Meteor App Packages in CoffeeScript

To include the Npm module “tedious” (to access a MSSQL database) I created my first Meteor package, just yesterday. See this post. A private package defined in the “packages” folder of the app. That was actually easier than expected. So I decided to put future functionality, that seems packageable, in such packages.

I prefer CoffeeScript over JavaScript so I wondered, if I can write the package code in CoffeeScript. Well that was a must-have requirement. If I couldn’t get this working anyhow, I would have abandoned the idea of packages, yet again, I think. At the moment of this writing, the Meteor package API is still not documented. So I had to experiment a bit. After looking in the relevant sources of Meteor (packages.js under tools), I made at first a rather complicated solution.

I decided to look at the source code of some standard packages and found out, that you can use other packages in your package definition. I tried the following:

And it worked like a breeze. I just have to add all “.coffee” files I have in the package and can access globally defined variables form my normal app code. As you might see from the sources I plan to build a very basic fulltext search (n-gram) for my app. I haven’t found anything simple that integrates well with Meteor. Maybe you can point something out.

In case you wonder why I didn’t use Meteorite. Well, I don’t know exactly. I simply didn’t want to go the Meteorite way. I find it questionable that there exists yet another mechanism for the same purpose, and since the Meteor native package system is included and works quite well (for the built in packages), I decided to stick with it and ignore Meteorite and those Atmosphere “Smart Packages”.

I don’t know if this is a wise choice. Time will tell.

Update: Meteor 0.6.5 introduced major changes to it’s package system, consider this updated information.


2 thoughts on “Meteor App Packages in CoffeeScript

    1. Dirk Porsche says:

      Well, I have encountered other circumstances, where I’m basically doing this (enhancing a Third-Party-WebApp hosted on IIS). I have no other choice there, (well at least I think, it’s a foreign culture for me). But trust me, keeping everything in sync isn’t that easy, especially when you have to change things month after you developed the code initially.

      Having only one place and the ease of Meteor’s CoffeeScript integration and it’s change/restart cycle while developing is worth those few steps and things to remember.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s