Mechanism to reorder tasks?

[evilsoft]

While working on a template to use Backbone.Marionette with the Browserify plugin, I found that a majority of the Browserify issues really only stem from the order in which the JS is compiled.

To get around the compilation order issue I committed a huge sin in completely overriding appTasks['common']. This is horrible, as any plugins users of this template would use would not be represented in the common tasks, unless it is added to config/application.coffee.

My question is, is there a way to remove specific tasks from common only and then rebuild the stack in prependTasks/appendTasks? I tried this with removeTasks but removeTasks seems to be applied after prependTasks/appendTasks is merged in. That then removes the tasks from the entire stack.

If there is not a built in way to this now, I am curious if it makes sense for me to submit a PR to add another collection to the config that would be applied before prependTasks/appendTasks or just build out a function that plucks those out of appTasks in my templates config file?

A mechanism like this would clear up a majority of the broken with the Browserify plugin in a nice, easy to read way.

The only other bit is that Browserify wants to own the sourcemaps, so you just let Browserify own the concat and sourcemap bit as well. Just have to remember to shim in all the vendor deps in a given project's config.

[searls]

Right now you can always take the task list from lineman.config.application and modify it or replace the associated property path in your return object. I've been putting up with that solution for a year now, and I agree that it is not fantastic.

My current plan, and it's been on the backburner for a while is to introduce a new API that is rule based and additive. Meaning that in your application you'd just define a set of rules about tasks, indicating requirements like '"foo:bar" must come after "blah:baz"' and it would play back the rules such that they were respected. This would certainly be preferrable to punting around a data structure from lineman core, through all the plugins, and onward to the user config.

All that to say, this is an issue and we have put some thought into it, and we hope to resolve it relatively soon.

On Wed, Jul 30, 2014 at 12:06 PM, Ian Hofmann-Hicks notifications@github.com wrote:

While working on a template to use Backbone.Marionette with the Browserify plugin, I found that a majority of the Browserify issues really only stem from the order in which the JS is compiled. To get around the compilation order issue I committed a huge sin in completely overriding appTasks['common']. This is horrible, as any plugins users of this template would use would not be represented in the common tasks, unless it is added to config/application.coffee. My question is, is there a way to remove specific tasks from common only and then rebuild the stack in prependTasks/appendTasks. I tried this with removeTasks but removeTasks seems to be applied after prependTasks/appendTasks is merged in. That then removes the tasks from the entire stack. If there is not a built in way to this now, I am curious if it makes sense for me to submit a PR to add another collection to the config that would be applied before prependTasks/appendTasks or just build out a function that plucks those out of appTasks in my templates config file? A mechanism like this would clear up a majority of the broken with the Browserify plugin in a nice, easy to read way.

The only other bit is that Browserify wants to own the sourcemaps, so you just let Browserify own the concat and sourcemap bit as well. Just have to remember to shim in all the vendor deps in a given project's config.

Reply to this email directly or view it on GitHub: https://github.com/linemanjs/lineman/issues/301

[evilsoft]

Awesome. Thanks for the quick response. I will keep an eye out for your fix.

Wonderful Library....keep it up,

[jaminday]

I realise this has been closed, but dropping by to +1 this.

I came across a similar scenario today where I had to completely override the appTasks.common config object to ensure the default handlebars task ran before my custom browerify task.

I ended up going with the following in my application.coffee config file:

appTasks:
    common:
      ["handlebars", "browserify"].concat(_.without(app.appTasks.common, "handlebars"))

.... but doing a complete override like this doesn't quite feel right. It was the best I could come up with though.

I'm sure there are plenty of higher-priority things to work on, but a nice programmatic way to customise the order of tasks would be a bonus!

All in all though, really digging Lineman so far. Thanks for making such a great tool.

[searls]

Yeah we are stuck having to do the same. What we need is an abstraction that lets us define rules about what we want to accomplish (eg "I want coffee after cssmin"), so that we don't have lineman, N plugins, and users all editing the same data structure.

On Sun, Nov 2, 2014 at 2:19 AM, Jamin Day notifications@github.com wrote:

I realise this has been closed, but dropping by to +1 this. I came across a similar scenario today where I had to completely override the appTasks.common config object to ensure the default handlebars task ran before my custom browerify task. I ended up going with the following in my application.coffee config file:

appTasks:
    common:
      ["handlebars", "browserify"].concat(_.without(app.appTasks.common, "handlebars"))

.... but doing a complete override like this doesn't quite feel right. It was the best I could come up with though. I'm sure there are plenty of higher-priority things to work on, but a nice programmatic way to customise the order of tasks would be a bonus!

All in all though, really digging Lineman so far. Thanks for making such a great tool.

Reply to this email directly or view it on GitHub: https://github.com/linemanjs/lineman/issues/301#issuecomment-61396831