have ddc emit a post-compile map

[devoncarew]

Something like a json file that specifies what files were generated where. This would be valuable to downstream tools that may want to post-process the compile artifacts; move them around, concatenate them, ...

[jmesserly]

certainly easy to do. I wonder though, what do JavaScript authors normally do? Presumably if you're writing JS by hand, you don't have a "post-compile map". I'm not aware of one from TypeScript/BabelJS/CoffeeScript either.

Maybe https://babeljs.io/docs/setup/ can give us some ideas on the best way to integrate with build tools?

[jmesserly]

btw, don't mean to say "no" to this. But I like to ask "what would JavaScript do" or "what do other JavaScript tools do". It keeps us honest on our "we're just JavaScript" goal, plus it means we can reuse ideas, which means one less problem for us to solve, and it can lead to better usability too, as it's already familiar to our users.

[devoncarew]

Gotcha. Yeah, this is really more of an idea - something I would have consumed here: https://github.com/flutter/atom-flutter-dev/blob/master/tool/grind.dart#L25 instead of traversing dirs looking for .js files. If there's something that would integrate better w/ a JS workflow, +1.

[vsmenon]

I think the current situation is exacerbated by how we handle dart:* libraries - i.e., lots of little libs with (to the user) meaningless names reflecting internal helper libs.

BTW, if we end up using something like requirejs, it appears to provide it's own tools for concatenating / packaging.

[jmesserly]

Ahhhh, good call @vsmenon! Yeah we need a require('dart/core') or something like that, and it just gets everything.

[jmesserly]

but yeah I agree, this is basically we don't interop with JS modules (#285)

[devoncarew]

I'll close this out in favor of tying into existing JS workflows, and ddc supporting node / io.js modules / require().