具有传递依赖性的AMD模块

Question

Suppose I want to create an AMD module that itself depends on some other AMD module. Doesn't matter what, but to be tangible, suppose its some new kind of date-picker widget that depends on moment.js

So I setup a bower.json that looks something like this:

{
  "name": "sampleLib",
  "version": "0.0.1",
  "description": "test",
  "main": "myControl.js",
  "moduleType": [
    "amd"
  ],
  "dependencies": {
    "moment": "~2.8.1"
  }
}

OK, cool. No problem there.

My question is about how it gets consumed... I see two options, neither of which I love:

Option One

Concat my code and moment.js into a unified script, and publish that. Its easy for clients to consume since they only have to depend on my module. In this scenario:

1. Is moment.js actually a devDependency, because my clients don't have to download it?
2. If a client depends on another module that also transitively depends on moment.js, is there any way around the client basically loading the library twice?

Option Two

Don't concat my code and keep moment.js declared as a dependency in bower.json. So when a client bower install s my library, they'll also bring down moment.js. Thats cool. But the thing I worry about is namespacing... Suppose I depend on moment as 'lib/moment', but the client is structured so that it just depends on moment as 'moment'? At runtime, does my code fail because lib/moment isn't defined? I worry this is too brittle, is there a way to harden this, besides good documentation?

TL;DR

What is the most robust way to publish AMD modules with dependencies?

Answer 1

Option 1 - While concatenating is simpler for distributing your code, you hit on one of the issues with doing so - you run the risk of conflicts with other libraries. You also increase the size of your js library.

Option 2 - I don't think you're really referring to namespacing here, but rather the path of the module. Is that correct? RequireJS has a config block that you can change base paths and mappings that should solve the issue you're referring to. http://requirejs.org/docs/1.0/docs/api.html#config

So, in your case if you want to publish an AMD module and dependencies, I would still go with option 2.