BYO Meteor Package

Written by Pete Corey on Dec 22, 2014.

This morning I started working on a quick project called Suffixer, which is a tool to help you find interesting domain names. For this project I needed a searchable english dictionary accessible from within a Meteor app. After some sleuthing, I decided that adambom’s dictionary JSON would be my best bet. The next step was importing that JSON data into Meteor in the most “Meteor way”.

Creating a Package

Since this is a fairly reusable component, I decided to throw it into a Meteor package. Doing this is as simple and running a “create package” command inside your Meteor project:

meteor create --package pcorey:dictionary

This will create a package called pcorey:dictionary in the packages directory within your project. There you’ll find package.js and other files to get you started. Next, throw some code into the file referenced in the onUse section of package.js. Finally, add the package to your project:

meteor add pcorey:dictionary

You’ll notice that Meteor will immediately pick up this change and build your package into the project. For local packages, this is all you need to get started.

However, I wanted to keep this package in its own github repo and eventually publish it to Meteor’s package repository. With that in mind, I pulled it out of my packages folder within my project and into its own directory.

Package Assets

If you take a look at my package’s github repository, you’ll notice that I’m including dictionary.json in the package.js file:

Package.onUse(function(api) {
    api.addFiles('dictionary.json', 'server', {isAsset: true});

I’m passing an additional two arguments to this call of addFiles. The 'server' argument is straight forward; it’s telling meteor to only make this file available to the server. The {isAsset: true} argument is used to incidcate that this file should be loadable as an asset. This is a fairly undocumented feature that I only discovered after some frantic googling. Adding the file to the package in this way lets you load it as an asset in the package:

var dictionary = JSON.parse(Assets.getText('dictionary.json'));


My package defines a collection called Dictionary that I intended to be used on the client side by projects importing this package. However, without explicitly exporting Dictionary, it will remain hidden within the package’s scope.

You can specify your package’s exports in your package.js file. Here’s I’m exporting the Dictionary collection defined in dictionary.js and making it accessible to both the client and the server:

api.export('Dictionary', ['client', 'server']);

Publishing Your Package

Once you have your package completed, the next step is to publish it to Meteor’s package repository:

meteor publish --create

When making changes to you package, be sure to increment your version in package.js and then re-publish the package:

meteor publish

You can now add your package to any Meteor project using the standard meteor add command. That’s it!

Throw Back Thursday: Julia Sets with Sass

Written by Pete Corey on Dec 18, 2014.

The other day I was looking through my old GitHub repositories, and I found JuliaSass. This was my fisrt time experimenting with Sass and Haml. I had been using Less at the time, but I learned about Sass’ support of @functions and I was inspired. I decided to build a Sass script that would generate a Julia Set fractal. Haml would be used to generate a huge number of divs, and Sass would be used to calculate and set each div’s color based on the fractal’s coloring algorithm.

The resulting CSS file was over 50000 lines long and took over 1 minute to generate on my machine. Needless to say, this is a horrible idea, but I thought it was a cool expiriment.

Check it out!

Aspect Ratio Media Queries

Written by Pete Corey on Dec 16, 2014.

The other day I was playing with a fullscreen CSS layout using viewport units. I had content that was a fixed aspect-ratio, and I wanted it to fill as much of the screen as possible without overflowing. At first, I was setting the element’s width to 100vw, but of course, if the aspect ratio of the window was greater than the aspect ratio of the content, the content would overflow off the screen. In those cases, I wanted to bind the height of the content to 100vh, instead of binding the width to 100vw.

My first naive attempt to do this was to use Sassmax function to compare 100vh with 100vw:

$size = max(100vh, 100vw);

In hindsight, this is obviously not going to work. The result of this expression is going to change as the viewport aspect ratio changes. Fundamentally, this is something Sass can’t deal with. Sass kindly explained that to me:

Error: Incompatible units: ‘vh’ and ‘vw’.

After some googling, I came across aspect-ratio media queries. This is exactly what I needed! To build my layout, I use an aspect-ratio media query to alternate between binding against vh and vw based on whether the screen is in a horizontal aspect ratio, or a vertical one.

I whipped up a quick codepen to show this off. Resize the viewport to see it in action:

See the Pen aspect-ratio media queries by Pete Corey (@pcorey) on CodePen.