{"action":"created","issue":{"url":"https://api.github.com/repos/americanpanorama/panorama/issues/12","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":1,"created_at":"2015-12-22T18:34:15Z","updated_at":"2015-12-24T07:30:10Z","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/167060711","html_url":"https://github.com/americanpanorama/panorama/issues/12#issuecomment-167060711","issue_url":"https://api.github.com/repos/americanpanorama/panorama/issues/12","id":167060711,"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":"2015-12-24T07:30:10Z","updated_at":"2015-12-24T07:30:10Z","body":"I'm not sure that supporting inclusion via `<script>` is something we really want to aim for. We're targeting an intermediate+ JS developer audience, one who should be ok running an `npm install`. If we make that explicit in our docs (I think we already have, in `@panorama/toolkit` and in `panorama-template`, I think our bases are covered.\r\n\r\nThat means that #10 is all we really need to aim for.\r\n\r\nGoing the npm route means also that we don't have to worry about the upstream deps confusion you mention -- npm will handle this if we get our build right."}}