Custom type support

[dominicbarnes]

It would be awesome if this lib would allow custom types to be registered from the outside, this would be a great first-step to solving duojs/duo#171

var filedeps = require("file-deps");

filedeps.type('html', function (str, ext, fn) {
  // custom type handler
});

[matthewmueller]

+1, I think html would probably be the only other one right? It might make more sense to just include it in this lib. That was the original plan anyway.

Otherwise, can you think of a good way to extend this through Duo's API?

[dominicbarnes]

Well, I had something other than HTML in mind, namely that .assets file I mentioned in the duo issue.

I haven't come up with a gameplan over in duo-land yet, but perhaps something like:

Duo(root)
  .type("assets", require("duo-assets"))
  .entry("client.assets", "assets");

[matthewmueller]

hm, so basically this would walk client.assets for dependencies?

What about using duo.include(file, src) to put it in the mapping? then pulling it in from there maybe.

Otherwise if we covered html in addition to css and js, wouldn't that take care of all possible ways to include an asset?

[dominicbarnes]

Could you include an example of duo.include in context? I'm not sure I follow yet

Including static HTML support is necessary, but it won't cover everything. Specifically, it breaks down when you're considering any template library, especially non-HTML-ish ones like jade. (especially if there are files included via dynamic attributes) Duo can't possibly predict all of these scenarios, nor should it, which is why configurability should be reached for.

[matthewmueller]

So the way I see it going down is all the high-level languages will be compiled first. In the same way that .coffee is compiled to JS before dependencies are parsed. Flow would look like:

jade => html => [favicon.ico, img, ... ] => symlink / copy 

[matthewmueller]

For the includes stuff. This won't work yet, but i think it'd be easy to fix:

if (duo.assets) {
  for (var i = 0, asset; asset = assets[i++];)
    duo.include(asset) // asset contains all the info
}

We're basically injecting information directly into the duo.json with include. Then we have something at the end run through the duo.json and symlink / copy those assets. Not 100% sure I follow what you have in mind either though.

[dominicbarnes]

I'm really talking about server-side templates here, which don't need to be processed by duo or sent to the client. (besides, if they are generated per-user with database info, that limits what duo can pick up anyways) However, the assets that these templates reference need to make it into the build/ directory, just like the JS/CSS we are generating via duo.

That being said, since these assets don't make sense to be referenced in my JS/CSS entry files, duo needs a way to be informed about them. For consistency, I thought a new/custom entry type made sense.

I get that this new entry file type is basically a manifest. (which people seem to be knee-jerking against right now) But, if I'm going to be ditching the component.json for dependencies/scripts/styles, I wouldn't want one that only has images/fonts/files.

As far as your includes example, where exactly is duo.assets coming from?

[matthewmueller]

I'm really talking about server-side templates here, which don't need to be processed by duo or sent to the client. However, the assets that these templates reference need to make it into the build/ directory, just like the JS/CSS we are generating via duo.

Yah same page. So I'm wondering if it makes sense to run through the build so all our assets get symlinked from our jade file, but throw away the output (the built html).

I get that this new entry file type is basically a manifest. (which people seem to be knee-jerking against right now) But, if I'm going to be ditching the component.json for dependencies/scripts/styles, I wouldn't want one that only has images/fonts/files.

Good point. My confusion is more like... what is client.assets? is it a file? a folder? I think if we removed the support check, you could just do:

var src = yield duo(root)
  .entry('some-image-asset.png')
  .run();

src would be '' and the image would get symlinked. I don't think that's ideal for more than a couple assets though.

As far as your includes example, where exactly is duo.assets coming from?

This would be from the component.json manifest. Not saying this is a great solution for anything other than migrating existing component apps to duo.

[dominicbarnes]

If duo can be fed assets like that, if it could also support either globs or copying entire folders, that would be enough for me. (easy enough to put that in a makefile)

$ duo pages/home/public/
# copies to build/pages/home/public/

$ duo pages/home/images/*.png
# copies all the png files to build/pages/home/images/

Is that what you are thinking?

[matthewmueller]

Okay, we'll need a few tests around this, but I think all that is required is removing this line:

https://github.com/duojs/duo/blob/master/lib/duo.js#L510

[matthewmueller]

Is that what you are thinking?

Yah, I think that would be pretty cool actually

[dominicbarnes]

Could even run those kinds of things through plugins too. That could lead to using duo as a complete asset pipeline, applying compression on images, minification, etc! (awesome)

I'm guessing up-front the CLI would convert globs and folders into lists of files.