Task Running

[ericelliott]

Choosing a Task Runner for the Cloverfield Boilerplate Scaffold

Cloverfield aims to create a next generation JavaScript project boilerplate. That means we'll use the tools that coders in-the-know will be using over the next 1 - 3 years. We're starting with the 2016 edition. Read more.

The JS community has been splintering when it comes to task runner consensus. For a while, Grunt was the clear winner, but that isn't the case anymore. We need to make a decision on one of these options, because many of our generators are going to produce some sort of task runner config. Please do some research and weigh in by answering the questions below.

Gulp and Brocolli have entered the community radar, and there is a growing trend to lean more heavily on Unix pipes instead of Node streams or the heavy file i/o typical of Grunt setups.

And the long-time reigning champion that's been a part of Unix since the time of the ancient grey beards is starting to make inroads. See Building JavaScript Projects with Make.

Oh, and npm has a built-in task runner that lets you easily leverage Unix pipes. Substack thinks that's the way to go, and he's not alone.

This is a pretty confusing landscape for those who haven't investigated all of these possible solutions, so lets try to lay out the pros and cons of each.

Questions

• What's your pick?
• What's the main reason you use it?
• What are the other advantages?
• What are the disadvantages?

  Greener fields

• If you could change one thing, what would it be?
• If you could only keep one thing, what would it be?

[benlesh]

Having worked with Grunt, Gulp and Broccoli, my current go to is Broccoli. Mostly because I'm always setting up front-end build processes, testing and dev workflows and Broccoli was engineered specifically for that problem space. It's faster to deal with during dev builds than grunt, and there's generally less noodling with the Brocfile than I'd have to do with the others.

The downside is it's not as general purpose as the other two. But that's also the upside got me at least.

Grunt has the most mature community, but is dirt-slow.

Gulp is faster than grunt (usually), but you end up doing a lot more work to set up your workflow than you will with Broccoli because of Broccoli's built in server and watching. At least if your developing UI.

[benlesh]

If I were doing something more general purpose, I suspect I'd use Gulp ATM.

[clohr]

+1 for npm's task runner.

I have found that Grunt files become unwieldy on large projects and is slower than Gulp. Having used Gulp on recent projects, I found that there are some cool ways to better organize your tasks, but a number of plugins tend to violate the Gulp guidelines and you need to research the good modules to create optimal Gulp recipes. Broccoli looks cool, but if you are looking for something that works equally well on *Nix and Windows, it doesn't appear to be quite ready for Windows.

For me, each of these task runner tools create an extra layer that can be solved simpler by just utilizing npm run per Substack. Sticking with npm eliminates the need for additional dependencies which will reduce the overall boilerplate footprint and create a low barrier of adoption for those already familiar with Node.

[jesstelford]

Makefiles

I've said it before; Using a "flavor of the month" tool for a project that is meant to last a long time is a bad idea.

Everything you can do in grunt/gulp/taskjs you can do in Makefiles, with the added benefit of decades of backing, knowledge, tutorials, and examples already out there. Given it's cross-project and cross-language, it allows others who may not be 100% familiar with JS build systems to get up and running quickly - one less tool to learn (I'm assuming most decent developers know Make already).

If not make, then npm task runners would be my second choice. Because these can be simple calls out to a bash script that does what a Makefiles would have done for you otherwise. (And besides, Makefiles often call out to external scripts anyway - it's the Unix Philosophy!)

[benlesh]

@jesstelford

"(I'm assuming most decent developers know Make already)."

You assume wrong. The majority of developers, particularly web developers, either don't have a build process or have their build processes handed to them by IDEs like Visual Studio. More importantly, they have absolutely no reason to know what a make file is, let alone how to write one. That doesn't make them bad developers.

I see nothing wrong with Make, and I applaud the spirit of the suggestion, people are too happy for shiny things. But using Make with JavaScript projects is more "flavor of the month" (ala hipster) than anything else these days. It's pretty rare to see a JS project using Make, in my experience. If you're looking for "tried and true" in JavaScript-land, Grunt or simple npm run scripts are most likely your gotos.

[jesstelford]

@blesh Thanks for calling me on that statement. I have a bias toward Make since I come from a C/C++ background.

have their build processes handed to them by IDEs like Visual Studio.

Even more reason for using Makefiles; VS has a Makefile Project Wizard built in, whereas the others require a plugin to be runable from within that IDE.

Although, but implying the majority of web developers use VS disregards the large numbers of devs who work in *nix environments (Linux, OSX, etc).

It's pretty rare to see a JS project using Make

I was curious, so I did some basic searching on Github;

• 99,548 references to .js inside a Makefile
• 436,468 references to grunt in either grunt.js or gruntfile.js
• 72,380 references to gulp in either gulp.js or gulpfile.js

If my search-fu is correct (it probably isn't), it shows Grunt as by far and away the most popular build tool for Javascript, but Make still comes in before Gulp.

[ericelliott]

Make has been around for decades and is still in constant use. There is a TON of tooling for make. Most IDEs either know how to assist you with make files, or have plugins that do. It's true that few JavaScript projects use it, but some do, and it may be worthwhile to encourage Make to spread in the JavaScript ecosystem.

Contrast with Grunt, Gulp and Brocolli, the only one with a large ecosystem is Grunt, and it's quickly going out of fashion. Gulp and Brocolli are new things to learn for most JS developers. As long as you have to learn something new, shouldn't you have some assurance that it will still be useful in 2017?

I think make and npm are the only safe bets available today...

That said, make is something new to learn for many JavaScript developers.

Maybe we should stick with npm as the standard for minimal projects, and generate a makefile with our scaffolding. That way, digging into make is opt-in, and developers who don't want to can use simple commands like npm run build.

Thoughts?

[getify]

Just gonna leave this here: https://gist.github.com/substack/8313379

[cswenor]

My vote is for Gulp. It is something new to learn, but it is very intuitive. A Gulp File is very easy to read an understand what is going on. I have to agree with @clohr that you have to do research to find the good plugins/scripts because the community is still small.

I do like the sound of make though. I personally never considered using it with JS. I'm going to have to look at a few examples.

[jesstelford]

@ericelliott

make is something new to learn

Arguably, so is Grunt, Gulp, etc - their syntax can be (almost) as opaque as make at times. I whole heartedly agree with it may be worthwhile to encourage Make to spread in the JavaScript ecosystem.

generate a makefile with our scaffolding

Now you're talking about implementing autoconf / cmake. I'm not so sure that's a good route to go down (it's the equivalent of implementing a gruntfile-builder package that autogenerates your gruntfile.js based on gruntfilelists.txt :P)

It's always possible to alias npm tasks to make targets:

// package.json
{
  "scripts": {
    "build": "make build"
  }
}

That way, it feels familiar to a JS user who might not have seen make before, but doesn't otherwise care about what make / Makefiles actually are.

@cswenor

Check out Building javascript projects with make for a great intro ;)

[cswenor]

One thought I have about using make is that it is a new language.

If I imagine myself giving a Junior Developer that has started learning with JavaScript and they see this and see it is a completely different syntax they might be spooked a bit.

Just a thought.

[getify]

I think we may be missing an important point... build processes are not necessarily appropriate for beginning developers to be _task_ed (pun intended) with writing. Build processes are more a "devops" thing than a "junior javascript developer just joing the team" kind of thing.

That's not to be elitist and say that non-devops devs shouldn't be able to understand and even help manage these things. I'm just saying in the spectrum of important influences on choice of build systems, I wouldn't say "immediate familiarity to a junior dev" is high on my list.

[jesstelford]

@getify

I wouldn't say "immediate familiarity to a junior dev" is high on my list.

The caveat to that is; We may encounter non-junior / intermediate / senior JS devs who have never used Make before, but want to use the cloverfield project (in a way which requires altering the build system). In that case, I'd argue that forcing them to use/learn Make is a good thing, but it's almost guaranteed to turn some people off. The same way that using Grunt over Gulp might turn some people off, etc.

[getify]

I'd say "ability to use/execute the build system" and "ability to configure/customize/write the build system components" are two separate and almost orthagonal concerns.

From my limited perspective, it seems the former is more what's at concern here with sentiments like "almost guaranteed to turn some people off". So I think the more important question there is what is the interface to the system, and how accessible is it to those with less experience. I can't imagine npm can be beaten in that respect.

What it runs on under the covers should be debated separately, and the focus should be IMO less on "ease of familiarity" and more on "right fit". I linked to "task.js" earlier because for me, writing JS code to build my JS code is the most natural fit. If you're at a PHP shop, though, I bet PHP is the more natural fit. Same with a perl shop.

I personally don't feel like make is a natural fit in such environments, but I also wouldn't turn to bash scripting (anymore, now that I have node) so I recognize if you're purely coming from the sysadmin/devops PoV make and bash are pretty natural.

[jesstelford]

Well thought out and articulate points!

As I said earlier, I have a C/C++ background which gives me a favourable bias towards make, to an extent that I still haven't bothered learning Grunt / Gulp / etc, as I am yet to see a benefit for me. For others, I can see how keeping it JS would be beneficial.

[cswenor]

I agree that JavaScript feels like a more natural fit. So whatever is selected should be JS.

[ericelliott]

I think we may be missing an important point... build processes are not necessarily appropriate for beginning developers to be tasked (pun intended) with writing. Build processes are more a "devops" thing than a "junior javascript developer just joing the team" kind of thing.

:+1:

Yep. Let's clarify what our typical build system is trying to achieve:

• Simple dev command that watches files for changes, then rebuilds only what needs to be rebuilt
• Example that transpiles from ES6 or CoffeScript, configurable to do so with or without sourcemaps
• Build CSS system with sprite generator
• Lint on build and display results in that dev command console output
• Run smoke tests on change
• Full build command that kicks off cross-platform testing (e.g. Sauce Labs cloud testing)
• Am I missing anything?

What we really need is TodoMVC for build systems

Let's actually set up builds using the top contenders. Let's pick the Backbone TodoMVC source (we're not actually building an app here, this is an arbitrary, meaningless selection, no bikeshedding) and whip up the contenders.

If you care about build system x, write a TodoMVC build with x and link to it here.

To make the timing meaningful, we should try to use all the same tech in all the contender build systems. These are arbitrary tech selections -- these do not reflect the tech we'll promote in Cloverfield. No bikeshedding about this stuff here, please. =)

• ESLint with these rules (change the rules if it doesn't pass, not the JavaScript source.)
• Concat JS and compress with Uglify
• Run the CSS through node-sass
• Run a couple tests with tape

Since we're JavaScript guys, we can kick off the build process and time the results using JavaScript. We can worry about the exact timing code when we have a couple builds to compare.

Criteria for judging:

• Build times with an emphasis on repeat builds - the longer it takes to build during the dev process, the less productive developers are
• Ease of use after the build system has been set up - this includes simple maintenance of the build config, e.g., how hard is it to add a task?

Note also, this isn't a spec race. We're all going to weigh in with our opinions, which are informed by the somewhat-objective results.

The fastest build is not an automatic winner, but it will help if we have some data backing our opinions up.

Let's get building. =)

[ericelliott]

Now you're talking about implementing autoconf / cmake. I'm not so sure that's a good route to go down (it's the equivalent of implementing a gruntfile-builder package that autogenerates your gruntfile.js based on gruntfilelists.txt :P)

Nope, I'm talking about running a single command to, for instance, add a CSS sprite compiler to the build, rather than choosing the tech, downloading the libs, and adding to the makefile manually.

[ericelliott]

I think the more important question there is what is the interface to the system, and how accessible is it to those with less experience.

Absolutely agreed. :+1:

[heltonvalentini]

I think we should keep it simple. Use npm as the standar for minimal projects and generate a bash script with #!/usr/bin/env node so we can write JS bash as shown here https://gist.github.com/substack/8313379

[ericelliott]

I agree that JavaScript feels like a more natural fit. So whatever is selected should be JS.

One thing I love about npm is that anything can be an npm task, and as long as it reads from stdin and writes to stdout, it's easy to pipe tasks together without slowing things down. For me, that stdin->stdout composability of tasks is a worthy consideration. That pretty much rules out grunt. Gulp kindof does that with the streaming API if people write their streaming code properly...

[ericelliott]

I think we should keep it simple. Use npm as the standar for minimal projects and generate a bash script with #!/usr/bin/env node so we can write JS bash as shown here https://gist.github.com/substack/8313379

This is totally doable. I LOLed at Substack's task.js. I think what's less important than the tools is that we support a high-quality workflow for developers.

• There should be a dev mode that watches files and rebuilds when needed
• In dev mode, syntax problems and any critical unit test breakages should alert the developer with clear errors
• It should be trivial to kick off a full build and run the full test suite
• What else?

[ericelliott]

Note, this is pretty basic stuff that just about every task runner should have lots of clear examples for. I'm totally cool with npm, and I don't think we'd get much backlash if we make that the standard, as long as the npm examples exit with an error status for continuous integration...

[benlesh]

There's a larger problem at play here in my mind:

There are two camps:

1. Ivory Tower JS Developers - These are people that are completely out of touch with the mass majority of JS hackery going on in the world (see 2). They always use task runners, they set up builds, they use Travis CI, and they consider it all "easy" and "second nature". They live and work in bubble environments with others who are experts in their own right, and frequently discuss things like Make, Rake, JSLint, Istanbul, etc, with like-minded peers. Some of them don't even consider themselves to be in an Ivory Tower and wonder how everyone else is missing out on what they already know and have accepted as common place.
2. Common JS Developers - These aren't "Junior Developers", at least in title. These are people who might even be extremely skilled developers in other languages, who generally view the web as "another UI". Or maybe they're people who started off with JS because they wanted to add some piece of functionality to a website they were making pretty for some small midwestern company. Sometimes they were the guy tasked with maintaining a website for a few years, and now they're being asked (6 years too late) to make the company website "more Web 2.0". Maybe they're someone who just never had the good fortune of being exposed to newer technologies, so they're maintaining an old ASP Classic or PHP app, and now they have bigger aspirations. Either way, this developer probably has never heard of Make, Grunt, Gulp, Rake, etc, or possibly even Node. They're interested in improving the tooling around their growing JavaScript work load, but have no idea that they can set up builds.

The problem is that for people in category No. 2 above, the concepts and learning curves for all available technologies are daunting to say the least. They probably don't have access to mentors or even know were to look.

So to what @getify was saying earlier that "Junior devs shouldn't be setting up builds" (paraphrasing), I'd say "that's only because it's so hard right now that they can't". Proof: A junior dev can build and deploy a C# project with the click of a mouse in Visual Studio.

Furthermore, because they "shouldn't" doesn't mean they aren't going to try. And if they're going to try, it should be easy for them.

Now I'm not saying the JS world should strive for "click to deploy". But I am saying that the available tooling isn't approachable or ergonomic enough, and that's why a "Junior Dev" can't be trusted with it. Not necessarily because the core concepts are hard.

Personally, I think the work that @stefanpenner has done with Ember-CLI (built atop BroccoliJS) is absolute genius, and the larger JS community should strive to build upon that idea.

What I think is a bad idea is getting all neckbeard about "what people should be using because it's the old way and it's 'established'". The old ways are good, and we should remember them, but they're not progress, and it's the inadequacies of the old ways that gave birth to all of these new task runners. If Make were perfect, Rake wouldn't exist. If Rake were perfect, Grunt wouldn't exist. Grunt, Gulp; Gulp, Broccoli. And so on.

[heltonvalentini]

• There should be a dev mode that watches files and rebuilds when needed
• In dev mode, syntax problems and any critical unit test breakages should alert the developer with clear errors
• It should be trivial to kick off a full build and run the full test suite
• What else?

I think that all these tasks are better explained here: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/

[benlesh]

In closing, I'd like to offer exactly zero solutions to the problems I've presented.

（╯°□°）╯︵ 🎤

[jesstelford]

@ericelliott

Great idea - I'll see what I can do to put together a make example (although I do have to say; make's power really comes into play when there are a lot of files that need expensive compilation steps due to its intelligence in avoiding recompilation of untouched files).

@heltonvalentini

That's an excellent post, thanks for linking it - it even opened my eyes to some things I didn't know npm's task runner could do :)

@blesh

what people should be using because it's the old way and it's 'established'". The old ways are good, and we should remember them, but they're not progress, and it's the inadequacies of the old ways that gave birth to all of these new task runners.

I dispute the claim grunt, et al came about because of deficiencies in make. Can you point out what it is that Grunt / Gulp / etc can do that make can't?

I would rephrase what you said to be:

The old ways are good, and we should remember them because they have already solved the problem, and it's the inadequacies of the these new task runners which make that so obvious.

[ericelliott]

I think that all these tasks are better explained here: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/

Yep. I'm aware of that. What Cloverfield will be is something that takes most of the work and hard choices out of that. Things like which test suite should we use? Well, that kinda depends on your framework choice, right? For instance, I think if you're using Meteor, you really only have one choice that integrates well with meteor, but shouldn't $ cf test install and scaffold the right test tools for you?

This implies that Cloverfield should support multiple frameworks, and that the framework selection you make will have an impact on what Cloverfield does.

Before any of you go crazy investing a lot of time in this, let me make it clear:

Cloverfield is about supporting the future, not the framework of the minute. If you're happy with ember-cli, continue to use ember-cli and ignore this project.

When you eventually realize that the web is eating all software because it's built on standards that have lasted the test of time, we'll welcome you back, and hopefully, somebody will have extended Cloverfield with some pretty nice Ember 6.0 support.

Brace for it: That means I don't give a crap about supporting today's Angular custom element directives. They're getting shot in the head by Angular's team next year.

...But I do consider it important to think about how we might scaffold web components such that they're easy to use with Angular, or React, or Meteor.

=)

[jesstelford]

@blesh

this developer probably has never heard of Make, Grunt, Gulp, Rake, etc, or possibly even Node. They're interested in improving the tooling around their growing JavaScript work load, but have no idea that they can set up builds. "that's only because it's so hard right now that they can't" available tooling isn't approachable or ergonomic enough Not necessarily because the core concepts are hard.

The thing is, they are hard. And we make them hard as a conscious choice. Technically, the only think you need to run a javascript project is node index.js.

It's us as the developers who are looking for more advanced options / features that don't exist by default who decide to add an extra tool or two or twenty. It's about the trade offs we make there - more complexity at build time for (possibly) better developer productivity during coding time, and (possibly) better performance at run time.

A junior dev / someone new to JS would not be making those choices because they shouldn't need to. It's only when they get sufficiently advanced enough that they should be doing it. At that point, it's reasonable to assume they're able to learn another tool chain (Gulp / Grunt / Makefiles / etc), and that the tool they learn will be the one they stick with. This goes back to @ericelliott's implication that cloverfield will eventually influence what a new JS dev learns as the 'standard' tool.

Proof: A junior dev can build and deploy a C# project with the click of a mouse in Visual Studio.

Counter-proof: A junior dev can run a javascript application by running node index.js

[jesstelford]

@ericelliott

Cloverfield is about supporting the future, not the framework of the minute. If you're happy with ember-cli, continue to use ember-cli and ignore this project.

In that case, I put forward Makefiles once again. It has withstood the test of time, and is usable with every "modern" framework of the minute, and will continue to be usable with whatever new frameworks come out in the future. npm, Grunt, Gulp, etc, are still all young, may change, and may go the way of angular directives. Make will not.

[ericelliott]

npm is young compared to make, but it's been around almost since the beginning of Node, and it's the gateway to the single largest module repository in the world with the most active developer ecosystem in the world. I think it's a fair bet that npm and npm run will still be around and popular 3 years from now.

Of course, those npm scripts could just be calling make commands, and I'm happy to go that route if that's the concensus the Cloverfield community reaches. I'm eagerly looking forward to your TodoMVC build with Make. =)

I do think that even if we go with make, npm run could still be the standard way for developers to run the build scripts.

[ericelliott]

My version of old vs young:

The old ways are good, and we should remember them, because they have already solved the problem. The young ways are good, and we would not have progress without them, but new tools do not guarantee progress; they sometimes even revert the progress that old ways have already made.

[robertdmunn]

I use Grunt because of its relative maturity, large plugin ecosystem, and broad scope as a task runner. Broccoli looks interesting. The partial re-build feature is something good that there is no easy way to replicate in Grunt.

I agree that the npm task runner is good as a starting point, but I don't know how easily I could duplicate my Grunt config for a complex project using npm run, and I don't know how it solves the partial re-build problem.

I like Make. Will Windows users be less inclined to use the platform with make as the build tool, and if so, is that an important factor in the decision?

[jesstelford]

I have put together an example using make. From the docs:

Getting Started

git clone https://github.com/jesstelford/cloverfield-build-make.git && cd cloverfield-build-make
npm install

Build process

To run the build process

make <target>

Available make targets can be seen in Makefile;

all   - alias for make lint build test
build - alias for make css js
js    - concat + compress js files
css   - convert scss to css
lint  - use eslint to check correctness of js files
test  - run tape tests as present in test/ dir
clean - clean up after previously run build targets

Note that the css target really doesn't do anything - it is a contrived example for this repo and merely results in copying an existing .css file to another location (it was never Sass to begin with!)

npm run aliases

I have aliased a couple of the commands in package.json as runnable scripts. This is done as an example showing how make and npm can live in harmony.

npm run build-all   # alias for make lint build test
npm run build-clean # alias for make clean

[benlesh]

@jesstelford

Can you point out what it is that Grunt / Gulp / etc can do that make can't?

They can be written in JavaScript and require no knew syntax knowledge, and should be pretty seamless for any developer with Node experience to acclimate themselves to. Make, will never be able to claim those things. It may as well be Rake in comparison. Great tool, wrong language.

@ericelliott

Cloverfield is about supporting the future, not the framework of the minute. If you're happy with ember-cli, continue to use ember-cli and ignore this project.

I don't think you quite understand what I'm saying. **I'm not saying "Make Cloverfield support XXX framework"**... I'm not stupid. I'm saying "Make it easy as hell for me to build anything, including my framework, or my framework support libraries, or my crappy tictactoe widget, or my FRP fizzbuzz app, with Cloverfield". FWIW: I build _non-Ember_ things all of the time with Ember-CLI. **RSVP.js is built with Ember-CLI.** It's just an abstraction on top of BroccoliJS, but it provides some nice features for development and builds. It could be a lot better though. ## The reason I brought up Ember-CLI has nothing to do with Ember It represents a first-of-its-kind effort to add good tooling around development workflows and builds. It's just a shame it's not generic enough to suit more needs. I'd presume that's what this effort is. If you really want me to "ignore this project", make a JavaScript build process that runs in some other language. Something like that would have to be beyond amazing, feature wise, just to garner my attention. If we were talking about Ruby or C#, I'd want my build setup to be done in those languages. Otherwise it's just shitty ergonomics. Expecting X language developers to know Y language to build X language is just yuck, even if it's "not hard" and "it's been around forever so people should know it".

[ericelliott]

Make, will never be able to claim those things.

It might if we provide great tools to generate the make config.

"Make it easy as hell for me to build anything, including my framework, or my framework support libraries, or my crappy tictactoe widget, or my FRP fizzbuzz app, with Cloverfield".

Yep. We're on the same page here.

FWIW: I build non-Ember things all of the time with Ember-CLI. RSVP.js is built with Ember-CLI. It's just an abstraction on top of BroccoliJS, but it provides some nice features for development and builds. It could be a lot better though.

What are your favorite things about it that we should definitely do?

What should we definitely do differently?

Expecting X language developers to know Y language to build X language is just yuck, even if it's "not hard" and "it's been around forever so people should know it".

I agree. We're not gonna do that. Even if we decide to use Make under the covers.

So, Ben, what does your ideal build system look like? Do we get to see your TodoMVC contribution next?

[ericelliott]

@jesstelford Thanks!

Where's the watch task? (aka interactive dev mode) =)

[benlesh]

What are your favorite things about it that we should definitely do?

From a building non-Ember standpoint, the biggest thing is it adds a little on top of BroccoliJS to automatically clear out directories. Because of broccoli it includes a local development server with automatic refreshing if watched files are updated.

From a building Ember applications standpoint, it provides paths to initialize an project, update/upgrade an existing project. It sets up Broccoli to build, run tests, development watch, etc. Because of this, it's infinitely easier to set up an Ember project.

What I wish it would do is be generic enough to step me through some questions to set up any type of project. A basic JS library, an Ember app, an Angular app, a XXX framework whatever-majig. I wish it would ask me things like:

1. Do you want to use ES5, ESNext, Traceur, CoffeeScript, ___?
2. Is this geared for the browser, Node, mobile, or any combnation of those?
3. Do you want to add unit tests?
4. What testing framework do you want to use?
5. Do you want to add code coverage?
6. Do you want to initialize a Git repo?
7. Do you want to add CI support? If so, Travis? Jenkins?
8. What OSs will this build run on?
9. Do you want to add development watches?
10. What browsers do you want to run tests in?

Let's pretend you can ask a series of questions from some CLI like that and generate an easy-to-grok .JS configuration file (Brocfile, Grunt, Gulp, Custom, whatever).

Alternate functionality I'd love to see in a tool like this would be the ability to from a CLI tool say "upgrade this npm/bower dependency in another branch and run the tests and give me the results".

There's a real PITA workflow around updating dependencies in JavaScript projects at times. And that would be a "nice to have", but definitely not a requirement.

[benlesh]

On a related note, @igorminar from the Angular team is just beginning a similar CLI effort. It might be a good time to compare notes, and possibly work together. If something generic could be put together that also meets the needs of their CLI efforts, there's probably a huge value to other similar communities as well. What's involved with setting up an Angular project build today is really no different than setting up any other JS project build.

I would be sure to talk to @stefanpenner and @igorminar about all of this because it's certainly related to existing projects and efforts and I think the JS community to use some real unity around these sorts of tools.

[ericelliott]

From a building non-Ember standpoint, the biggest thing is it adds a little on top of BroccoliJS to automatically clear out directories. Because of broccoli it includes a local development server with automatic refreshing if watched files are updated.

This sounds like a clean task and a watch task. We'll definitely have those. Am I reading this correctly?

From a building Ember applications standpoint, it provides paths to initialize an project, update/upgrade an existing project. It sets up Broccoli to build, run tests, development watch, etc. Because of this, it's infinitely easier to set up an Ember project.

Sounds a lot like what I envision for Cloverfield.

What I wish it would do is be generic enough to step me through some questions to set up any type of project. A basic JS library, an Ember app, an Angular app, a XXX framework whatever-majig. I wish it would ask me things like: [insert list here]

Yep, Cloverfield will have commands for many of those things. If you leave off any commands, it will ask you questions to figure out what you want to do, and tell you what command you'll use to make it happen next time -- so you can start using cf with zero knowledge of how cf works, and gradually learn how to use it faster if you want to skip the Q&A.

Alternate functionality I'd love to see in a tool like this would be the ability to from a CLI tool say "upgrade this npm/bower dependency in another branch and run the tests and give me the results".

That's brilliant. I'd love that, too.

Thanks for the tips. I'll ping them both and see if they'd like to weigh in...

[jesstelford]

@blesh

I wish it would ask me things like:

1. Do you want to use [...]

ability to from a CLI tool say "upgrade this npm/bower dependency in another branch and run the tests and give me the results".

Great ideas - a new-project / beginner friendly tool like that would rock!

@ericelliott

I'll add those targets to the Makefile (thanks for creating jesstelford/cloverfield-build-make#1)

[benlesh]

I think this is a really exciting concept. Thank you so much for letting me be a part of the conversation.

[stefanpenner]

So one clarification, Broccoli isn't a task runner, rather a tool focused to be a build-pipeline and only a build-pipeline.

I have had good experience with broccoli, it continues to improve and evolve nicely. Even works relatively well on windows machines. Although it can still be improved, it feels like the right of abstraction

Broccoli basically lets you describe operations on trees of files.

• filter the tree
• move tree
• move files in the tree
• rename files in the tree
• transform files in the tree (delegating to something like 6to5)
• combine the trees
• remove files in the tree
• log a tree
• debug a tree

But figures our the how for you.

I have written broccoli-stew which tries to give you unix inspired broccoli helpers. I found these nice and improved my productivity. The example bellow uses them.

As it turns out, broccoli's best selling feature for me (beyond accurate fast builds) is that is embeds nicely in other tools. Although it has its own cli, sometimes you want to integrate it into existing tooling. Want your own CLI? Like the npm script approach? etc. etc.

So a quick example, given the following brocfile (exurbs from rsvp.js):

// find the trees of files you care about
var lib = find('lib');
var testDir = find('test');

// globs work
var testFiles = find('test/{index.html,worker.js}');

// find specific files and move them
var json3 = mv(find('node_modules/json3/lib/{json3.js}'), 'node_modules/json3/lib/', 'test/');
var mocha = mv(find('node_modules/mocha/mocha.{js,css}'), 'node_modules/mocha/',    'test/');

// combine two trees
var testVendor = merge([ json3, mocha ]);

// compile all es6 modules in this tree, (further filter to make sure we only get js files)
var rsvp = compileModules(find(lib, '**/*,s'));

// exclude source maps (just because)
dist = find(dist, '!*.map');

// combine and create a unified tree (that is the final output)
module.exports = merge([
  map(dist, function(content) { return license + content; }), // pre-pend license
  testFiles,
  testVendor,
  mv(dist, 'test'),
  mv(testBundle, 'test')
]);

the following is used to build it (if you are embedding and not using broccoli-cli)

var broccoli = require('broccoli');
builder = new broccoli.Builder(require('path/to/above/example');
builder.build();
builder.cleanup(); // when you are done;

wanna hook it up to some file-watcher?

watcher.on('change', function() {
  builder.build();
});

// the builder also informs us of when new roots need to be watched, so we can inform the watcher accordingly

Obviously if you want the turn-key solution, the broccoli-cli does the later under the hood already for you. and broccoli does its best to figure out the most efficient way to build and re-build.

But if your like me, I like to know how to hack things if I need to and when i don't i like that they "just work".

[stefanpenner]

I think their is lots more fun and learning in this space. If anyone has thoughts/concerns/ideas don't hesitate to reach out.

[ericelliott]

Stefan,

Would you be interested in writing the TodoMVC build system implementation for Broccoli?

On Tue, Jan 6, 2015, 4:12 PM Stefan Penner notifications@github.com wrote:

So one clarification, Broccoli isn't a task runner, rather a tool focused to be a build-pipeline and only a build-pipeline.

I have had good experience with broccoli, it continues to improve and evolve nicely. Even works relatively well on windows machines. Although it can still be improved, it feels like the right of abstraction

Broccoli basically operates on trees of files.

• filter the tree
• move tree
• move files in the tree
• rename files in the tree
• transform files in the tree (delegating to something like 6to5)
• combine the trees
• remove files in the tree
• log a tree
• debug a tree

I have written broccoli-stew https://github.com/stefanpenner/broccoli-stew which tries to give you unix inspired broccoli helpers.

As it turns out, broccoli's best selling feature for me (beyond accurate fast builds) is that is embeds nicely in other tools. Although it has its own cli, sometimes you want to integrate it into existing tooling. Want your own CLI? Like the npm script approach? etc. etc.

So a quick example, given the following brocfile (exurbs from rsvp.js):

// find the trees of files you care aboutvar lib = find('lib');var testDir = find('test'); // globs workvar testFiles = find('test/{index.html,worker.js}'); // find specific files and move themvar json3 = mv(find('node_modules/json3/lib/{json3.js}'), 'node_modules/json3/lib/', 'test/');var mocha = mv(find('node_modules/mocha/mocha.{js,css}'), 'nodemodules/mocha/', 'test/'); // combine two treesvar testVendor = merge([ json3, mocha ]); // compile all es6 modules in this tree, (further filter to make sure we only get js files)var rsvp = compileModules(find(lib, '*/_,s')); // exclude source maps (just because) dist = find(dist, '!*.map'); // combine and create a unified tree (that is the final output)module.exports = merge([ map(dist, function(content) { return license + content; }), // pre-pend license testFiles, testVendor, mv(dist, 'test'), mv(testBundle, 'test') ]);

the following is used to build it (if you are embedding and not using broccoli-cli)

var broccoli = require('broccoli'); builder = new broccoli.Builder(require('path/to/above/example'); builder.build(); builder.cleanup(); // when you are done;

wanna hook it up to some file-watcher?

watcher.on('change', function() { builder.build(); }); // the builder also informs us of when new roots need to be watched, so we can inform the watcher accordingly

Obviously if you want the turn-key solution, the broccoli-cli does the later under the hood already for you. and broccoli does its best to figure out the most efficient way to build and re-build.

— Reply to this email directly or view it on GitHub https://github.com/ericelliott/cloverfield/issues/2#issuecomment-68952070 .

[stefanpenner]

sure why not, email me at stefan.penner@gmail.com with the details.

[jesstelford]

@ericelliott

Where's the watch task? (aka interactive dev mode) =)

I have added a watch-build target to the Makefile example, as outlined in jesstelford/cloverfield-build-make#1:

make watch-build

Will use the npm watch package, and spin off two processes (one watching js changes, the other watching css changes), which can be terminated with Ctrl-C.

[ericelliott]

@jesstelford I'm not sure why, but I can't seem to get make watch-build to actually rebuild anything. Check the open issues. =)

[Flet]

Hey @ericelliot I think the idea of comparing task runners in the same way todomvc compares frameworks is an awesome idea. It would be enlightening even beyond the scope of this project.

I think it is worthy of its own repo, so if you don't start one I will. :) It would be nice to have a basic set of files to "build" and a clear set of tasks to accomplish. With some clever requirements, it could also measure some interesting metrics for each approach (number of required dependencies, timings, etc).

[jesstelford]

@Flet / @ericelliott

I have created a "base" project which can be forked, and have the build tool added easily. This is what I used to build my make version, with all the make-specific stuff removed:

https://github.com/jesstelford/cloverfield-build-todomvc