Packages are a way to distribute and consume functionality from different users in the ecosystem or from the Meteor Core team. The Meteor package system has been completely brought in house to Meteor. And as part of their 0.9.0 release, there's an entirely new packaging system. So in the rest of this video, I'm going to show you a couple of techniques for managing packages in your application.
I'm inside of our To Dos application directory now. And the first thing I'd like to do is to add a third party package called Iron Router for routing. So to do that, I can say Meteor Add and then type the prefix for the organization or user, and then a colon and the name of the package. So I'm going to add the iron:router package.
The new Meteor Constraint Solver and Package system will automatically pull in the required dependencies for the Iron Router project. And so now you can see that I have this Iron Router package installed. Now, notice if I look inside of the Packages folder that there's no package called Iron Router. So Meteor manages all of the package installation centrally outside of our application, and that lets it better manage versions across different packages.
If I want to see the list of packages that my app is using, I can use the Meteor List command. Now, it used to have to pass a using flag, but now you just say Meteor List and this shows a whole list of packages that are being used by your app. And you can see the Iron Router package down there at the bottom.
You can also see the versions of the packages that we're using. And if you want to see a more private view of those versions, you can see inside of the Private Meteor directory, take a look at the Versions file. And this is a list of all the packages that we're using in the app, not just the ones that are in the application namespace. And you can see the versions of each one that we're using. So this is part of how Meteor manages the dependencies across our various packages.
If I want to add a particular version of a package like Iron Router, I can see Meteor Add and then the name of the package, even if it's early installed, and then the version. So in this case, let's say I want to add Meteor Iron Router Version 100-pre 2. So I want to try out a pre-release of Iron Router. When I press Enter, it should update the Iron Router package to this particular release.
And then I can verify the version that I'm using by typing Meteor List again and seeing Iron Router down there at the bottom on the proper version. I can search for a package by using the new search command, and then type a search term like Iron. And here's all the Iron packages that show up, for example.
And if I want to look at a specific package and get more information about it, I can say Meteor Show and get data specifically on that package-- for example, all of its various versions and where it's maintained. Just like before, we can install Meteor Core packages this way as well. So for example, if I type Meteor Add Accounts UI, this will add the Core Meteor Package accounts dash UI. Now, notice this packages is not namespaced. And so for the packages that are maintained by Meteor themselves, there's no namespace like Iron or CMather.
Now, sometimes it's useful to have packages that are local to just this project for reasons that I've mentioned previously-- namely, that we want to control file load order or we just have some reusable code that we're going to use throughout our app. It's also a useful way to override core packages.
I can change into the Packages folder and create a new package that's local to the app. And I'd like to namespace them with the name of the app. I can say Meteor Create and pass that Package flag. And we're going to create an package called App-- and I'll just call this Helpers where we'll put some utilities. Maybe even we'll call it Utils.
Now, this still requires that we go into the Package.js file and fill out the Describe section. And the important part is that it has a version and the Get part is optional. Now, slightly strange behavior here is that even though we have this package defined in our local Packages folder, we need to tell Meteor about this package, that we want it to be loaded.
So you can think of this folder more as the first place that's looked up in the lookup chain for packages. But we still need to say Meteor Add, and then I'll say App Utils. And it will just look in that Packages folder first to find this package. It finds it and then adds it to our application. And now if we say Meteor List, you'll see that it's added to the list of packages that we're using down there at the bottom.
Lastly, I'm going to show you how you can add another folder into the lookup of Meteor packages. And this can be useful if you work on packages. For example, I have a folder here for all of the Iron packages. And sometimes, I just want to make those available to the application without publishing them.
Another use case for this is if you have private packages that are shared across multiple apps and they're not published to Atmosphere, but you want to use them in your applications anyway. To accomplish this, we can use an environment variable that tells Meteor about this folder. And then Meteor will use that folder when it looks up package locations.
Now, you could put this Environment variable right into your development env.sh file, but I'm going to go ahead and do it at the command line so that you can see how it works. So what I will do here is we'll change into the App directory, and I'm going to set an environment variable. We'll just export it. And it's called package DIRs.
And we're going to set that equal to some directory. In this case, I'm going to set it to Users, CMather, Source, Iron for the Iron Packages. And then we can separate all the different directory paths with a colon. And just in case this environment variable has already been set, I'm going to go ahead and include the previous value of it.
So now if I echo this out, you should be able to see that Package Directories has been set. Now if I try to add a package from that directory, Meteor will be able to find it. For example, let's say I want to add Iron layout directly to my project.
Now, it turns out that Iron Layout is already published. And so it could find it directly on the Atmosphere platform. But it's also in my Iron folder, and so it will find the package there first. In this case, it's using my local development version of Iron Layout, so I'm getting an error saying there's a conflict with Iron Router, which has installed from the published version.
But in any case, this should show you how you can use this environment variable to tell Meteor about a different package directory on your system. And in another video, I'll show you how you can use a Start script to make this all easier to manage.
In this video, we took a look at some of the new features of the Meteor Package system. Specifically, we looked at how to install third party packages like Iron Router, and then we looked at how to also install core packages that come from the Meteor team. Then we looked at how to create and add local packages to our application, and finally, how to tell Meteor about a Package folder that might exist somewhere else on our system using an environment variable called package_DIRS.