{"action":"created","issue":{"url":"https://api.github.com/repos/assetgraph/assetgraph/issues/235","labels_url":"https://api.github.com/repos/assetgraph/assetgraph/issues/235/labels{/name}","comments_url":"https://api.github.com/repos/assetgraph/assetgraph/issues/235/comments","events_url":"https://api.github.com/repos/assetgraph/assetgraph/issues/235/events","html_url":"https://github.com/assetgraph/assetgraph/issues/235","id":55793780,"number":235,"title":"Population lifecycle events, limiting the scope of Assetgraph","user":{"login":"Munter","id":331790,"avatar_url":"https://avatars.githubusercontent.com/u/331790?v=3","gravatar_id":"","url":"https://api.github.com/users/Munter","html_url":"https://github.com/Munter","followers_url":"https://api.github.com/users/Munter/followers","following_url":"https://api.github.com/users/Munter/following{/other_user}","gists_url":"https://api.github.com/users/Munter/gists{/gist_id}","starred_url":"https://api.github.com/users/Munter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Munter/subscriptions","organizations_url":"https://api.github.com/users/Munter/orgs","repos_url":"https://api.github.com/users/Munter/repos","events_url":"https://api.github.com/users/Munter/events{/privacy}","received_events_url":"https://api.github.com/users/Munter/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/assetgraph/assetgraph/labels/Question","name":"Question","color":"f7c6c7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-01-28T18:16:02Z","updated_at":"2015-01-28T19:51:39Z","closed_at":null,"body":"I have been thinking that our approach to handling preprocessing of assets is not good enough to cover all use cases and isn't extensible enough for people to hook in with their own custom logic.\r\n\r\nI had an idea that it might make sense to expose some population lifecycle events, giving the consumer an option to manipulate assets or relations before they are even added to the graph.\r\n\r\nThis would allow us to think less about all the different kinds of non-web assets that might exist in the graph and how to make them become web assets, thus keeping the scope for Assetgraph narrow.\r\n\r\nObviously we would have to expose an opt-in or opt-out default transformation to make it useful to consumers that don't care for a high degree of customizability. [Accord](https://github.com/jenius/accord) would probably be the best bet here for covering as many compilations as possible and move them out of our range of responsibility.\r\n\r\nObviously the `findOutgoingRelations` methods would still need to be able to pick up the references to these now unknown asset types, but then instead of modeling them as non-web assets just pass the unknown relation to some sort of a resolver-compiler combo.\r\n\r\nDoes this make sense?"},"comment":{"url":"https://api.github.com/repos/assetgraph/assetgraph/issues/comments/71903011","html_url":"https://github.com/assetgraph/assetgraph/issues/235#issuecomment-71903011","issue_url":"https://api.github.com/repos/assetgraph/assetgraph/issues/235","id":71903011,"user":{"login":"Munter","id":331790,"avatar_url":"https://avatars.githubusercontent.com/u/331790?v=3","gravatar_id":"","url":"https://api.github.com/users/Munter","html_url":"https://github.com/Munter","followers_url":"https://api.github.com/users/Munter/followers","following_url":"https://api.github.com/users/Munter/following{/other_user}","gists_url":"https://api.github.com/users/Munter/gists{/gist_id}","starred_url":"https://api.github.com/users/Munter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Munter/subscriptions","organizations_url":"https://api.github.com/users/Munter/orgs","repos_url":"https://api.github.com/users/Munter/repos","events_url":"https://api.github.com/users/Munter/events{/privacy}","received_events_url":"https://api.github.com/users/Munter/received_events","type":"User","site_admin":false},"created_at":"2015-01-28T19:51:39Z","updated_at":"2015-01-28T19:51:39Z","body":"Can sourcemaps be base64 inlined and still be valid? If so, that would solve that problem. If we haven't already added support for that in assetgraph we certainly should.\r\nWriting to disk and reading it back seems like a hacky solution in comparison.\r\n\r\nFor the precompilers that access assets on disk, assuming we hook into some sort of an `addRelation` event, the complete file url will be available to the compiler if it needs it. However the compiler choses to gather its dependencies would be out of scope for Assetgraph. I've had the same when compiling Sass with `@import` statements. It works fine just letting the compiler figure it out, as long as you don't require special magic with multiple search directories for includes (worst design idea ever).\r\n\r\n@mafintosh had a great idea about wrapping the whole precompiling mess into a mock file system. Reading from it would produce the compiled asset. This would be a great abstraction, since everybody is currently reimplementing precompiling over and over and over for development, build and tests. A file system wrapper would be far superior\r\n"}}