If you're interested in file-based tools, Jake [1] has excellent support for the sort of rules Fez of offers, and is quite mature.<p>I haven't dug deeply into Fez yet, but here's a few things Fez seems to offer that Jake doesn't:<p>1- Automatic concurrency. Like Gulp, Fez's subtasks run in parallel. It looks like Fez launches them in subprocesses in order to prevent conflicts, which is a good idea. I'm skeptical of parallelism in builds, though, because race conditions lead to nasty, hard-to-detect-and-fix bugs. I don't think the theoretical speed boost is worth the potential of defects getting into released code.<p>2- Automatic pipelining. Also like Gulp, Fez can pipe the output of one operation to the input of another. This is useful because you can avoid dealing with temporary files. Unlike Gulp, Fez has an extremely simple and non-error-prone way of constructing those pipelines. I like it.<p>The major advantage of Fez (and Jake) over Grunt and Gulp is that they use file timestamps to tell if a task needs to run. This can lead to major speed benefits. I recently modified my Jakefile to use this sort of dirty checking on my Sass compiler. I don't change my CSS that often, but the css task was doing an expensive "shell to Ruby" command on every build no matter what. Adding dirty checking shaved my typical build time down from 6.5s to 3.5s.<p>Overall, Fez looks like a really nice tool. It has a strong ideology (rule-based transformation of files) tempered by a nice dose of practicality. For example, although Fez wants every task to define a file-transformation rule, it also supports "imperative mode" for tasks that don't fit that model. It's very promising, and I'm looking forward to learning more.<p>[1] Jake: <a href="https://github.com/mde/jake" rel="nofollow">https://github.com/mde/jake</a>
I'm suppose I'm in the minority of developers that _don't_ think we need to learn more build tools.<p>make, configure, automake, autoconf, MSBuild, Apache Ant, rake, gradle, jake, grunt, gulp, fez<p>Sorry, I'm sure your system is nice and organized. But now you've introduced one more build dependency that will make projects based on Fez just a little more difficult to on-board.
I wonder what the pros/cons are for Fez, compared to Gulp: <a href="https://github.com/gulpjs/gulp" rel="nofollow">https://github.com/gulpjs/gulp</a>
I am in the process of creating a build tool too (for a different language: Java)
I noticed that you have some magic variables (%f), like make ($<, etc..). I am trying to avoid that, but I cannot come up with a clean way without 'magic' variables (e.g. When using wildcards, one would need to know the set of files that have changed. Mine is something similar to<p><pre><code> classes/**/*.class -> src/**/*.java:
javac [WHAT TO USE IF NOT A 'Maigc var'?]
</code></pre>
Also:<p>1. Will fez support different dir for target and recipes? (like above example I gave) ?<p>2. What about targets that do not have a file dependency (e.g. .PHONY in make)? How does fez deal with it?<p>What I am trying to avoid is a big learning curve (or have a user need to read a book) :-)<p>Thank you and success in your project!
I don't understand how to use it. Can I just write this:<p><pre><code> *.less → %f.css
*.css → %f.min.css
*.min.css → dist.min.css
</code></pre>
in a file and then run the command "fez"? And if not, then why not? If that was how you used fez then I would strongly consider using it.<p>If you are looking for a build tool, I strongly recommend you first consider a bash script.<p>Or if you are still looking for a build tool, like you collect them or something, I made my own too (lol): <a href="https://github.com/ithkuil/bild" rel="nofollow">https://github.com/ithkuil/bild</a><p>Mine uses yaml files like this:<p><pre><code> - coffee:
files: src/*.coffee
out: lib
- uglify:
files: public/js/*.js
out: public/js/min.js</code></pre>
This could turn out to be incredibly powerful tooling for Javascript compilation.<p>I'm not a fan of Require-type systems because they introduce additional runtime behavior. With the proper dependency graph tools available at compile time, we could remove the need for AMD completely. This will reduce client overhead and boilerplate. (Granted, AMD boilerplate will be converted into a dependency graph spec. But it would be there regardless, and I am of the opinion that this is a superior form.)<p>Exciting times ahead...
Similar to Bud: <a href="http://github.com/azer/bud" rel="nofollow">http://github.com/azer/bud</a> (<a href="https://medium.com/p/6a4c74b4bd90" rel="nofollow">https://medium.com/p/6a4c74b4bd90</a>)<p>See how Bud approaches building and watching changes; <a href="https://gist.github.com/azer/7819664" rel="nofollow">https://gist.github.com/azer/7819664</a>
Cool! I have two questions: does this support watching files to regenerate them?<p>Second, one of the main features from my similar project (npm install webapp-builder) is appending a socket.io connection to generated HTML to force a browser refresh when files have finished building. I view webapp-builder as too monolithic, so I'm curious how difficult it would be to implement a similar feature in Fez?
Pretty cool! Does it track dependencies of build steps that have "require"? E.g. if I have a javascript bundle being built using browserify - will it track the files that browserify is loading? Also: Did you consider reusing the Grunt ecosystem? E.g. enable loading grunt plugins and treat this as a potential alternate runner?
Looks interesting. A note to the author: that post is very difficult to read on mobile. Setting a width on your container will go a long way to improve readability (e.g. .wrapper { max-width: 90%; margin: 0 auto; }).