{"action":"created","issue":{"url":"https://api.github.com/repos/npm/npm/issues/9057","labels_url":"https://api.github.com/repos/npm/npm/issues/9057/labels{/name}","comments_url":"https://api.github.com/repos/npm/npm/issues/9057/comments","events_url":"https://api.github.com/repos/npm/npm/issues/9057/events","html_url":"https://github.com/npm/npm/issues/9057","id":97191285,"number":9057,"title":"coDependencies: a new type of dependency field","user":{"login":"bucaran","id":8317250,"avatar_url":"https://avatars.githubusercontent.com/u/8317250?v=3","gravatar_id":"","url":"https://api.github.com/users/bucaran","html_url":"https://github.com/bucaran","followers_url":"https://api.github.com/users/bucaran/followers","following_url":"https://api.github.com/users/bucaran/following{/other_user}","gists_url":"https://api.github.com/users/bucaran/gists{/gist_id}","starred_url":"https://api.github.com/users/bucaran/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bucaran/subscriptions","organizations_url":"https://api.github.com/users/bucaran/orgs","repos_url":"https://api.github.com/users/bucaran/repos","events_url":"https://api.github.com/users/bucaran/events{/privacy}","received_events_url":"https://api.github.com/users/bucaran/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/npm/npm/labels/feature-request","name":"feature-request","color":"ACE1AF"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-07-25T04:53:08Z","updated_at":"2015-07-27T05:20:57Z","closed_at":null,"body":"I am having a bit of an issue over at [Fly](https://github.com/flyjs/fly) => flyjs/fly/issues/61\r\n\r\n#### Actors\r\n\r\n+ Host (`fly`, `gulp`, `broccoli`, etc)\r\n+ Plugins (`fly-*`, etc.)\r\n+ Guests (plugin dependencies)\r\n\r\n\r\n#### Problem\r\n\r\n+ Plugins always pull in the guest dependency (mocha, tape, eslint, jade, ...) while the end user only lists the plugin (`fly-mocha`, `fly-tape`, `fly-eslint`, ...) as a dependency. Users are forced to use the version the plugin author has decided to support.\r\n\r\n+ Adding support to multiple versions of the guest dependency is the plugin responsibility.\r\n\r\n#### Example\r\n\r\n_Mr. Node_'s organization has decided to try out Fly to compile their asset pipeline, but for whatever reason they are stuck using `mocha` `v2.0.0` in their project. Since `fly-mocha` always ships with the latest and hottest (`v2.2.5` at the time of this writing), _Mr. Node_ is stuck.\r\n\r\n#### A possible solution...\r\n\r\n`package.json` could list yet another type of dependency:\r\n\r\n+ `coDependencies` :white_check_mark: \r\n+ ~~`guestDependencies`~~\r\n+ ~~`clientDependencies`~~\r\n\r\nThis field would list all the dependencies and versions the _plugin_ supports as well as the default version (extreme example follows):\r\n\r\n```json\r\n  },\r\n  \"coDependencies\": {\r\n    \"mocha\": { \r\n      \"versions\": [\"1.0.0\", \"^1.5.0\", \"2.0.0\", \"2.2.5\"],\r\n      \"default\": \"2.2.5\"\r\n    },\r\n  },\r\n```\r\n\r\nJust like`devDependencies`, `coDependencies` are available only during development (they do not ship with the plugin when it becomes a package). The version~install strategy could make your `node_modules` look like this (other strategies are conceivable):\r\n\r\n+ `node_modules/1.0.0/mocha`  \r\n+ `node_modules/1.5.0/mocha`\r\n+ `node_modules/2.0.0/mocha`\r\n\r\nThe default version would be symlinked to `node_modules/mocha`. `npm link` could be used to switch versions or a new `npm switch` or `npm use` action could be added to make this more obvious:\r\n\r\n```\r\nnpm use mocha 1.5.0\r\n```\r\n\r\n##### Plugin Side\r\n\r\nDuring development, authors would switch between versions to test the plugin in all its incarnations. \r\n\r\nPlugins will need to be aware of the multiple version support and accommodate for version specific code / behavior. \r\n\r\nMost plugins will support the latest version of their guest library, and that will be fine. But plugins with very special version requirements (due to their guest library dysfunctional version history) would have a way to accommodate all users.\r\n\r\n##### Host Side\r\n\r\nAs usual, `npm i -D fly-mocha` would pull `fly-mocha` into my `node_modules` and add it to my `devDependency` field:\r\n\r\n```json\r\n  },\r\n  \"devDependencies\": {\r\n    \"fly-mocha\": \"0.1.0\",\r\n  },\r\n```\r\n\r\nBut `npm` which is aware of `fly-mocha`'s `coDependencies` field, would also install each of the supported dependencies and add the following to the user `package.json` (same as `fly-mocha`'s `coDependencies` above):\r\n\r\n```json\r\n  \"coDependencies\": {\r\n    \"mocha\": { \r\n      \"versions\": [\"1.0.0\", \"^1.5.0\", \"2.0.0\", \"2.2.5\"],\r\n      \"default\": \"2.2.5\"\r\n    },\r\n```\r\n\r\nThe version~install strategy would be the same as above, a directory for each version and the default version `2.2.5/mocha` would be symlinked to `node_modules/mocha`. Finally, _Mr. Node_, can use mocha `2.0.0`:\r\n\r\n```\r\nnpm use mocha 2.0.0\r\n```\r\n\r\nThis would update the default field above in his `package.json` and change the symlink inside `node_modules/mocha`.\r\n\r\n#### Vaguely Related?\r\n\r\n+ #930\r\n+ #1400"},"comment":{"url":"https://api.github.com/repos/npm/npm/issues/comments/125089239","html_url":"https://github.com/npm/npm/issues/9057#issuecomment-125089239","issue_url":"https://api.github.com/repos/npm/npm/issues/9057","id":125089239,"user":{"login":"bucaran","id":8317250,"avatar_url":"https://avatars.githubusercontent.com/u/8317250?v=3","gravatar_id":"","url":"https://api.github.com/users/bucaran","html_url":"https://github.com/bucaran","followers_url":"https://api.github.com/users/bucaran/followers","following_url":"https://api.github.com/users/bucaran/following{/other_user}","gists_url":"https://api.github.com/users/bucaran/gists{/gist_id}","starred_url":"https://api.github.com/users/bucaran/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bucaran/subscriptions","organizations_url":"https://api.github.com/users/bucaran/orgs","repos_url":"https://api.github.com/users/bucaran/repos","events_url":"https://api.github.com/users/bucaran/events{/privacy}","received_events_url":"https://api.github.com/users/bucaran/received_events","type":"User","site_admin":false},"created_at":"2015-07-27T05:20:57Z","updated_at":"2015-07-27T05:20:57Z","body":"@iarna Thanks. We are reviewing how we can use `peerDependencies` to solve our core issue. I'll refer to this again with a report of how we handled this later :hap"}}