Closed dwelch2344 closed 11 years ago
Not quite sure I follow you.
One of the key goals of the project is to reduce the friction of developing with assets that need preprocessing, and get it to a save-and-go cycle. In that regard, watching files in dev mode is critical.
This allows things like Less/Coffeescript/Tpescript etc, to be recompiled in the background as files change.
This is implemented now, albeit in a single threaded fashion. There's also support for processors to advise additional files to watch, beyond the initially declared file (useful for processing @imports, etc)
I'm using bakehouse daily a large, non-trivial app, and only occasionally finding that the compile cycles slow me down. (regardless, there's an issue to move the processing into a multithreaded context). I would like bakehouse to make working on files that need pre-processing as seamless as possible.
The ability to control this behaviour between envs is the other major goal... And is defined by providing different @Profile
configurations. (take a look at the demo project for an example of how this is intended to work)
In my current project, we leave .js files alone in dev (no concatenation / minification); compile typescript and Less.
In prod, files are concatenated, and there's a little minification.... Though minification is one area that needs a bunch more focus.
I agree that there should be an option to advise the config not to watch files, as...like you say, beyond dev, these don't change.
Great response. That's along the lines of what I was hoping for. Sounds like its right up my alley :D
Sent from my iPhone
On Feb 9, 2013, at 10:38 PM, martypitt notifications@github.com wrote:
Not quite sure I follow you.
One of the key goals of the project is to reduce the friction of developing with assets that need preprocessing, and get it to a save-and-go cycle. In that regard, watching files in dev mode is critical.
This allows things like Less/Coffeescript/Tpescript etc, to be recompiled in the background as files change.
This is implemented now, albeit in a single threaded fashion. There's also support for processors to advise additional files to watch, beyond the initially declared file (useful for processing @imports, etc)
I'm using bakehouse daily a large, non-trivial app, and only occasionally finding that the compile cycles slow me down. (regardless, there's an issue to move the processing into a multithreaded context). I would like bakehouse to make working on files that need pre-processing as seamless as possible.
The ability to control this behaviour between envs is the other major goal... And is defined by providing different @Profile configurations. (take a look at the demo project for an example of how this is intended to work)
In my current project, we leave .js files alone in dev (no concatenation / minification); compile typescript and Less.
In prod, files are concatenated, and there's a little minification.... Though minification is one area that needs a bunch more focus.
I agree that there should be an option to advise the config not to watch files, as...like you say, beyond dev, these don't change.
— Reply to this email directly or view it on GitHubhttps://github.com/TheMangoFactory/bakehouse/issues/19#issuecomment-13344782..
I was pondering the implementation for different environments / profiles (dev vs test vs production) and considering how it might be tricky to watch for changes while in development.
If you're going to write code to do it, it'll have to handle concurrency for multithreaded environments. Then I realized that probably isn't really necessary. If you think about it, you only really need to recompile / reload code when in development. Once you move out to test and production servers, it should never change really.
Along those lines, you really wouldn't even need to operate (minify, concat, etc) the source files as it'd be nicer to have the "raw" versions available while debugging (although for something like Less you'd also need the compiled form). But what I was thinking is that there could be a flag for either "debug" mode where your assets are plainly visible in a least-modified-from-source state, and then "live" or "optimized" mode.
Thoughts?