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?

[ericelliott]

I've created TodoTasks for this purpose.

[ericelliott]

@jesstelford Can you open a TodoTasks PR with your base project?

[jesstelford]

:+1: Open: https://github.com/ericelliott/todotasks/pull/1

[ericelliott]

Refer to the sample project, todotasks.

@jesstelford, could you help us clean up the repo and make it conform more to this suggested spec?

[AWaselnuk]

Not a complete answer to your questions @ericelliott but as someone who has gone through the build tool learning process recently (within the last year):

Make - I found learning Rake easy and intuitive. I'm sure Make would be just as nice to work with. Gulp - Seemed cool at first but cryptic errors from the Node ecosystem turned me off. Grunt - Definitely easy to learn and work with but I could see myself sometimes wanting the granularity and speed of something Gulp. NPM - The moment I heard about npm run I tried it out and was immediately successful. It was very easy as I could lean on my existing experience with bash and node. Brocolli - Haven't tried it.

[ericelliott]

Thanks Adam! Your perspective is very helpful. =)

[ralphtheninja]

I like the idea of ./task.js. Keeping it in javascript makes for portable tasks. I also like using code as configuration instead of mega large and confusing .json configuration blobs (grunt).

[ericelliott]

The problem with ./task.js is that every developer will have their own way of doing things. In order to encourage an ecosystem of best practices to flourish, it's necessary to establish some baseline standards.

Keep in mind that while Substack is a brilliant developer, he spends a whole lot of time building little one off, self contained, isolated modules (which is very good!). The purpose of this project is to ease the process of building complete applications. When you're working on a team (or for larger orgs, teams of teams!), it's really hard to keep everybody on the same page. If there's a prescribed way of doing things, that saves t * dn time where t = time and dn = number of developers on the team.

In other words, having no standards means that a lot of devs are wasting a lot of time reinventing the wheel. =) That's the problem that Cloverfield hopes to be able to solve for all application developers who decide to use it.

[elrasguno]

While I'm quite late to the party, I just wanted to throw in a vote for NPM. I'm working on a games platform that's all Node -- and only back end services -- so that obviates Grunt, and we're managing the majority of the work that we'd otherwise use Gulp for with Jenkins instead. NPM's "scripts" and "bin" facilities (via package.json) allow us to do anything we need a module to do to install, run, test, and clean up after itself.

To @blesh's point about there being two types of developers, I can hang with the best of JS experts that know the value of continuous integration and rabid testing and automation, but I'm also prepared, if necessary, to accept that JavaScript may not always be the best tool for a job. If that were the case for a given module, my second choice would immediately be make, because it can actually do all of the things that these other tools have been built to do. It just happens to be the case that most people don't like reading man pages to learn how to use things.

And then I read Building JavaScript Projects with Make, and I was like ... "uh, yeah, I can do that, too!"

[ericelliott]

@elrasguno Rock on. I love the feedback. I'm really liking the npm run option, and make sounds like a great backup plan for developers who want to dig deeper. :+1:

[ericelliott]

@jesstelford I just looked at your test.js and LOLed.

[ericelliott]

I have some open PRs in the todotests repo if anybody would like to review them, in order, please! =)

1. Cleaning up the base implementation example
2. Adding an npm example with build script

Note that in the npm example, the source gets compiled with Browserify and minified with working sourcemaps. It would be great if other build system examples could do the same.

[ericelliott]

@vivainio raised an interesting point in the existing scaffolding tools thread.

Gulp is fine on windows, make and 'npm run' are a no-go there.

It's true that both npm run and make both encourage more reliance on the operating system, and a whole ecosystem of tooling that may or may not be available in a Windows environment, whereas you're more likely to rely on cross-platform JS implementations using tools like Gulp and Broccoli.

Any thoughts on using npm run and make cross platform? Is this reason enough to avoid heavy reliance on these tools?

Does @jesstelford's make implementation of todotasks run on Windows? (I don't have a Windows box handy right now to test).

[ericelliott]

Interesting. @isaacs (of npm / node fame) just posted a makefile tutorial gist. Check it out!

[vivainio]

@ericelliott ...and just the kind of example that won't work on Windows.

[Cmdv]

Being new to the game, for me a good way to monitor/fish out errors in my code when I'm in development is very important so I can easily auto rebuild and possibly leave the file non minified so I can find where the issues are.

Nodemon is very handy but I'm sure there is other solutions out there but been a bit of a newby, I've not had the experience to play with them all.

[ericelliott]

@Cmdv Check out the npm implementation in the todotasks repository.

It watches files for changes and automatically lints, rebuilds, and reruns unit tests on file saves. The build produces sourcemaps so you can easily find the source of bugs with correct filenames and line numbers.

Ignore the actual code -- the important thing about that repo is the process. Type npm run dev and you'll fire up the interactive developer console where you'll see the automatic task output. Then make a change to a file in the js/ directory, save it, and watch what happens in the dev console.

All of these tools support processes like that. The thing that's interesting about the npm implementation is that I was able to reproduce that process in a tiny fraction of the lines of code I used to do the same thing with Grunt.

[mattdesl]

Something else worth considering, at least for the npm approach, is that there are a lot of tools that aim to reduce even the npm scripts boilerplate. Some tools I'm enjoying recently for frontend:

• wzrd for browserify + http-server
• budo or beefy for watchify + http-server + LiveReload
• standard for config-less style linting
• testling or smokestack for running TAP in a browser

So it's hard to say "this is how it would look with npm" since I probably would have done it really differently. :wink:

[ericelliott]

@mattdesl

I like the idea of mixing in wzrd or budo, assuming it's easy enough to integrate them into people's actual projects. They're a bit limited by default, but they're a great idea.

For the rest of my reply, see my comment in the tech selection thread.

[ericelliott]

Looks like we're going with npm scripts. Thanks for the lively discussions! =)

[ericelliott]

Hey everybody... I'd love your input on composable scaffolds. =)