{"action":"created","issue":{"url":"https://api.github.com/repos/americanpanorama/panorama/issues/12","repository_url":"https://api.github.com/repos/americanpanorama/panorama","labels_url":"https://api.github.com/repos/americanpanorama/panorama/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/americanpanorama/panorama/issues/12/comments","events_url":"https://api.github.com/repos/americanpanorama/panorama/issues/12/events","html_url":"https://github.com/americanpanorama/panorama/issues/12","id":123533357,"number":12,"title":"Let's talk about dependencies...","user":{"login":"mojodna","id":45,"avatar_url":"https://avatars.githubusercontent.com/u/45?v=3","gravatar_id":"","url":"https://api.github.com/users/mojodna","html_url":"https://github.com/mojodna","followers_url":"https://api.github.com/users/mojodna/followers","following_url":"https://api.github.com/users/mojodna/following{/other_user}","gists_url":"https://api.github.com/users/mojodna/gists{/gist_id}","starred_url":"https://api.github.com/users/mojodna/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mojodna/subscriptions","organizations_url":"https://api.github.com/users/mojodna/orgs","repos_url":"https://api.github.com/users/mojodna/repos","events_url":"https://api.github.com/users/mojodna/events{/privacy}","received_events_url":"https://api.github.com/users/mojodna/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-12-22T18:34:15Z","updated_at":"2016-03-24T18:33:02Z","closed_at":null,"body":"`peerDependencies` don't make sense because npm 3 doesn't install them, introducing an extra step before being able to work on this module. Conceptually, they're right for the non-bundled, `webpack`-ed build.\r\n\r\n`dependencies` seems like the most appropriate way of defining them (they install when developing on this and are included for npm-style resolution), but it adds to the footprint when only the bundled assets are used.\r\n\r\n`devDependencies` would install necessary runtime libraries and facilitate bundling (and keep the footprint small), but it would preclude npm-style module resolution (because nested modules would be unavailable).\r\n\r\n#10's approach (facilitating npm-style resolution, which we're not currently doing) seems like the most appropriate mechanism for _our_ use-cases, but we're also trying to hit these:\r\n\r\n1. bundled assets, suitable for inclusion via `<script>`, with external (to avoid potential duplication) references to compatible dependencies (e.g. Leaflet, d3, ...)\r\n2. bundled kitchen sink, suitable for inclusion via a single `<script>` tag (including all dependencies).\r\n\r\nWe're currently using (1), but incorporating it into a separate build system and potentially introducing confusion around how to incorporate upstream dependencies (e.g. react-leaflet).\r\n\r\nThoughts?"},"comment":{"url":"https://api.github.com/repos/americanpanorama/panorama/issues/comments/200962060","html_url":"https://github.com/americanpanorama/panorama/issues/12#issuecomment-200962060","issue_url":"https://api.github.com/repos/americanpanorama/panorama/issues/12","id":200962060,"user":{"login":"ericsoco","id":1127259,"avatar_url":"https://avatars.githubusercontent.com/u/1127259?v=3","gravatar_id":"","url":"https://api.github.com/users/ericsoco","html_url":"https://github.com/ericsoco","followers_url":"https://api.github.com/users/ericsoco/followers","following_url":"https://api.github.com/users/ericsoco/following{/other_user}","gists_url":"https://api.github.com/users/ericsoco/gists{/gist_id}","starred_url":"https://api.github.com/users/ericsoco/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ericsoco/subscriptions","organizations_url":"https://api.github.com/users/ericsoco/orgs","repos_url":"https://api.github.com/users/ericsoco/repos","events_url":"https://api.github.com/users/ericsoco/events{/privacy}","received_events_url":"https://api.github.com/users/ericsoco/received_events","type":"User","site_admin":false},"created_at":"2016-03-24T18:33:02Z","updated_at":"2016-03-24T18:33:02Z","body":"Here's another style: https://github.com/mattdesl/eases\r\n\r\nI'm not sure yet if this would work for us, needs some thought. But the idea is that the library is not compressed or transpiled (the latter, we can discuss), but is brought in as raw source. And each component has a single entry point, a js/x file, and you just import that file (and it imports whatever other local files are necessary).\r\n\r\nStill don't see how this will help with dependencies at the npm level (would still have to specify everything used by each component in `dependencies`).\r\n\r\nAnother, somewhat-related thought: maybe we need to offload some of the complexity to the downstream project, in terms of determining which dependencies from the toolkit to package into its build? A bit less portable but we can shepherd the process, esp. on internal Richmond/Stamen projects. Might be simpler."}}