middleware and targets dependencies

[aurmil]

hello

let's consider this config:

[css]
paths[] = ...
paths[] = ...
cachePath = ...

[tmp_local.css]
files[] = ...
files[] = ...
filters[] = CssMinFilter

[styles.css]
files[] = ...
files[] = tmp_local.css

when compiling through CLI, everything is OK when using middleware and accessing style.css file, which is the main one, error:

Could not locate tmp_local.css for styles.css in any configured path.

middleware should check if file is a target (or I did something wrong)

[markstory]

Is the cachePath inside paths[] for your CSS files? You might be getting lucky with build order in the CLI tool. The middleware doesn't build static assets and won't check for files depending on other targets.

If you want to 'extend' one target with another you need to use the extend option in your asset definition. I think your styles.css target should look like:

[styles.css]
extend = tmp_local.css
files[] = ...
files[] = ...

[aurmil]

1. yes, cachePath is inside paths[]
2. lucky, may be, I intentionaly declared "child" section (tmp_local.css) before "main" section (styles.css) in ini config file. I didn't check if sections order was followed by the tool but I counted on it and it works
3. actually, using extend does not meet my needs. my current need is: tmp_local = merge and minify my custom files then styles = merge vendors files already minified + tmp_local. I just wanted not to parse/minify files that are already minified

[markstory]

I don't think there will be a way for the middleware to generate the styles file without using extend unless you pre-generate the tmp_local as a static asset. However, that will disrupt the edit, refresh flow for styles in tmp_local

[aurmil]

yep, I understand for the middleware could we imagine a "require = target"?

[css]
paths[] = ...
paths[] = ...
cachePath = ...

[a.css]
files[] = ...
files[] = ...
filters[] = CssMinFilter

[b.css]
require = a.css
files[] = ...

unlike extend, b.css does not inherit properties from a.css it just specifies that b.css need to "include" a.css target file

if it seems OK for you, I'll will make a new issue for this point

[markstory]

How is that different than extend though? You earlier asset definition included bundling tmp_local into styles.css, which is functionally equivalent to making all of the dependencies of tmp_local dependencies of styles so beyond the overhead of re-minification (which the middleware doesn't do) why doesn't extend work?

[aurmil]

with extend, if

[A.css]
...

[B.css]
extend = a.css
...

filters declared by A are applied to B my need is to apply some filters on A and then A be a part of B content + apply other filters to B, not the same filters that were applied to A hope I'm clear enough

[markstory]

Ok. The filter application needing to be different is a reason that extend wouldn't be suitable, and we'd need a new way to express what is wanted.

[markstory]

Would it make sense for a require target's output file to be treated like a 'source' file for the second target. For example

[vendor.js]
files[] = a.js
files[] = b.js
filters[] = UglifyJs

[app.js]
require = vendor.js
files[] = c.js
filters[] = UglifyJs

In the above example, the generated vendor.js (post minification) is added to the files[] list of app.js. This would result in vendor.js being run through uglify twice, but I think that is required if we want targets to be used transparently both as standalone targets, and as inputs to other targets.

[aurmil]

yes, seems to match what I had in mind

[markstory]

@aurmil Cool, I should have something functional up in a few days. I have to work out caching the intermediary results.

[markstory]

Closing as a pull request is up now.