what's the difference between ambientDependencies and regular dependecies in typings

Question

In the following typings.json file, what the difference between ambientDependencies(or globalDependencies) and regular dependencies:

{
  "ambientDependencies": {
    "es6-shim": "registry:dt/es6-shim#0.31.2+20160317120654",
    "jasmine": "registry:dt/jasmine#2.2.0+20160412134438",
    "jquery": "registry:dt/jquery#1.10.0+20160417213236"
  },

"dependencies": { }, <--- what does this do?

}

typings install <something> --save will save to dependencies, but what does this mean?

Answer 1

imagine you have two dependencies:

package.json

{
    "dependencies": {
        "a": "1.0",
        "b": "2.0"
    }
}

Where the dependency tree looks like:

|[email protected]
|[email protected]

In this case, there would be no difference between having both of them as globalDependencies or dependencies. However, an issue arises when they have their own dependencies. Imagine your dependency tree looks like this:

|[email protected]
|  |[email protected]
|  |[email protected]
|[email protected]

When you install [email protected] as a global dependency, it will strip references to [email protected] and [email protected], and will ask you to install those dependencies as globals. It requires you to flatten your dependency tree to:

|[email protected]
|[email protected]
|[email protected]
|[email protected]

This works fine for [email protected], but now you need two versions of b. [email protected] depends on [email protected], but your app depends on [email protected]. Which type version do you install? If you install [email protected], the type definitions for [email protected] might break. If you install [email protected], your app types might break. This is the issue globalDependencies faces.

When you build a type definition using typings and install it as a regular dependency, it wraps up the sub-dependencies without exposing them to your app. This means that if you install [email protected] as a regular dependency, it won't use the top level [email protected] definitions. It will instead use its own private [email protected] that doesn't pollute your global namespace. Effectively, regular dependencies preserve your dependency tree structure, and they are the preferred way of approaching definitions. The issue is that not all libraries have type definitions built as regular dependencies. Ideally, as people write more definitions, globals will be naturally phased out.