account for client template compilation

[pruett]

just wanted to throw this in the log...

leverage roots-browserify + roots-client-templates as a singlular compiled js file would be awesome

not sure the best API for such a declaration, maybe a flag when defining the browserify extension would work? :thought_balloon:

[hhsnopek]

this would be nice for roots-yaml as well. @jenius what would be the prefered method for this? pass a boolean option through with an optional key name for accessing the data?

[jescalan]

This is a super tough issue, because it means interfacing between two different extensions. I don't want to make this happen through other-extension-specific options in one extension, I'd much rather have a general interface for this as the solution, which is a much larger undertaking.

[joshrowley]

You could probably make this happen in your app.coffee

[jescalan]

The problem is that a lot of the time people want to essentially pipe the output of one extension into another. But it's not a direct pipe necessarily to the next extension in like, and it's not necessarily piping the output, sometimes you want to pipe something that roots understands through.

[hhsnopek]

my initial thought for browserify & client-templates would be to put them together, but we could do that with roots-yaml as well.

Why not have an option where compilation of roots-client-templates & roots-yaml would export them as modules, which we could pipe in each file after they're compiled (because of the roots compilation ordering), then during roots-browserify we can add the file in, and remove it.

[jescalan]

I don't think putting them together is the right answer.

For your second point, I don't really understand...

[hhsnopek]

Exactly what I was getting at with my first point.

For the second: so lets say we have an option for roots-client-templates & roots-yaml to build a file that is UMD compatible.

Example:

var data = {};
module.exports = Data;

Then we take those compiled files, and pipe them into roots-browserify which would add them in as dependencies (where required). After roots-browserify has compiled piped template.js or the data object we can delete template.js from our public folder.

[jescalan]

Client templates already generates UMD wrapped files always, so that's the good news. It's the piping in part that's the challenge.

[hhsnopek]

We could have a promise within the browserify stream that waits for templates.js and data object ready to be accessible, maybe events emitted, then starts or completes the stream?

[jescalan]

I think you'd have to dive a little deeper into the roots internals to understand how we could potentially make this happen -- that isn't possible unfortunately.

[hhsnopek]

lowest priority can't be given to roots-browserify? https://github.com/jenius/roots/blob/v3/lib/extensions.coffee#L33

[jescalan]

This still is not relevant to the current issue :confused:

[hhsnopek]

hmm so there's no way currently to make browserify run last? I know that we're trying to make it accord run parallel which doesn't help either if we want to have it wait

[jescalan]

You can make it run last, but that does not solve the problem we're talking about.

[hhsnopek]

Well my thought was if browserify runs last, verifying that roots-client-templates and/or roots-yaml is done compiling (with an event emitter), we can take templates.js and/or the data object (so long you have required the expected location of templates.js into your logic at some point) and requiring it properly.

[jescalan]

There's a lot more complexity than you think going on with the ordering in the compile process. While I'd be happy to review a PR if you really want to dive into this, I don't have the time to take this on myself at the moment.

[hhsnopek]

I'll dive into it and see what I can do :smile: I might bounce more ideas around here before I do that