Working with packages in Meteor : Basics

Introduction

Meteor is Full stack solution to build real-time apps. It is reactive in nature and amazing technology to work with as it provides all the tools that are required to build amazing real-time apps with developer focus on implementing the business stuff and not the technology plumbing.

Early days of Meteor, it does not have the packaging system and tool to support it by its own  but it was provided by community built tool called Meteorite. From Meteor 0.9.0, it has official solution for the packaging which is in-built into Meteor CLI tool.

For starters, Meteor package is piece of code that extends functionality of Meteor. Just like npm modules in Node.js, or Gems in Ruby.

Meteor is isomorphic in nature, meaning that it combines code on client side and server side and you can single code on server and client also.

So, due to this, Meteor packages work differently than the other packages exists in other frameworks. Thus packaging system is different all togther from rest of frameworks.

In typical Meteor package, either of two things or both might exist. Such as, there is server component which works only in server side and also contains the client component which works on client side. Meteor package manager is better integrated to support isomorphism nature .

Before proceeding futher, it is assumed that you have installed the Meteor on your machine. If not refer to previous blog post for instructions. and you need to have the meteor project created. To which you can run the commands from this article.

Atmosphere Packages Repository

Atmosphere is an offical repository which hosts the Meteor packages. In this you can search for packages, look for trending packages etc. Meteor community is filled with awesome developers, as of writing this article, it has above 9k packages hosted and still counting.

In this site, you can get the packages for every aspect like email, front end framework etc, but as Meteor is reactive in nature, some packages are built based on reactivity in mind, such as client routers, iron-router, flow-router etc

It is integrated with Meteor CLI tool which does adds the packages from here or searches any packges from here.

Any Meteor developer can create and push the Meteor packeges to this site and it is available for anyone to use it.

Adding / Removing packages

Basic commands like adding, removing packages is obivous from commands such as add and remove sub commands to meteor CLI tool.

meteor add <package-name>

meteor remove <package-name>

For e.g. for adding and removing Twitter bootstrap package, we can use following command-

metoer add twbs:bootstrap

meteor remove twbs:bootstrap

Futher, you can add and remove multiple packages in a one line, package names should be separated by space

For e.g.

meteor add twbs:bootstrap ian:accounts-ui-bootstrap-3

meteor remove insecure autopublish

This command is used to add the packages from Atomphere repo, where community packages are published.

Adding/removing packages with versions constraints

Previously, we saw adding packages without versioning, which basically adds latest version available of package.
Adding packages with version is easy, just add the name of package followed by @ symbol followed by version of package.

Like, [package-name]@[version-name]

For e.g.
meteor add twbs:bootstrap@3.3.1

Now, adding version comes different syntaxes-

  • Default version which as above , adds version which is same as major version with same or higher any minor or patch version
    For e.g. `meteor add twbs:bootstrap@3.3.1` will add version 3.3.1 or higher like 3.3.2 or 3.3.5 but not 4.0.2 , it is change in major version
  • If wanted to add exact version, you can add `=` equals to sign after `@`.
    For e.g. `meteor add twbs:bootstrap@=3.3.5` adds exact same version as 3.3.5

About package naming and versioning

In Meteor, packages are named with special naming convention, in which it precedes package name with its author name, which is as follows-

<author_name>:<package name >

It provides to namespace the package, so that two authors can have same package but they are just namespaced with author name.

This is done for two reasons, one is to give credit to author (as community is full of awesome people) and second is to avoid naming conflict and by giving the namespacing for packages, if someone wants to create package with name which already is already taken, it can be avoided with this naming strategy.

In Atmosphere repo, you can see that, multiple packages of bootstrap exists, here is link, but due to author name prefixed, it made bootstrap to be used for multiple packages.

There is one exception to this rule, in which packages are not preceded by author name like coffeescript, underscore, etc. These are core packages which are maintained by Meteor core team (MDG)

Meteor packages are versioned according to Semantic versioning system. Where, there are 3 numbers, which are separated by dots. Such as-

major.minor.patch

Where,

  • `major` is major release , can be non-backward as its big change to system,
  • `minor` is the minor feature release, with backward compatibility
  • `patch` is bug fixes release

For e.g.  1.4.0 or 2.3.5

The packages file

As you add the packages from command line, it get added to special file exists under .meteor/ directory inside project root directoy

Its location is –

<project-root-dir>/.meteor/packages

This file contains the listing of packages, one per line along with comments explaning the what each core packages signifies.

The core packages (which are added to every  project while creating it) and packages which are added from the meteor command line tool.

Following are actual content of file as of Meteor 1.2.1. (For higher version, contents may vary, as some core packages may get added/removed )

$ cat .meteor/packages
# Meteor packages used by this project, one per line.
# Check this file (and the other files in this directory) into your repository.
#
# 'meteor add' and 'meteor remove' will edit this file for you,
# but you can also edit it by hand.

meteor-base # Packages every Meteor app needs to have
mobile-experience # Packages for a great mobile UX
mongo # The database Meteor supports right now
blaze-html-templates # Compile .html files into Meteor Blaze views
session # Client-side reactive dictionary for your app
jquery # Helpful client-side library
tracker # Meteor's client-side reactive programming library

standard-minifiers # JS/CSS minifiers run for production mode
es5-shim # ECMAScript 5 compatibility for older browsers.
ecmascript # Enable ECMAScript2015+ syntax in app code

twbs:bootstrap

Conclusion

This article covers the basics in using Meteor packaging system, such as adding/removing, with or without version. We also had looked at how packages are named and versioning strategy used and finally, packages file which stores packages which are added to project.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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