middlewares to be async

[tunnckoCore]

Im working on tunnckoCore/benz, which i think is awesome.
Because lies on top of great libs - async-done, now-and-later and co. Allows you to pass async, callback, generator functions, passing context through them; returning and yielding promises, thunks streams; handles errors and completion of all of them.

You can look at the tests for now. Also want to mention that it is almost like bach, but bach dont have options and flexibility that i need and want. You cant pass context to all of the functions with it. With benz you can pass context and can pass result of one middleware to next if you want. Support running on parallel and on series. Just look the tests, please :)

I will try to implement also to accept sync functions. It is little bit more work cuz promises and streams looks like sync functions, so it is lil' bit tricky to determine which is stream, which is sync, which is promise. But I believe it is possible.

You can try benz now (v0.2.0) here in glob-fs instead of custom calling middlewares - its ready, just need more tests and docs that I will add today.

With the title i mean like this

var glob = require('glob-fs')()

glob.use(function notemp(file, next) {
  if (/temp/.test(file.path)) {
    file.exclude = true
  }
  next(null, file)
})

or to be possible through option like async: true?

[tunnckoCore]

actually, it would be easy to determine it is glob-fs File object. I can add to checks here, just check for "if object and if object.isDotdir and object.isDotfile and then wrap it in callback style function"

edit: hm, or not so easy.

[jonschlinkert]

I actually built it this way initially, but it works really well as just sync - easier to explain and maintain.

however, I agree with the underlying reason for the point you're making. I think there needs to be another check after emitting exclude and include to allow middlewares or listeners to change that decision.

fwiw, this lib is still very WIP. my guess is that it's about 50% away from the finish line. I've been using it in stuff, but only to help me figure out how to improve it... hopefully you're looking at it the same way...(?)

also, it's slow right now, but once we get to optimization we'll be able to speed it up substantially...

[tunnckoCore]

hopefully you're looking at it the same way...(?)

Im thinking that it should be just thin wrapper with fast defaults - custom readers, custom iterators. Are you thinking to expose custom readers and iterators?

my guess is that it's about 50% away from the finish line.

I dont think you should do so much, lol. For me it is almost done, except custom readers, iterators and improve middlewares.

see last two comments #2 (comment)

[jonschlinkert]

I dont think you should do so much, lol

Usually I tend to do everything in one lib until I get it right. then I break things out. it's just my preference. I guess I'm conservative and would rather make sure we have the right conventions first