{
  "_args": [
    [
      {
        "raw": "@glimmer/di@^0.2.0",
        "scope": "@glimmer",
        "escapedName": "@glimmer%2fdi",
        "name": "@glimmer/di",
        "rawSpec": "^0.2.0",
        "spec": ">=0.2.0 <0.3.0",
        "type": "range"
      },
      "/home/travis/build/lukesargeant/ember-sparkline/node_modules/@glimmer/resolver"
    ]
  ],
  "_from": "@glimmer/di@>=0.2.0 <0.3.0",
  "_id": "@glimmer/di@0.2.0",
  "_inCache": true,
  "_location": "/@glimmer/di",
  "_nodeVersion": "6.9.1",
  "_npmOperationalInternal": {
    "host": "packages-18-east.internal.npmjs.com",
    "tmp": "tmp/di-0.2.0.tgz_1489925396182_0.16966746700927615"
  },
  "_npmUser": {
    "name": "dgeb",
    "email": "dan@cerebris.com"
  },
  "_npmVersion": "3.10.8",
  "_phantomChildren": {},
  "_requested": {
    "raw": "@glimmer/di@^0.2.0",
    "scope": "@glimmer",
    "escapedName": "@glimmer%2fdi",
    "name": "@glimmer/di",
    "rawSpec": "^0.2.0",
    "spec": ">=0.2.0 <0.3.0",
    "type": "range"
  },
  "_requiredBy": [
    "/@glimmer/resolver"
  ],
  "_resolved": "https://registry.npmjs.org/@glimmer/di/-/di-0.2.0.tgz",
  "_shasum": "73bfd4a6ee4148a80bf092e8a5d29bcac9d4ce7e",
  "_shrinkwrap": null,
  "_spec": "@glimmer/di@^0.2.0",
  "_where": "/home/travis/build/lukesargeant/ember-sparkline/node_modules/@glimmer/resolver",
  "bugs": {
    "url": "https://github.com/glimmerjs/glimmer-di/issues"
  },
  "contributors": [
    {
      "name": "Dan Gebhardt",
      "email": "dan@cerebris.com"
    },
    {
      "name": "Tom Dale",
      "email": "tom@tomdale.net"
    }
  ],
  "dependencies": {},
  "description": "Dependency injection support for Glimmer applications.",
  "devDependencies": {
    "@glimmer/build": "^0.6.0",
    "broccoli": "^1.1.0",
    "broccoli-cli": "^1.0.0",
    "testem": "^1.13.0"
  },
  "directories": {},
  "dist": {
    "shasum": "73bfd4a6ee4148a80bf092e8a5d29bcac9d4ce7e",
    "tarball": "https://registry.npmjs.org/@glimmer/di/-/di-0.2.0.tgz"
  },
  "gitHead": "611a788ba6aeac9293fe8f11268c5db58ad7f8da",
  "homepage": "https://github.com/glimmerjs/glimmer-di#readme",
  "license": "MIT",
  "main": "dist/commonjs/es5/index.js",
  "maintainers": [
    {
      "name": "chadhietala",
      "email": "chadhietala@gmail.com"
    },
    {
      "name": "chancancode",
      "email": "godfreykfc@gmail.com"
    },
    {
      "name": "dgeb",
      "email": "dan@cerebris.com"
    },
    {
      "name": "krisselden",
      "email": "kris.selden@gmail.com"
    },
    {
      "name": "locks",
      "email": "rokusu@gmail.com"
    },
    {
      "name": "mmun",
      "email": "im.mmun@gmail.com"
    },
    {
      "name": "rwjblue",
      "email": "me@rwjblue.com"
    },
    {
      "name": "stefanpenner",
      "email": "stefan.penner@gmail.com"
    },
    {
      "name": "tomdale",
      "email": "tom@tomdale.net"
    },
    {
      "name": "wycats",
      "email": "wycats@gmail.com"
    }
  ],
  "module": "dist/modules/es2017/index.js",
  "name": "@glimmer/di",
  "optionalDependencies": {},
  "readme": "# glimmer-di [![Build Status](https://secure.travis-ci.org/glimmerjs/glimmer-di.svg?branch=master)](http://travis-ci.org/glimmerjs/glimmer-di)\n\nDependency injection for Glimmer applications.\n\n## What is Dependency Injection?\n\nDependency injection is a pattern that increases the flexibility, testability\nand consistency of your code.\n\nThe three key ideas are:\n\n1. An object's dependencies (that is, the other objects it needs to do its job)\n   should be provided to the object when it is created, rather than hard-coded.\n2. A dependency may have multiple implementations, so long as each\n   implementation adheres to an agreed-upon interface.\n3. An object using a dependency shouldn't care where on the filesystem that\n   dependency comes from.\n\nLet's look at a short example that **does not** use dependency injection. We'll\nwrite a hypothetical server that renders a short HTML document when an incoming\nrequest is received:\n\n```js\nimport HTTPServer from \"./servers/http\";\n\nexport default class HelloWorldServer {\n  constructor() {\n    let server = new HTTPServer({\n      port: 80\n    });\n\n    server.on('request', req => {\n      req.write(\"<html><body>Hello, world!</body></html>\");\n    });\n  }\n}\n```\n\nThis is great, but there's one problem. As you can see, our Hello World server\nis importing the HTTP library directly. If we want to support both HTTP and\nHTTP/2 (or even something like a WebSocket), this code is not reusable.\n\nWe would have to either duplicate this code, or add some configuration options\nto let the user tell us which protocol they want to use. Of course, that would\nwork today, but if we wanted to support HTTP/3 in the future, we'd have to come\nback and add a new configuration option for every new protocol.\n\nWhat if, instead of telling the server what protocol to use, we could instead\nprovide it with an object that encapsulated all of those concerns?\n\nInstead of having our `HelloWorldServer` import and instantiate `HTTPServer`\ndirectly, we can provide it with an object that we guarantee implements the same\ninterface. In this case, that means any object that emits a `'request'` event\nand supports adding an event listener with the `on()` method.\n\nLet's look at what that updated example might look like:\n\n```js\nexport default class HelloWorldServer {\n  constructor(server) {\n    server.on('request', req => {\n      req.write(\"<html><body>Hello, world!</body></html>\");\n    });\n  }\n}\n```\n\nNow we're no longer concerned with instantiating and configuring an HTTP server.\nAll we have to know is that whatever object gets passed to our class has an\n`on()` method that lets us add an event listener.\n\nNow, let's look at a few different ways we can use our newly improved Hello\nWorld server.\n\n```js\nimport HelloWorldServer from \"./hello-world-server\";\nimport HTTPServer from \"./servers/http\";\nimport HTTP2Server from \"./servers/http2\";\nimport WebSocketServer from \"./servers/web-socket\";\n\n// HTTP 1\nlet httpServer = new HTTPServer({\n  port: 80\n});\nnew HelloWorldServer(httpServer);\n\n// HTTP 2\nlet http2Server = new HTTP2Server({\n  port: 4200\n});\nnew HelloWorldServer(http2Server);\n\n// WebSocket\nlet wsServer = new WebSocketServer();\nnew HelloWorldServer(wsServer);\n```\n\nWith that one small change, we've dramatically improved the reusability and\nflexibility of our Hello World server. It can now handle any protocol, even ones\nthat didn't exist when it was written, so long as they can be adapted to follow\nthe simple interface we've defined.\n\nThis idea may seem simple, but it has profound implications for managing the\ncomplexity of your code as your application grows. And it means that you can\nswap in different pieces of code easily depending on the environment.\n\nFor example, in unit tests we may want to swap in some stub objects to verify\nsome behavior. Dependency injection makes it easy and avoids having to override\nglobal values.\n\nWe can also make it possible to run the same application on both Node.js and the\nbrowser, by swapping in one piece of framework code when you have a full DOM\nimplementation and another implementation when you don't.\n\nWhile dependency injection is just a simple pattern, it helps to have that\npattern formalized into code. That's exactly what this library does: implement\nan incredibly lightweight version of dependency injection, with some utilities\nto help us clean up after ourselves when we're done running the app.\n\n## Containers and Registries\n\nThe two core parts of the Glimmer DI system are the `Registry` and the `Container`.\n\nHere's how to remember the role of each:\n\n1. The `Registry` is where you **register** code (that is, JavaScript classes).\n2. The `Container` **contains** objects, and is where you request instances of\n   registered classes.\n\nIf that sounds confusing, let's look at an example that should make it\nclearer.\n\nLet's say I have a class for a UI component that I want to make available to the\nsystem. The first thing I would do is create a new `Registry` instance and tell\nit about my class.\n\n```js\nimport { Registry } from '@glimmer/di';\nimport ProfileComponent from './components/profile';\n\nlet registry = new Registry();\nregistry.register('component:profile', ProfileComponent);\n```\n\nYou probably noticed the string that we're passing to the `register` method:\n`'component:profile'`. This is what we call a _specifier_, which is a unique\nidentifier for a class. They take the form of `${type}:${name}`. In this case,\nwe have a UI component called `Profile` so its specifier would be\n`'component:profile'`. If instead we had an blog post model, its specifier might\nbe `'model:blog-post'`.\n\nSo now we've told the `Registry` about our component. Let's get an instance of\nthat component now. To do that, we'll need to create a new `Container`, tell it\nabout our registry, and then ask it for the component we want:\n\n```js\nimport { Container } from '@glimmer/di';\n\n// Create the container and pass in the registry we previously created.\nlet container = new Container(registry);\nlet component = container.lookup('component:profile');\n```\n\nNow our `component` variable contains an instance of the previously-registered\nprofile component.\n\n### Singletons\n\nOne important thing to note is that (by default) every time you call the\n`lookup` method, you'll get the same instance of the component:\n\n```js\nlet component1 = container.lookup('component:profile');\nlet component2 = container.lookup('component:profile');\n\ncomponent1 === component2; // => true\n```\n\nBut that's not the behavior we want: in an app, you need to be able to create\nmany instances of the same component.\n\nIn this case, we want to change the default behavior and tell the registry that\nwe should always get a _new_ instance when we call\n`lookup('component:profile')`:\n\n```js\nregistry.registerOption('component:profile', 'singleton', false);\n```\n\nHere, we've set the `singleton` option to `false` for this component. We could\nhave also configured this setting back when we originally registered the component:\n\n```js\nregistry.register('component:profile', ProfileComponent, {\n  singleton: false\n});\n```\n\nNow if we lookup multiple components, we'll get a different instance each time:\n\n```js\nlet component3 = container.lookup('component:profile');\nlet component4 = container.lookup('component:profile');\n\ncomponent3 === component4; // => false\n```\n\n### Injections\n\nSo far, this doesn't seem to offer any benefits over just instantiating the\nclass ourselves whenever we need a new instance. Let's look at one of the killer\nfeatures: injections.\n\nAn _injection_ is a rule that tells the container to automatically give one object\naccess to another.\n\nFor example, let's imagine we have a centralized data store that we want to make\navailable to all of our components, so they can retrieve model data over the\nnetwork. Without worrying about how components get created in our framework, we\njust want to say: \"every time a new component is instantiated, make sure it has\naccess to the data store.\"\n\nWe can set this up automatically with an injection. First, let's register the\ndata store with the registry:\n\n```js\nimport DataStore from \"./data/store\";\n\nregistry.register('store:main', DataStore);\n```\n\nBecause we want components to share a single store instance, note that we didn't\ndisable the default `singleton` setting. For the whole app, there will be just\none store.\n\n(If there's only one instance of a particular type in an app, we often call it\n`main`. In this case, because there's one store and it's a singleton, its\nspecifier is `store:main`. There's nothing special about this name, though; it's\njust a common convention.)\n\nNext, we'll create a rule that tells the registry that new components should be\nprovided with the data store instance:\n\n```js\nregistry.registerInjection('component', 'store', 'store:main');\n```\n\nLet's look at each of these arguments to `registerInjection`. Each one helps define part\nof the injection rule. In this case, it means:\n\n1. For every new `component` created,\n2. Set its `store` property to\n3. The instance of `store:main`\n\nIn other words, every time `container.lookup('component:profile')` gets called,\nsomething like this is happening under the hood:\n\n```js\nlet store = container.lookup('store:main');\nreturn ProfileComponent.create({ store });\n```\n\nThe nice thing about injections is that we can set up a rule once and not worry\nabout the details of where and how instances actually get created. This\nseparation of concerns allows for less brittle code.\n\nYou've also now seen why specifiers contain information about both name and\ntype. Injections let us specify rules that apply to all instances of a\ncomponent, say, without having to repeat that rule for every component in the\nsystem.\n\n## Resolvers: Mapping to the File System\n\nSo far, we've always had to tell the `Registry` about a class before we're able\nto get an instance from the `Container`. But if we're being good developers, and\norganizing our code well and being consistent in our naming, shouldn't our app\nbe able to find our classes automatically?\n\nThat's exactly what the `Resolver` helps us do. With a resolver, we can define\nrules that map specifiers (like `component:profile`) on to module names (like\n`app/components/profile.js`).\n\nA simple `Resolver` implements a single method, `retrieve()`, which takes a\nspecifier and returns the associated class.\n\nLets write a resolver that will load the component class using CommonJS instead of\nhaving to eagerly register every component in our app:\n\n```js\nclass Resolver {\n  retrieve(specifier) {\n    let [type, name] = specifier.split(':');\n\n    if (type !== 'component') { throw new Error(\"Unsupported type\"); }\n    return require(`./app/${type}s/${name}.js`);\n  }\n}\n\nlet registry = new Registry();\nlet resolver = new Resolver();\nlet container2 = new Container(registry, resolver);\n\n// Make sure components aren't singletons\nregistry.registerOption('component', 'singleton', false);\n\n// Requires and instantiates `./app/components/admin-page.js`:\nlet adminPage = container2.lookup('component:admin-page');\n```\n\nNote that `retrieve()` *must* return synchronously. Your module loader therefore\nmust return synchronously, as it does in this CommonJS example. If you're using an\nasynchronous module loader, you'll need to make sure modules are loaded before you\nstart instantiating objects.\n\nAs a general rule, this package is designed to be synchronous to achieve maximum\nperformance; it is your responsibility to ensure that code is ready before it is\nneeded.\n\nOne last thing: you may have noticed that the container in this example has both\na registry and a resolver. The container will look for classes in both, but the\nregistry always takes precedence. If the registry is empty, the container will\nfall back to asking the resolver for its help.\n\n## Acknowledgements\n\nThanks to [Monegraph](http://monegraph.com) and\n[Cerebris](http://www.cerebris.com) for funding the initial development of this\nlibrary.\n\n## License\n\nMIT License.\n",
  "readmeFilename": "README.md",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/glimmerjs/glimmer-di.git"
  },
  "scripts": {
    "build": "rm -rf dist && BROCCOLI_ENV=dist broccoli build dist",
    "build:tests": "rm -rf tests && BROCCOLI_ENV=tests broccoli build tests",
    "preversion": "rm -rf dist && BROCCOLI_ENV=dist broccoli build dist",
    "test": "testem ci"
  },
  "types": "dist/types/index.d.ts",
  "version": "0.2.0"
}