Working With Packages in Meteor: the Basics
Working With Packages in Meteor: the Basics
Abhijeet Sutar provides a summary of Meteor and how to use it's packaging system—with and without version control.
Join the DZone community and get the full member experience.Join For Free
Meteor is a full-stack solution to build real-time apps. It is reactive in nature and an amazing technology to work with as it provides all of the tools that are required to build amazing real-time apps with a developer focus on implementing the business stuff and not the technological plumbing.
In the early days of Meteor, it did not have the packaging system and tool to support it on its own but it was provided by a community-built tool called Meteorite. Since Meteor 0.9.0, it has an official solution for the packaging that is in-built into the Meteor CLI tool.
For starters, the Meteor package is a piece of code that extends the 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 the 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 that exist in other frameworks. Thus, the packaging system is different altogether from the rest of the frameworks.
In the typical Meteor package, either of two things or both might exist. Such as, there is a server component which works only on the server side and also contains the client component which works on the client side. Meteor package manager is better integrated to support isomorphism nature.
Before proceeding further, it is assumed that you have installed Meteor on your machine. If not, refer to the previous blog post for instructions. Plus, you need to have the meteor project created for which you can run the commands from this article.
Atmosphere Packages Repository
Atmosphere is an official repository which hosts the Meteor packages. In it, you can search for packages, look for trending packages etc. The Meteor community is filled with awesome developers—as of writing this article, it has above 9k packages hosted and still counting.
On 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 adds the packages from here or searches any packages from here.
Any Meteor developer can create and push the Meteor packages to this site and they are available for anyone to use.
Basic commands like adding and removing packages are obvious from commands such as
remove sub commands to
meteor CLI tool.
meteor add <package-name> meteor remove <package-name>
For example, in order to add and remove the Twitter bootstrap package, we can use the following command:
metoer add twbs:bootstrap meteor remove twbs:bootstrap
Further, you can add and remove multiple packages in one line (package names should be separated by spaces.)
meteor add twbs:bootstrap ian:accounts-ui-bootstrap-3 meteor remove insecure autopublish
This command is used to add the packages from the Atmosphere repo, where community packages are published.
Adding/Removing Packages With Versions Constraints
Previously, we saw how to add packages without versioning, which basically adds the latest available version of the package.
Adding packages with version is easy, just add the name of the package followed by the "@" symbol and then the version of the package.
meteor add twbs:email@example.com
Now, adding version comes different syntaxes:
- Default version which as above, adds version which is the same as the major version with the same or higher, any minor or patch version
For example: `meteor add twbs:firstname.lastname@example.org` will add version 3.3.1 or higher like 3.3.2 or 3.3.5, but not 4.0.2 , it is changed in the major version
- If you wanted to add an exact version, you can add `=` equals after `@`.
For example: `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 a special naming convention, in which it precedes the package name with its author name, which is as follows:
<author_name>:<package name >
It provides to the namespace the package, so that two authors can have the same package but they are just namespaced with the author name.
This is done for two reasons—one is to give credit to the author (as the community is full of awesome people) and second is to avoid a naming conflict. And, by giving the namespacing for packages, if someone wants to create a package with a name that is already taken, it is avoided with this naming strategy.
In Atmosphere repo, you can see that multiple packages of
bootstrap exists (here is a link) but, due to the author name prefixed, it caused bootstrap to be used for multiple packages.
There is one exception to this rule, in which packages are not preceded by author names like
underscore, etc. These are core packages which are maintained by the Meteor core team (MDG).
Meteor packages are versioned according to the Semantic versioning system—where there are 3 numbers which are separated by dots. Such as:
- `major` is major release , can be non-backward as it's a big change to the system
- `minor` is the minor feature release, with backward compatibility
- `patch` is the bug fixes release
For example: 1.4.0 or 2.3.5
The packages File
As you add the packages from the command line, it gets added to a special file that exists under .meteor/ directory inside the project root directory.
Its location is:
This file contains the listing of packages, one per line, along with comments explaining what each core packages signifies—the core packages (which are added to every project during creation) and packages which are added from the meteor command line tool.
Following are actual contents of the file as of Meteor 1.2.1. (For higher versions, contents may vary as some core packages may be 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
This article covers the basics in using the Meteor packaging system, such as adding/removing, with or without version. We also have looked at how packages are named and the versioning strategy used. And finally, the packages file which stores packages which are added to the project.
Published at DZone with permission of Abhijeet Sutar , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.