01:54 <ShoeSuedeBlues> Gentlemen, I have a question conerning vienna. I am not sure if this is the right place to ask.

01:57 <ShoeSuedeBlues> I can’t seem to the the todo’s example up and running. Vienna never loads.

12:02 <adambeynon> elia: I forget, how do I require javascript files using the new builder? (it keeps trying to parse it as ruby)

12:02 <elia> yeah, you need to explicitly use .js

12:03 <elia> but I'd like to get rid of that

12:03 <adambeynon> ahh right. forgot about that :)

12:03 <elia> and maybe teach the path reader to detect mime type

12:03 <elia> at the cost of reinventing sprockets… :(

12:12 <adambeynon> elia: I did think of another way to possibly handle the requires. When we encounter a require() directive inside a ruby file (compiler.requires) then we could add that to the sprockets env (environment.opal_requires = Set.new), so when we actually compile a ruby file inside the processor, If it is in that list of required files, then we could wrap it inside

12:12 <adambeynon> the Opal.modules stuff

12:12 <adambeynon> that way, the "main" file would compile as-is, and only required files would be registered

12:12 <adambeynon> as you say, fighting against sprockets might cause issues

12:14 <elia> adambeynon, i fear that would be fighting against sprockets really

12:14 <elia> adambeynon, it surely fights with sprockets cache

12:15 <elia> and probably with having multiple sprockets "manifest" (main) files

12:15 <elia> which I'm quite sure is the case for many ppl

12:16 <elia> adambeynon, another (ugly) way is to wrap everything and then ask ppl to Opal.require the main file from JS

12:16 <adambeynon> thats true

12:22 <adambeynon> elia: that could be a good solution - thing is, we could be flexible - offer the old style, and the wrapped style as a config option

12:23 <adambeynon> although

12:23 <adambeynon> well

12:23 <adambeynon> no, thats probably silly

12:25 <elia> adambeynon, I think that if we take the burden to duplicate (for the good) some functionalities of sprockets we can get the best out of both worlds (being manifest vs. wrapping)

12:26 <elia> adambeynon, and if the work is done the right way when we're in the context of sprockets we can link to it for file retrieval, cache, paths, etc.

12:29 <elia> adambeynon, I think we'll need to introduce something on the lines of the Asset class from sprockets, that knows it's mime, real path, logic path

14:07 <adambeynon> elia: do you think there is any way that we can get sprockets to serve up each file individually as well? (they are currently being concatenated using new builder)

14:13 <elia> adambeynon, right, that's another issue

14:14 <elia> adambeynon, I don't think it's possible afaik, unless we find some hacky trick :)

14:15 <elia> talking about that a middleware could handle the main and have sprockets serving only wrapped stuff

14:16 <elia> I think sass serves a single file when using @import over #=require

14:26 <elia> adambeynon, …

14:26 <elia> maybe you're right

14:26 <elia> what if we store the main in the context

14:26 <elia> instead of storing the deps

14:26 <elia> we probably still need to fix the cache

20:50 <elia> adambeynon, https://github.com/rails/sprockets-rails/blob/master/lib/sprockets/rails/helper.rb#L122-L125

20:50 <elia> should we bother about multiple files?

20:52 <elia> also considering that surely the stacktrace is more clear, but the loading is way slower and concentrating efforts on SM isn't wasted time