This is fantaaaaaaaastic

Btw feel free to ditch the hyphens

Here's screenshot of npm run release:

And a screenshot of running build with a watcher trigger:

Btw feel free to ditch the hyphens

Since every team has their own naming conventions, I don't want to step on anybody's toes & rename them in a way that makes less sense for the more active contributors.

Also edited original post with a todo re: lint task.

Lastly, I know that ZEIT prefers async/await. So I can setup fly-esnext to allow for async task definitions.

It doesn't really add anything except for visual appeal...

export async function build(fly) {
  await fly.source('src/*.js')...
}

export default async function(fly) {
  await fly.start('build')
  await fly.watch('...')
}

I prefer async/await and hope fly supports it as default 😍

@nkzawa I was playing with this locally. It can definitely be done, but it's a matter of trading dependencies & speed for syntactical preferences.

My gut says that opting in to a plugin is the right choice.

@lukeed Is the speed issue because of transpilation ? I think it can be solved since native async/await would be introduced on Node soon, or by using https://github.com/leebyron/async-to-gen

@lukeed I'm also in favor of async/await. Generators feels like bit of a magic.

@nkzawa Fly is powered by Bluebird; more specifically, Bluebird's coroutine implementation. This is because it's consistently the fastest Promise/Promise-alternative there is, for now. It's also the most memory efficient -- I spent weeks testing over 40 libraries. It's the clear winner.

Right now, the current game plan is reevaluate all benchmarks once async is supported natively. If and only if the native implementation can contend with Bluebird's performance will I consider adopting a pure native approach.

Fly isn't meant to be a prime example of what can be done with Node built-ins. Admittedly, it'd be awesome! I love that about most ZEIT products. But the only way Fly can even be considered over Gulp or Grunt is if it's considerably & unequivocally faster.

That said, I had a fork with async-to-gen, but it applies its own wrapper around the native Promise class. Even after some tinkering, I could get it to write Promises with Bluebird.promise, at best, but those are still slower than Bluebird.coroutine. 😞

This is why I made fly-esnext. All it does is rewrite an async function into a generator function (behind the scenes) & then evaluates the "transpiled" flyfile. And since flyfile.js is the only point of contact from the User and Fly, that's the only thing that needs rewriting. The plugin hides all generators from the user (no more magic for @arunoda), but Fly still receives the generators it needs, then wraps 'em into coroutines.

We can continue this discussion at a later time (very interested in your feedbacks!) but installing fly-esnext for this PR is the quickest & simplest solution.

@lukeed nice.
Shall we use fly-esnext to this?
(I hope that's possible)

@arunoda You bet. I'll add it tomorrow. I've updated my todo list with fly-esnext as a new item.

@nkzawa Fly used to support async/await, mind you, that was before Babel 6. It was slow. So, we removed it prior to 1.0.

@arunoda Generators feels like bit of a magic.

Generators feel more lower level, if anything. While I do find async/await better looking than function* myself, introducing fly-esnext in a later PR seems more sensible.

Don't you agree @lukeed?

Would using fast-async change things somehow?

#851

@sedubois Unfortunately, no. You still suffer Babel's 350-600ms boot time, and the end result is still slower & less efficient. Bluebird is hands-down the fastest option.

Having the ability to write async/await tasks in Fly is not a problem, guys. This is what fly-esnext solves. It's already doable & with near-zero perf loss.

Sorry @jbucaran, missed your comment. I think we should just include fly-esnext in here. The guys here all want it & it's not our project anyway 😉 Plus, the performance is the same; there's only an increase in memory usage...but it's still lower than Gulp!

Rebased & forced update. PR now includes the async/await version. @arunoda @nkzawa @rauchg

Task names were also truncated; eg compile-lib --> lib, remove-strict-mode --> unrestrict. If it were my personal project, I'd just replace the hyphens with underscores. ¯_(ツ)_/¯

Stat improvements are the same.

PR is still failing because master fails; and this is still lacking a full bench task.

@lukeed it looks master's CI succeeds.

@nkzawa Ah, I just inspected. Did not realize that Next.js is testing Node 4.x...

Fly only supports >= 6 because 4 is dropping LTS in April.

@lukeed But we need to support Node 4 even after that due to legacy reasons.
Some people still might use it.

But anyway, we need to support it for at-least until April.

@rauchg If we could that's nice.
But in order to test them in travis, we need to build it on travis.

If not, we could change the travis build tool to handle Node versions manually.
Always, build in latest node and change the node version to do the test.

Up to you guys. Fly originally supported 4.x, but switched to 6.x at the last minute. All we got out of it was a couple spread operators & destructured assignments.

Yeah, I'll patch it. I like that rule too; just took a shortcut this time around.

cc @jbucaran, this was my hesitation for dropping support for 4.

@lukeed Right!

BTW which 4.x?

=4.6 would be best.

Is there something that could be affecting the runtime of NPM scripts? Travis is now throwing because of a "reserved word" (require). However, I just reproduced a simple project that only uses the Fly plugins here & the same error does not appear on 4.7.

Any ideas?

@lukeed Maybe problem with Travis caching. It seems like it not re-install modules.

@timneutkens Grabbed all of the latest~

Thanks 😄 Hopefully, one day, I can just drop Fly into native Node 8(?) & it'll just work. Crossing my fingers for massive boost in native Promise performance. 🤞

@lukeed found a small bug, the binaries are copied over to dist/bin the thing I'm seeing is that they lose the given rights they had (execution). Which breaks next.

@timneutkens Thanks! Fix incoming.

❤️

@timneutkens Should I delete the gulpfile.js in my next PR, or leave it for reference on that bench task?