{"action":"created","issue":{"url":"https://api.github.com/repos/dojo/core/issues/145","repository_url":"https://api.github.com/repos/dojo/core","labels_url":"https://api.github.com/repos/dojo/core/issues/145/labels{/name}","comments_url":"https://api.github.com/repos/dojo/core/issues/145/comments","events_url":"https://api.github.com/repos/dojo/core/issues/145/events","html_url":"https://github.com/dojo/core/issues/145","id":149403618,"number":145,"title":"Split Shims and Functional Core","user":{"login":"kitsonk","id":1282577,"avatar_url":"https://avatars.githubusercontent.com/u/1282577?v=3","gravatar_id":"","url":"https://api.github.com/users/kitsonk","html_url":"https://github.com/kitsonk","followers_url":"https://api.github.com/users/kitsonk/followers","following_url":"https://api.github.com/users/kitsonk/following{/other_user}","gists_url":"https://api.github.com/users/kitsonk/gists{/gist_id}","starred_url":"https://api.github.com/users/kitsonk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kitsonk/subscriptions","organizations_url":"https://api.github.com/users/kitsonk/orgs","repos_url":"https://api.github.com/users/kitsonk/repos","events_url":"https://api.github.com/users/kitsonk/events{/privacy}","received_events_url":"https://api.github.com/users/kitsonk/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/dojo/core/labels/discussion","name":"discussion","color":"d4c5f9"}],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/dojo/core/milestones/7","html_url":"https://github.com/dojo/core/milestones/2016.04","labels_url":"https://api.github.com/repos/dojo/core/milestones/7/labels","id":1692697,"number":7,"title":"2016.04","description":"","creator":{"login":"kitsonk","id":1282577,"avatar_url":"https://avatars.githubusercontent.com/u/1282577?v=3","gravatar_id":"","url":"https://api.github.com/users/kitsonk","html_url":"https://github.com/kitsonk","followers_url":"https://api.github.com/users/kitsonk/followers","following_url":"https://api.github.com/users/kitsonk/following{/other_user}","gists_url":"https://api.github.com/users/kitsonk/gists{/gist_id}","starred_url":"https://api.github.com/users/kitsonk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kitsonk/subscriptions","organizations_url":"https://api.github.com/users/kitsonk/orgs","repos_url":"https://api.github.com/users/kitsonk/repos","events_url":"https://api.github.com/users/kitsonk/events{/privacy}","received_events_url":"https://api.github.com/users/kitsonk/received_events","type":"User","site_admin":false},"open_issues":10,"closed_issues":7,"state":"open","created_at":"2016-04-08T09:45:41Z","updated_at":"2016-04-22T08:56:42Z","due_on":"2016-04-29T23:00:00Z","closed_at":null},"comments":9,"created_at":"2016-04-19T09:34:05Z","updated_at":"2016-04-22T09:20:15Z","closed_at":null,"body":"@novemberborn pointed out that [`dojo/compose`](/dojo/compose) currently only has a dependency of `WeakMap` on core.  It raised the thought in my head that maybe we should split core into things that provide functional shims to ES6+ (and W3C APIs not fully available) and things that are actual functional enhancements to APIs that we would prefer to use (e.g. `request`).  This could reduce dependendicies for some packages and give a clear distinction between replicating APIs and providing *unique* APIs.  `Task` would go into *core* while `Promise` would be in *shims*.\r\n\r\nIt would also reduce my *worry* about Streams being in core.  That would clearly go into the shims package, because it is trying to replicate an future API.  It also gives us a clear option to produce a \"modern\" version of the shims package that is essentially nothing but `export default Promise;`."},"comment":{"url":"https://api.github.com/repos/dojo/core/issues/comments/213349287","html_url":"https://github.com/dojo/core/issues/145#issuecomment-213349287","issue_url":"https://api.github.com/repos/dojo/core/issues/145","id":213349287,"user":{"login":"kitsonk","id":1282577,"avatar_url":"https://avatars.githubusercontent.com/u/1282577?v=3","gravatar_id":"","url":"https://api.github.com/users/kitsonk","html_url":"https://github.com/kitsonk","followers_url":"https://api.github.com/users/kitsonk/followers","following_url":"https://api.github.com/users/kitsonk/following{/other_user}","gists_url":"https://api.github.com/users/kitsonk/gists{/gist_id}","starred_url":"https://api.github.com/users/kitsonk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kitsonk/subscriptions","organizations_url":"https://api.github.com/users/kitsonk/orgs","repos_url":"https://api.github.com/users/kitsonk/repos","events_url":"https://api.github.com/users/kitsonk/events{/privacy}","received_events_url":"https://api.github.com/users/kitsonk/received_events","type":"User","site_admin":false},"created_at":"2016-04-22T09:20:15Z","updated_at":"2016-04-22T09:20:15Z","body":"> Could you elaborate? I think npm is useful for managing dependencies. The build system would then do tree shaking and whatnot to produce runnable code.\r\n\r\nIt does, if you know what those dependencies are, where you should locate them and more specifically in a browser how to deal effectively with conflicting dependencies.  npm and CommonJS modules make big assumptions about having unfettered access to a filesystem, which browsers do not.  npm3 \"helps\" in its default behaviour of flattening dependencies.  Many people don't fully understand or appreciate the semantics of npm (including myself sometimes, as it was only relatively recently I began to understand `peerDependencies` and I had to help @dylans understand why that was better for a lot of things).\r\n\r\nFor our own purposes, a \"bare metal\" [npm toolchain](http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/) might be fine, but it takes a fair amount of knowledge to be able to build something incremental on top of it.  My feeling is that we should have a system that allows people to easily integrate our packages into their preferred toolchain (which is why having them on npm and hopefully bower makes that the easiest way for them to be consumed) but also provide an \"out of the box\" toolchain that works.  This provides an example of how we intend the packages to be consumed as well as provides those without a toolchain something to work with.  In my opinion, one of the biggest objectives we need around this space is that if a new developer cannot get a full Dojo 2 app running in less than 15 minutes, we have failed.\r\n\r\n> I appreciate that we don't want to ask people to install 20 packages in order to build a Dojo 2 application, but then why even have dojo/compose outside of dojo/core?\r\n\r\nWe will always be striking a balance between `left-pad`/`lodash` and `dojo/dojo`.  At the most basic, a Dojo 2 package meets these criteria:\r\n\r\n* A clear concise functional purpose\r\n  * That logically could have its own development/release cycle\r\n  * And could be managed with a maintainer\r\n* No circular dependencies on other packages\r\n* Minimise runtime dependencies on other packages\r\n"}}