Quick Tip: AMD Packages

Blog Post created by odoe on Feb 17, 2016



Maybe you're new to the ArcGIS API for JavaScript or maybe you're even a seasoned user, but at some point I'm sure you've dug deep into AMD and modular JavaScript.


I've written a few posts about this before, one being Embrace your AMD modules, as well as a post on custom builds. I even recorded a video about using the Bower release of the ArcGIS JS API.


One question seems to pop up quite a bit and that is a question about packages.


What are they and why do they matter?


Don't worry, packages are a concept that confused me at one point as well. Packages can be thought of as namespaces, similar to what you might see in Java or another language.


Let's break down a couple of some statements, using default ES5 syntax.


define(["esri/map"], function(map) {});


What we are doing here is requesting the map module from the esri package. The entire ArcGIS API for JavaScript s inside the esri package. There are other dependencies from other packages like dojo or dojox.


Typically, you don't need to concern yourself too much with packages if you are building a simple application. If you're using the CDN of the API, you are probably familiar with this little hack to use your local code.


Using packages


That's all fine and dandy, but if you are using the Bower release of the API and you want to do custom local builds, this is when packages matter. Because you need to let the Dojo build system know what packages it should be aware of. The easiest way to do this is to add the esri and it's dependency packages under a source folder. Your application code should go into an app folder.


This means you would end up with an application structure similar to this.


  ├── app
  ├── dgrid
  ├── dijit
  ├── dojo
  ├── dojox
  ├── dstore
  ├── xstyle
  ├── put-selector
  ├── esri


You can read this guide to find out how to have Bower install to your source directory. Now you can tell the Dojo build system what packages it should be aware of in your build profile.

  packages: [
    // 'app' is a sample path for your application
    // set this accordingly


You can see a sample build profile here. If you add more libraries, like Bootstrap and jQuery, you can just add them to them to the packages list.


So at the end of the day, packages are nothing more than a way to keep your code organized.


Now that's not the end of the story for packages. There are more details you can learn about to let the Dojo build system know that a folder is a package and that it is an AMD package. There's even stuff you can do to ignore any tests directories that may reside inside your package folder.


I'll cover those details next time!


For more geodev tips and tricks, check out my blog.