Koa 2.0.0 #533

Open
jonathanong opened this Issue Oct 16, 2015 · 322 comments

Projects

None yet
@jonathanong
Member

Roadmap

We do not plan to release v2 as "stable" until async/await hits node.js. Requiring babel to run your server is just not good developer experience. I do this right now, and I run into a host of problems. Writing your middleware with just promises or with co() or Bluebird.coroutine() everywhere isn't a good experience either. The current way to write middleware is ideal until async/await is native.

You can track v8's progress on async functions here: https://bugs.chromium.org/p/v8/issues/detail?id=4483. After v8 implements async functions, it will take some time for that v8 version to hit stable (6 weeks i think, not sure), then more time for that v8 version to hit node stable (i believe they plan to release a major version every 6 months).

Thus, once async functions hit v8, we have between 2-7 months to release Koa v2 as stable, but it'll probably just take us a day since not much other than the middeware signature has changed.

Don't be scared to use Koa v2 Alpha right now, though. People are already using it in production, and we don't foresee any major changes until we mark it stable.

Changes

The new middleware signature is:

// uses async arrow functions
app.use(async (ctx, next) => {
  try {
    await next() // next is now a function
  } catch (err) {
    ctx.body = { message: err.message }
    ctx.status = err.status || 500
  }
})

app.use(async ctx => {
  const user = await User.getById(this.session.userid) // await instead of yield
  ctx.body = user // ctx instead of this
})

You don't have to use asynchronous functions - you just have to pass a function that returns a promise. A regular function that returns a promise works too!

We don't know how much performance difference there will be, nor do many of the maintainers really care. Koa is as minimal as a framework can be and will not be your app's bottleneck.

New Features

Hopefully, Koa v2 will not have any new features as new features can be added to v1 as well. The only new features that will be added to Koa v2 will be breaking changes. Some possible features are:

Features for HTTP2 support can still go into Koa v1. The only problem is that if it's not in require('http') or require('https'), we're not going to include it in Koa. node-spdy is probably going to be the code that is merged into node.js.

Middleware

All of the current stable versions of middleware should be targeting koa v1. If it doesn't, let us know and we'll fix it.

Middleware may have an "alpha" version of the koa v2 version. These should NOT be marked as stable. If they do not exist, let us know and we'll create an alpha version so you can try it with koa v2. Better yet, make a PR!

Upgrading Middleware

You will have to convert your generators to async functions with the new middleware signature:

app.use(async ctx => {
  const user = await Users.getById(this.session.user_id)
  ctx.body = { message: 'some message' }
})

Upgrading your middleware may be a pain in the ass. One migration path is to update them one-by-one.

  1. Wrap all your current middleware in koa-convert
  2. Test
  3. npm outdated to see which koa middleware is outdated
  4. Update one outdated middleware, remove using koa-convert
  5. Test
  6. Repeat steps 3-5 until you're done

We have plans to create a migration bot #625 to make this process slightly better.

Updating Your Code

You should start refactoring your code now to ease migrating to Koa v2:

  • Return promises everywhere!
  • Do not use yield*
  • Do not use yield {} or yield [].
    • Convert yield [] into yield Promise.all([])
    • Convert yield {} into yield Bluebird.props({})

You could also refactor your logic outside of Koa middleware functions. Create functions like function* someLogic(ctx) {} and call it in your middleware as const result = yield someLogic(this). Not using this will help migrations to the new middleware signature, which does not use this.

I currently use babel and use async functions + flow type outside of koa middleware. this will make my migration path in the future easier. I'm not sure if I plan to ever remove babel though since I really like flow type.

How You Can Help

  • Documentation - we need a lot!
  • Testing Koa v2 and its corresponding middleware
  • Help create the migration bot #625

Questions

  • Should we transpile w/ babel before we publish? It might make performance better as it transpiles down to ES5, which V8 is more optimized with. Anyone wanna try benchmarking it?
@jonathanong jonathanong added this to the 2.0.0 milestone Oct 16, 2015
@fengmk2
Member
fengmk2 commented Oct 16, 2015

Should let user to do that, not koa itself.

@tejasmanohar
Member

@fengmk2 Maybe I'm missing something, but I don't think making the user transpile through Babel here is an adequate solution... wouldn't that require the user to modify what's in node_modules/ (/ fork koa and add babel transpiling in prepublish etc)?

Should we transpile w/ babel before we publish? It might make performance better as it transpiles down to ES5, which V8 is more optimized with. Anyone wanna try benchmarking it?
I think we should transpile for more reasons than performance (though that is a potential one). We can play with even more features this way, and there are quite useful / nice features in Babel that are hidden behind --harmony-x flags or entirely non-existent in Node 4.x.x.

@jonathanong
Member

yeah you can't expect users to transpile any of their node modules

@tejasmanohar
Member

Agreed. Personally, I think we should use Babel. Then, we don't require Node 4.x.x+ either- we just require an ES6 engine to use Koa (not to install / require etc) @jonathanong. Maybe not everyone is using Node 4.x.x because apps using Koa don't have to use a Node version that has any ES6 natively if we transpile, right? They could just be transpiling with Babel (or something else) themselves?

Basically, I think we should allow the user to decide how they want to run their app using our module. If we ship it as is without transpiling, then the user must use Node 4.x.x, but if we transpile and ship, they can use that, Babel, or something else- no restrictions as long as their engine is ES5+ and their application somehow supports ES6 (since generators). That is giving the user options.

But either way, asking users to transpile the module itself if they don't want to use Node 4.x.x isn't really reasonable (asking them to transpile it, that is. just saying only node 4.x.x is suboptimal, imo, but still reasonable).

@yanickrochon

I personally don't transpile. I can see the benefit, but in most case it just adds overhead for only a little benefit (code readability... which most dev don't need anyhow).

As far as I'm concerned, the 2.0 version should just be 4.x+ compatible, period. Devs can just stick with the 1.x branch for their existing applications. Everything is just fine. One of my project is still using a 0.21.0 version, and I don't see any reason to upgrade it. I started this project back when Node 0.11 was released, been using the --harmony flag then, and still using it with Node 0.12.7 at the moment.

Bottom line is, I don't see why 2.0 should be BC. I sure don't have any problem with it.

@tj
Member
tj commented Oct 17, 2015

+1 for 4.x only. To me there's nothing overly compelling enough to really make anyone feel like they have to upgrade if they can't quite yet, just a signature change etc. If the perf thing proves out then maybe that'll be worth it, but still a little weird.

@travisjeffery
Member

+1 to 4.x only too. with koa < 1.x people had to run recent/certain versions of node to have generators and that worked out alright/didn't seem to be an issue there.

@chentsulin
Contributor

+1 for 4.x only. koa is significant project which using new coming features to achieve great develop experience, so it needs move forward to the next steps.

@tejasmanohar
Member

@chentsulin Babel vs Node 4.x.x isn't about being able to use new features or not.

@chentsulin
Contributor

@tejasmanohar but support only Node 4.x.x will encourage people to upgrade, not just stay on 0.12. support from 0.x to 4 always be a nightmare to project maintainers. (maybe just like IE 6 ~ 11?)

If I does not use koa one year ago, I will stay on 0.10 for a long time.

@yanickrochon

@tejasmanohar what @chentsulin said is not really related to the use of Babel or not, but more about if Koa should be BC or not. My take is that, it should not and people should move forward.

That being said and in regards to the use of a transpiler, I don't like all the features in Babel... This is my choice, my opinion. I also do not use any project which are coded in CoffeeScript either. I may be an extremist on this matter, but I really don't like to have dependencies I don't really need nor use in my project. (And I have seen bugs and bad implementations being produced by transpilers that could have been trivial to avoid otherwise.)

My problem with using a transpiler is that it is opiniated. As everyone agree to be Node 4.x+ for version 2.0, all necessary optimizations are already there without using any development flags or a transpiler. As for code readability is concerned, there's not much Babel can add on top of that. Koa is supposed to be lightweight anyway. I haven't seen any valuable objective arguments to justify such dependency.

@tejasmanohar
Member

Ah, I see. Yeah, I don't think Koa 2.0 needs to be BC either.

@felixfbecker
Contributor

+1 for Node 4.x requirement

@thelinuxlich

+1 for Node 4.x requirement!

@cesarandreu

+1 for Node 4.x requirement.

Koa only works on node.js anyway, right? So it's not like other engines are at a loss. Any Node 4.x is LTS, so I'd expect people to be able to upgrade sooner or later.

@mike-marcacci

I'm all for the node 4.x requirement, but I do have a note about babel compatibility:

I've been using the branch from #533 on a brand-new project over the past week, and I discovered that because it uses native, uncompiled es6, I had to be careful what babel transformers are used on my code. Just as one example, if the "es6.class" transformer is enabled (which isn't necessary in 4.x, but is nonetheless on by default) the Koa class can't be extended by babel-compiled code and throws compile-time errors.

This is really a babel issue if it's an issue at all, and I've opted to explicitly declare my transformations in my package.json to avoid it, but I'm sure others will encounter this use case.

These are my babel configs that work seamlessly with the latest Koa.

...
  "babel": {
    "whitelist": [
      "strict",
      "regenerator",
      "es6.modules",
      "es6.arrowFunctions",
      "es6.destructuring",
      "es6.spread",
      "es7.asyncFunctions"
    ]
  }
...
@yanickrochon

How is Babel currently being used in Koa? Why is it listed as a devDependency?

@tejasmanohar
Member

@yanickrochon I assume it's listed as a dev dependency because you need it (or another transpiler of sorts) to develop on the experimental portion with ES7 async functions and all that jazz. 🎶

That said, doesn't look like it's actually being used to transpile anything in the scripts etc but rather only in usage by a developer. Maybe @jonathanong can shed some light here?

@jonathanong
Member

oh yeah it was part of the experimental tests. i removed the tests in the async-function branch but not babel yet.

@jonathanong
Member

also, i'm not changing the stance on the node 4.x compatibility. i just know people care about performance and the usage of es6 features slows performance (due to VM not optimizing yet). using babel to transpile to ES5 may improve performance (as well as being very easy), but i would want to benchmark that before doing that.

@yanickrochon

Dev for 2.0 doesn't have to have an RC just yet and may as well be a proof of concept. Angular 2.0 has been in alpha for ages... lol... so Koa 2.0 doesn't have to be released next month. At some point, all these new ES6 features will be optimized.

Also, as a thought; is co still relevant, or will still be relevant in 2.0?

@jonathanong
Member

yeah we'll leave it in for now for function* (ctx, next) {} middleware. i don't see a reason not to unless anyone has objections.

@felixfbecker
Contributor

Old middleware will not work anyway and will require koa-convert. I think we should remove co and instead let koa-convert take care of converting legacy, generator-based, context-as-this middleware. Might add performance, but the question should be why should we leave it in if old middleware won't work anyway.

@thelinuxlich

Arrow functions are optimized in Node 4

@jonathanong
Member

should we remove co from koa, guys? this means that all your generator functions should look like this if you don't use babel:

app.use(co.wrap(function* (ctx, next) {
  yield next()
})

we're going to eventually remove co anyways... could be v2 or v3.

@dead-horse
Member

remove co after node LTS support async await ?

@tejasmanohar
Member

👍 for after Node LTS supports async/await

@felixfbecker
Contributor

That's gonna be ages.

@tejasmanohar
Member

@felixfbecker Well, part of the question is would you rather use co#wrap. I'd guess 1.5 - 2 yrs till async/await is in Node LTS but may be completely wrong... all this Babel hype has made us immune to time!

@thelinuxlich

I prefer to use Babel so I can choose between co or bluebird

@yanickrochon

There's already a proposal which I think have merits. Since co has been Promise-based for a while now, I think Koa should drop it as dependency and move to a Promise solution. The advantage of using promises is quite evident and should not have a negative impact in most cases. Also, old middlewares can use co.wrap if they need to be re-used, until they migrate to be 2.0 compatible. To me, since there is a solution that not only works but is clean means that there's no problem in dropping co in favour of Promise or async/await (using a transpiler for now).

Furthermore, Generators have always been "hacky". It does not promote good usage of the design pattern :)

@jonathanong
Member

@thelinuxlich

I prefer to use Babel so I can choose between co or bluebird

this should be irrelevant if you do app.use(function* (ctx, next) {}) right

@thelinuxlich

@jonathanong how so? If I use async/await keywords I will need Babel anyway, right?

@gyson
Member
gyson commented Oct 23, 2015

@jonathanong

  • Is function* (ctx, next) {} a valid middleware or just a shortcut for co.wrap(function* (ctx, next) {}) with app.use?
  • Should koa-compose and koa-router support it ?
  • Could koa-* middleware return function* (ctx, next) {} ?
@fundon
Contributor
fundon commented Oct 23, 2015

I found some interesting things with koa-compose

e.g:

const middleware = compose([
  function *one(ctx, next) {
    // maybe will return something
  },
  function *two(ctx, next) {
    // maybe will return something
  }
])

// now, `yield middleware(ctx, next)` is a Promise Instance
app.use(function *(ctx, next) {
   const result = yield (yield middleware(ctx, next))
   // do something for result
})
@fundon fundon referenced this issue in trekjs/trek Oct 23, 2015
Merged

koa@2.0 #16

@meaku meaku referenced this issue in peerigon/npm-stats Oct 26, 2015
@meaku meaku Some fixes and improvements 01b4d7d
This was referenced Oct 27, 2015
@matthewmueller
Contributor

Haven't been really following this discussion too much, but I feel like I'm missing the benefits of these changes. Is it just "new-ness"? The API seems more confusing now:

app.use((ctx, next) => {
  const start = new Date;
  return next().then(() => {
    const ms = new Date - start;
    console.log(`${ctx.method} ${ctx.url} - ${ms}ms`);
  });
});

Don't take this to sound negative, just curious for the reasoning behind these changes.

@mike-marcacci

Hey @matthewmueller, it's taking advantage of the es7 syntax, which is much less of a hack than using generators:

app.use(async (ctx, next) => {
  const start = new Date;
  await next();
  const ms = new Date - start;
  console.log(`${ctx.method} ${ctx.url} - ${ms}ms`);
});
@madbence

@mike-marcacci it should be async (ctx, next) => ...

@mike-marcacci

correct :)

@tj
Member
tj commented Nov 19, 2015

Mentioned somewhere else, but I think we should wait to upgrade middleware until async/await is native, otherwise we'll just be going through them all over again to upgrade. Plus doing it now is confusing in the sense that it makes it seem like people should be migrating, even though 2.0 is not a thing yet (IMO shouldn't be until async/await).

Other than async/await there's not really anything new, so the less pain for migration the better. Requiring Babel will just make Koa go vaporware, at least I certainly wouldn't want to use Babel for server code.

@tejasmanohar
Member

@tj I kinda agree with you that maybe v2 shouldn't be released as "stable" until async/await is in V8 if we've decided not to use Babel to transpile the module's code (though I think that's fine and means we can release v2 stable-y earlier)... reason for this is it's kind a regression to switch out promises / .then()ables for co / generators / yield since we lose the serially (top -> bottom) processed code /readability benefits for managing async flow that exist in v1.

UPDATE: basically, writing koa 2 middleware without async/await is harder, less readable, and a regression in terms of what co / koa v1 / yield provide- imo

@magicdawn

at least I certainly wouldn't want to use Babel for server code.

👍

@omsmith
omsmith commented Nov 20, 2015

I'd say on my end, I've made the updates I've submitted, since I made them locally to give it all a go - so may as well submit them.

Perhaps the middlewares/tooling which have released new versions (koajs/compose, koajs/rewrite, koajs/route) should unpublish the major bumps and republish with an -alpha suffix? If 2.0 is being tip-toed around for the time being then not much point in releasing them all as latest when koa itself hasn't done so.

Personally, I do prefer the promise interface, even without async/await (although obviously the new syntax will make it nicer to consume), just to remove confusion in thinking this is what generators "actually do".

@yanickrochon

I too understand the wait, but really like the Promise implementation. Did not like it at first, but really got to appreciate things like

function getSomeValue(key) {
  return valueCache[key] || (valueCache[key] = new Promise((resolve, reject) => {
    // do some async processing
    // then resolve(value); or reject(Error)
  }));
}

My question, however is: "What is the ETA for native async/await?" If the answer is "next year, or something", then we should really consider releasing Koa 3.0 then and start migrating essential middlewares right now. 😄

@mike-marcacci

The tc39 page still has the spec in "DRAFT" but with the expectation that it will move to "FINISHED" this month.

Once it's finalized, it obviously has to be implemented in V8 before it can make its way to node, so the beginning of 2016 is the earliest I'd bet on.

@ljharb
ljharb commented Nov 20, 2015

fwiw, the arrow function spec did not move to stage 4 ("finished") this week - it's still stage 3.

@tejasmanohar
Member

@mike-marcacci Early 2016 seems a bit too hopeful.

@mike-marcacci

@tejasmanohar, you're definitely right - just emphasizing that "next year, or something" is definitely the answer to @yanickrochon's question

@tejasmanohar
Member

Moreover, maybe it's just me, but I don't see how using co in Koa v1 is better than using Babel for async/await in Koa v2 (and official middleware). Someone explain?

If we don't use async/await through Babel in Koa v2 stuff, then what's the improvement to warrant a new version? Also, what are the real downsides of transpiling syntax on the server?

UPDATE: We don't have to use Babel or force anyone to use Babel in Koa itself but what about the official middleware. I don't see a reason not to use Babel there until async/await hits stable Node?

@yanickrochon

To me, the real improvement over co is stack trace. Just by replacing parts of my apps with promises made a real difference on maintenance cost.

As for Babel, AFAIC, this is just a matter of semantic as it really doesn't offer much than that. I personally don't care much about it. I also noticed that arrow functions are slightly slower than "legacy" functions, but I haven't really made a benchmark on that one.

@coderhaoxin coderhaoxin referenced this issue in koajs/mount Nov 20, 2015
Closed

Koa@2 #32

@thelinuxlich

Pff, forget the past, release Koa 2 now :)

@tejasmanohar
Member

I'm not concerned with the perf aspect of Babel or even using Babel in the core... it's more about whether or not to use Babel for async/await in official middleware in the Koa.js org. We should probably vote on a universal policy for this, as if we release Koa@2, users will expect the popular official middleware to be upgraded and follow a standard.

And, I'm not the only one noticing this... @coderhaoxin, @fengmk2, and @matthewmueller have all brought up concerns about the new Promise-based middleware in issues on other repos in the org. Without async/await, this feels like a regression of the async control flow benefits from Koa@1 with yield... almost feels like callbacks from a readability perspective. See here, here, and here.

So... I'll start the poll. +1 for Babel in official middleware for me. I don't wanna include Babel in the core or make users of Koa use Babel (like require hooks), but I think that's a fair, opinionated choice for the official middleware as they're merely clients of Koa 2, not Koa itself.

@elgerlambert

Could be a while before async/await is implemented in v8 (comment made 3 weeks ago):

I should also note that async is a particularly tricky feature that will require
deep knowledge of V8's innards. We expect this to be a multi-quarter project. In
particular, it ties in closely with generators, around which there currently are
various open questions in the V8 implementation. We have some plans for tackling
that next year, but not before we have finished ES6. To be honest, we would
prefer not to open that can right now, since ES6 already is producing a lot of
churn. - https://codereview.chromium.org/1423663006/

Here's a different issue on the same topic: https://code.google.com/p/v8/issues/detail?id=4483

@menems
Contributor
menems commented Nov 20, 2015

Hi,

I don't think you have to use babel on official middleware, unless thoses middleware are already es5 transpiled for end user. Users have to choose if they want async support with babel or use promise style as long as async has official support on node core.

Some people prefer use promise catch pattern than try/catch.

koa1: generator
koa2: promise ( async with babel)
koa3: native async

I think it's a not a bad idea to release a koa2

@fengmk2 fengmk2 referenced this issue in koajs/cors Nov 20, 2015
Closed

Koa2 #6

@yanickrochon

I think that requiring Babel will only cause harm to Koa as it should be a matter of choice for a project only. Forcing Babel (i.e. extra non essential dependencies) is a big 👎 for me.

As for promises regressing to a callback-like style, I disagree. The big issue with callbacks was the indentation problem, where the flow could easily get lost through the layers of callbacks, where people had to fragment code to keep it clean. With Promises, the control can easily be vertical and simple through chaining, and usually only require one level of indentation for many, many asynchronous requests within the same workflow. Hardly the same as with callbacks.

Also, the advantage of promises is the lack of try... catch in code (that I particularly find ugly) and is encapsulated in a more elegant way using promises.

My guess is that async/await will take a bit lot longer than a few months to implement (as suggested by @elgerlambert 's comment. The implementation will need to get around the stack trace problem that arise when using yield with co right now and produce a real call stack on error, among other things. Bottom line is, I would not be surprised to see this feature implemented only after the second quarter of 2016 in an unstable version of Node.

@fundon fundon referenced this issue in koa-modules/multer Nov 20, 2015
Closed

Koa v2 multer v1 #4

@matthewmueller
Contributor

Thanks for the information guys. Yah, I think we should wait as well.

I'm -1 on the promise implementation (without await/async) for 2 reasons:

  1. It requires a change in all middleware (there are 1000's of koa middleware modules at this point, public and private)
  2. Aesthetically, I think it's really hard to say that the promise implementation is nicer than the generator implementation. There are more tokens and more indentation.

I agree with the others that I don't think it's reasonable to force everyone to use babel-node, it's also tangibly slower to recompile than node.

I do think the ctx stuff is nice, but I'd rather wait until async/await than force everyone to update their middleware twice.

@mattstyles

Requiring end-users to transpile, and to transpile selected dependencies, is proper weird.

Publishing transpiled modules isnt a problem, then its just a matter of which coding style is preferred or performance. Of course, having a decent stack trace is necessary too.

If maintainers like the async/await style and it looks like (for the time being) es5 transpiled code would be most performant then surely pre-compilation is the way to go no? Just dont force that transpilation on to the end-user, who should be able to include a few middleware, attach them to koa and node server to get going.

@omsmith
omsmith commented Nov 20, 2015

async/await wouldn't force an additional iteration. The signature stays the same, so churning through all the middleware wouldn't have to happen again (though more complex middleware might opt to use the new syntax to simplify things).

@tejasmanohar
Member

I agree with the others that I don't think it's reasonable to force everyone to use babel-node, it's also tangibly slower to recompile than node.

If we transpile official middleware that's making use of async/await before publishing to NPM, the end user doesn't need to use Babel. Async/await are just handlers of promises. It's about what's used in the official middleware. @matthewmueller

@yanickrochon

I could live with middleware being developped with Babel (as a dev-dependency), and transpiled to ES2015 before being published to npm.

  • src the Babel implementation
  • dist the transpiled code

and refer to dist/*.js in package.json for the main module. Thus making middlewares ready for async/await while being available for Koa 2.

@matthewmueller
Contributor

async/await wouldn't force an additional iteration

yah, the 2nd iteration is certainly optional, but people will probably want to upgrade their middleware again. i guess i just don't see any downside in waiting until async/await.

If we transpile official middleware that's making use of async/await before publishing to NPM, the end user doesn't need to use Babel. Async/await are just handlers of promises. It's about what's used in the official middleware.

just becomes harder to tweak and fix bugs you discover in your node modules, since it's compiled javascript. not as bad as coffeescript's compiled output, but still can be confusing.


Personally, I wouldn't mind supporting both promises and generators, but it seemed like folks wanted to support one or the other.

@targos
Contributor
targos commented Nov 20, 2015

To prevent the need of an update when async/await is native and keep backward compatibility, the middlewares could be exported like this (assuming src contains the source and lib the transpiled code):

module.exports = asyncSupported() ? require('./src') : require('./lib');
@tejasmanohar
Member

+1 for what @targos said

@monder
monder commented Nov 20, 2015

-1 on babel forced for everybody.
+1 for releasing v2 with promise based middlewares. Fully agree with @menems .
Most of the middleware do not require processing before and after request at the same time, so the cases as @matthewmueller mentioned are few, and it will be just the replacement of yield* next with return next().
Project based middleware and request handling with Promises looks more structural either starting with

next()
.then(() => {
  // code
}).then(() => {

or ending

}).then(() => {
  // code
}).then(() => {
  return next()
});
@dead-horse
Member

I'm -1 on change middlewares that use lots of generator functions to promise implementation. Don't want to maintain tow different branches for all the middlewares. Actually our inner web framework are still base on koa 1.x until async/await is native, it is not friendly for koa's users to migrate at this stage.

Maybe we should set the latest tag to 1.x (and all the middlewares support koa@2 too) until we have a conclusion with this issue. IMO we should make sure most of the frequently-used middlewares are default to support koa@2(using async-await with babel or promise implementation) before we finally announce koa@2.

@tj
Member
tj commented Nov 20, 2015

Replacing with promise-based ones seems really pointless to me since we'll just be doing it again later, back to the old yield code more or less. I don't see a huge reason to rush 2.0, I'd rather not taint the user experience and confuse people with something that isn't permanent. 2.0 has almost no new features, the reason for the bump was for async/await, so doing a 2.0 without async/await native is a bust IMO

@tejasmanohar
Member

+1. No point releasing 2.0 w/o async/await somehow (whether that's Babel, native, etc.). IMO- (Native async/await >) Babel async/await > Generators > Promise-based middleware w/o await.

@jonathanong
Member

yeah latest should be 1.x for a while. i haven't looked at how to publish "latest" on npm yet.

i don't see a rush with converting all the middleware to async/await or promises since you could always just use koa-convert or something. there's been a bunch of PRs but i've been more-or-less "meh" about them. some are fine since you don't NEED async functions to write it, but for others, it's easier to just use koa-convert.

@yanickrochon

With Koa 1.x, I get things like these

TypeError: You may only yield a function, promise, generator, array, or object, but the following object was passed: "undefined"
      at next (/home/yanick/dev/.../node_modules/koa/node_modules/co/index.js:101:25)
      at onFulfilled (/home/yanick/dev/.../node_modules/koa/node_modules/co/index.js:69:7)
      at process._tickDomainCallback (node.js:411:9)

I roughly have an idea where this is coming from, but it would make my life heck lot easier with a proper stack trace. If async/await doesn't get rid of that issue, screw that AFAIC.

@trueter trueter referenced this issue in erikras/react-redux-universal-hot-example Nov 20, 2015
Open

Express => Koa #591

1 of 8 tasks complete
@dead-horse
Member

I'll set my koa middlewares default to support koa 1.x, and a dist-tag koa2 point to the version that support koa 2.x.

$ npm view koa-bodyparser dist-tags
{ latest: '2.0.1', koa2: '3.0.0' }

Add some notifications in the readme, then change koa's latest tag to 1.x ?

@aheckmann
Member

doing a 2.0 without async/await native is a bust IMO

Agree.

@tejasmanohar
Member

Perhaps the middlewares/tooling which have released new versions (koajs/compose, koajs/rewrite, koajs/route) should unpublish the major bumps and republish with an -alpha suffix?

👍 @omsmith - except s/unpublish/deprecate

@mattstyles

Yeah I'd be happy to republish to try not to confuse the ecosystem

On Sat, Nov 21, 2015 at 5:31 PM, Tejas Manohar notifications@github.com
wrote:

Perhaps the middlewares/tooling which have released new versions (koajs/compose, koajs/rewrite, koajs/route) should unpublish the major bumps and republish with an -alpha suffix?

👍 @omsmith - except s/unpublish/deprecate

Reply to this email directly or view it on GitHub:
#533 (comment)

@mattstyles

Although, having said that surely a section at the top of the readme would suffice to explain which version hits which version of Koa

On Sat, Nov 21, 2015 at 5:33 PM, null matt@veryfizzyjelly.com wrote:

Yeah I'd be happy to republish to try not to confuse the ecosystem
On Sat, Nov 21, 2015 at 5:31 PM, Tejas Manohar notifications@github.com
wrote:

Perhaps the middlewares/tooling which have released new versions (koajs/compose, koajs/rewrite, koajs/route) should unpublish the major bumps and republish with an -alpha suffix?

👍 @omsmith - except s/unpublish/deprecate

Reply to this email directly or view it on GitHub:
#533 (comment)

@tejasmanohar
Member

No reason to rush this. As @tj said, there are very few actual improvements in Koa v2. If the overall consensus is no Babel for transpiling modules in this org (seems to be), then I vote we

  • Pause a Koa@2 release
  • Set Koa 1.x version as npm latest everywhere (in all Koajs/* middleware, too)
  • Move v2 to a non-master branch and put v1 on master (like Express).
    • This is because async/await is pretty far off from Node... First, it needs to be finalized in the ES2016 spec. Then, implemented in V8. Then... node. Would be surprised if it happened anytime before Q2 2016 (wild guess). Keeping v2 stuff on master for Koa + official middleware is confusing to newcomers, especially since the docs/ don't match up yet (which will obviously have to be fixed before we release v2 as well).
    • Add a notice to v1/master README about Koa 2
  • Start updating docs/ for Koa 2 on its non-master branch

Side note: I now see the -1 on Babel argument. One of the negative sides of Koa v1 pre-Node@4 was the requirement of using --harmony flags; we were longing for the features required to be in Node stable. Now that they are- if we introduce Babel and jump to async/await early, though we're not playing with as much risk as --harmony, it's still an extra step and yet another thing to push people away from using Koa in production. Koa v2 also provides no significant benefit to those who don't use async/await through Babel right now so transpiling doesn't solve much in the big picture.

@ugin
ugin commented Nov 21, 2015

I've upgraded a few projects from babel 5.x to 6.x mostly for performance issues, for a larger project initial load time took ~12s, not it takes ~4s. From my experience, introducing babel as a dependency is a terrible choice.

As mentioned above Generators have always been "hacky", well babel is a "hacky" choice as well, async/await are implemented using generators, so we only get a nicer syntax by introducing more complexity.

I agree with @tejasmanohar

@tejasmanohar tejasmanohar referenced this issue in koajs/route Nov 21, 2015
Closed

use with koa-send #41

@magicdawn

-1 on babel server code.

And I prefer this over ctx. I think we don't need to surrender to the arrow function. I use arrow function in small piece work, like Array.prototype.forEach / map , since it does not provide this binding, and our middlewares are not doing small piece work. So I don't use it in middlewares. that's it.

This was referenced Nov 23, 2015
@tejasmanohar
Member

On that note, would someone with access to NPM please change @latest to koa v1.x? :)

$ npm -v
3.4.1

$ npm dist-tags ls koa
npm latest: 2.0.0-alpha.3

I've done this with koa-route. Ideally, as @stephenmathieson mentioned in koajs/route#42, you should be able to npm install koa koa-route (same for all other official middleware- I'll have a look through the rest of them I have access to later today).

// cc @jonathanong @tj @fengmk2 @dead-horse @juliangruber (just tagging the most active people from this thread that have access- for some reason, @koajs/owners doesn't work for me- guess only owners can do that.)

@dead-horse
Member

If we make a conclusion here, I'll make these changes later. any suggestions ?

  • create a branch v2.x from master.
  • set v1.x to default branch.
  • change latest tag in npm point to koa@1
  • make all the middlewares' latest tag support koa@1, and add a tag named koa2 to support koa@2.
@tejasmanohar
Member

👍 - thx, @dead-horse

My Votes-

  • create a branch v2.x from master.
  • set v1.x to default branch.
  • change latest tag in npm point to koa@1
  • make all the middlewares' latest tag support koa@1, and add a tag named koa2 to support koa@2.

Additions -

  • set v1.x code to master
  • make all middleware's master reflect version compatible with koa v1.x

Questions-

  1. Why do you prefer setting v1.x to default branch to just moving v1.x code to master? This is nicer, as most people assume master reflects the current stable ("latest") afaik.

UPDATE: I guess ^ is valid if you want to avoid rewriting git history. Yeah... probably best.

Everyone else- please vote 😄

@fundon
Contributor
fundon commented Nov 24, 2015

Or create next tag for koa v2.x on npm.

@yanickrochon

I wondered the same thing about 2.0 being master.... it should've been a next branch with a 2.0-alpha* tags all along.

@tejasmanohar
Member

I'm cool w/ next branch

@jedahan
jedahan commented Nov 24, 2015

+1 for master being v1.x right now, next branch being created for v2.x, and using tags for actual version numbers, from either branch.

@tejasmanohar
Member

thanks for knocking this out, @dead-horse.

next question- should we continue accepting PRs for making official middleware v1 -> v2? I think it's a waste of a release for even the middleware (not sure koa core) until we have async/await. we'll have to update this all again once await is out, document this without await, and manage issues with/without await and for v1 until v2 is released stable and decently adopted. premature, imo.

@yanickrochon

My take on this is that some middleware can upgrade easily to Koa 2. Some of them do not rely on any asynchronous call, and having them compatible without koa-convert is just fine right now.

No need to wait for async/await if the middleware doesn't even need it. Besides, I personally prefer a Promise implementation as it does not force me to use await all the way down a function stack.

@EvanCarroll

Guys, come on. This is totally of topic. This is about the release of Koa v2. Not how to configure Babel for Koa v2. There are a hundred ways you could about getting/sharing that information, start with Stack Overflow or a separate bug report for docs. We have 58 people following this issue that are just concerned with the release of Koa v2, and the status of async/await in Node.

@callumlocke

We do not plan to release v2 as "stable" until async/await hits node.js. Requiring babel to run your server is just not good developer experience.

I think you might have chosen the worse of two evils here. Letting this project exist in a confusing state for months, during which time it requires constant diligence (to check you're not reading the wrong branch of documentation or installing the wrong version of a plugin), is a worse developer experience in my opinion, and is generating permanent baggage. I might be wrong, but I would guess that the Koa project would be stronger in the long term if it refocused its pitch now: deprecate v1 to shut down the constant source of confusion and gotchas (accepting that this temporarily limits the potential market to those devs who are comfortable with build systems). Then take advantage of the inevitable surge in interest when async/await hits Node stable and everyone's looking for clearly pitched tools that take advantage of it.

@DJviolin

@EvanCarroll StackOverflow Koa community is basically dead.

389 questions vs 24553 questions.

I think an unified documentation (with the most popular middlewares, even if they maintained by outsiders!) will help to get some popularity. It should be at least as robust as the Node and Express API documentation. As @callumlocke said, try to find the correct documentation for the correct repo in github wikis is suck! Until than, only those developers interested in Koa who really want to build a fully async app from the ground up. They are not very much. Maybe you have to "re-invent the wheel" every time with Express, but at least those wheels are very well documented.

@EvanCarroll

@DJviolin it's not dead because it has fewer questions than Express. It does massively less than express and it's a newer framework. It clearly has less adoption too. Regardless of your silly definition of "dead" this isn't the place to ask questions. This is a bug report and questions about Gulp have nothing to do with it. Let's not simply pester a community because people are waiting here for updates. End of story.

@tj
Member
tj commented Jul 25, 2016 edited

The number of questions on SO is not a good indicator of the popularity or state of any project IMO.

People are free to use whichever version they're comfortable with, 2.x doesn't make sense "officially" when compilation of SS code is required. If anything we can clarify in the state in the Readme a bit more.

A big reason for not going ahead with 2.x until then is precisely because Babel is really confusing to get started with, especially if you haven't used it on FE codebases. It's the choice between some confusion now for having what is effectively an RC, or having even more confusion from using Babel and forcing people to compile on the server, which many people do not want, myself included.

@fl0w
fl0w commented Jul 26, 2016 edited

@tj To be fair, 2.x only requires compilation if the consumer opts for the sugar (async/await) - that's not a requirement by the library to work. Some simply wants their library to handle "promises natively", and even patch express to work as such - e.g. express-promise or express-promise-router.

What's your take on having 2.x being a promise-oriented solution (which also supports deprecated generator based middleware), and 3.x intended for use with async/await (with deprecated middleware removed)?

Edit changed a word s/framework/library.

@chovy
chovy commented Jul 26, 2016

I'm waiting for async/await support. I heard node/v8 will have it in October.

@dead-horse
Member

What's your take on having 2.x being a promise-oriented solution (which also supports deprecated generator based middleware)

I don't think this isn't what we want. We migrate to v2.x for _asyn await_, and I think we should not recommend people to use koa as a promise-oriented solution, which lose lots of readability. Before async await being native in node, generator based middleware is still the best choice for now(shouldn't warning people it is deprecated).

@magicdawn

co.wrap acts almost same to async, so:

  • if you think it's ok to use babel, just use it
  • if you don't wanna compile server code, just use co.wrap / bluebird.coroutine ...

i.e: I add impress-router@next to support koa@next with co.wrap

@rattrayalex

There's going to be a lot of excitement in the community when async/await hits. It may be the biggest thing to happen to server-side JavaScript since the merger of iojs and the node foundation.

The degree to which koa captures this excitement is likely to be dictated by the level of preparation within the koa community. Potential new adopters will want to see a wide array of battle-tested libraries that have already been working with async/await in production for a while.

If koa doesn't capture this momentum, I personally would be very concerned about a Python 2 / Python 3 situation, where most people stay on express even though koa is clearly better. Let alone the version split pain within the koa world itself.

Please take my thoughts with a grain of salt, as I don't currently have the good fortune of being able to write backend JavaScript professionally. I'm hoping against hope that the node world rallies around terrific paradigms and technologies (eg, koa with async/await) so that it makes more and more business sense to switch from Ruby/Python/etc to Node.

@rattrayalex
rattrayalex commented Jul 26, 2016 edited

@tj your concerns about confusion and compilation make a lot of sense.

Would you be open to a PR that:

  1. Turns the readme into a concise rundown of the difference between versions 1 and 2, with prominent links to the documentation for each, and a clear how-to for setting up server-side babel and a word on the caveats.
  2. Encourages package maintainers to support v2
  3. Clarifies that 1.x series will continue to be supported until after async/await is released.
  4. Sets a tentative "major version bump" date (eg; Sept 1). If uptake of v2 and a/a goes smoothly, the default version can become v2. Since it's a major bump, nobody should be adversely affected or forced to use compilation. The official momentum should help the community rally & prepare.

Needless to say, I would work with you on the specifics 😁

EDIT: I meant docs/website, not readme.

@yanickrochon
yanickrochon commented Jul 26, 2016 edited

I, for one, have personally manifested in interest in programming with promises and don't mind at all what others call "mess". I believe that I am not the only one. Waiting for async/await is fine, but Koa 2 is alright at the moment, and middleware maintainers can just refactor to be compliant. Once async/await is fully integrated into Node without requiring compilation, refactoring from Promise (or co.wrap, etc.) to async/await is quite trivial, if not required at all!

My 2 cents.

@tj
Member
tj commented Jul 26, 2016

@rattrayalex sounds great to me! My main issue is that I think we really need the async/await syntax, otherwise people will start writing middleware with promises directly which to me is a step backwards I think in non-trivial cases. That said I saw the V8 news as well so it shouldn't be too far off! Especially now that Node is moving at a faster pace.

@rattrayalex
rattrayalex commented Jul 26, 2016 edited

Excellent! Hope to get to work on that soon. Thanks so much @tj !

@wlingke
wlingke commented Aug 2, 2016

I'm a newcomer to Koa and am building a new application in the next couple of months (ie most likely before node releases async/await). Would you recommend using 1.x or 2.0 with promise syntax? It sounds like using babel to transpile async/await is very buggy. Which would be easiest for converting my application over to await/async when it becomes available?

@BruceHem
BruceHem commented Aug 2, 2016

Been using koa with babel, all running fine. No point using koa1

On Aug 2, 2016 7:38 AM, "Lingke Wang" notifications@github.com wrote:

I'm a newcomer to Koa and am building a new application in the next couple
of months (ie most likely before node releases async/await). Would you
recommend using 1.x or 2.0 with promise syntax? It sounds like using babel
to transpile async/await is very buggy. Which would be easiest for
converting my application over to await/async when it becomes available?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#533 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AO8QO1G7jJ2NBp21HoLaUWLLX1z4htTYks5qbpGYgaJpZM4GP5wF
.

@dominhhai dominhhai referenced this issue Aug 2, 2016
Open

Koa v2.x #665

16 of 16 tasks complete
@ranisalt
ranisalt commented Aug 2, 2016

If anyone wants to write benchmarks for Koa 2, you can use my package sandra, it is promise-only and very clean as you can see here :) I'd happily help anytime.

@HriBB
HriBB commented Aug 6, 2016

Is it possible to detect koa version from the running app?

@dominhhai

@HriBB you can get from package.json

@slaskis
Contributor
slaskis commented Aug 19, 2016

Anyone tried async-to-gen?

With that instead of babel getting started with koa 2 can be as easy as:

{
  "name": "koa-example",
  "version": "2.0.0",
  "scripts": {
    "start": "node -r async-to-gen/register server.js"
  },
  "dependencies": {
    "async-to-gen": "^1.0.5",
    "koa": "next"
  }
}

Sure, it only provides the async part but a lot of the other es6+ features are already in node so...

@PlasmaPower
Contributor

@slaskis At that point I don't see an advantage over babel.

@slaskis
Contributor
slaskis commented Aug 19, 2016

The advantage I see is that it's way faster and easier to get going, with much less configuration and thus potentially less "scary" for new users.

@wlingke
wlingke commented Aug 19, 2016

I've just been using babel-node. This is okay even in production for small/medium apps from what I have read and what others have tried.

@rattrayalex

Hmm, that looks quite interesting. Though I imagine most people would want to use it by putting

require('async-to-gen/register')

at the top of their files.

Seems simpler than doing the same with babel and multiple plugins. Also claims to be faster.

@ilkkao
ilkkao commented Aug 29, 2016 edited

The current plan is that node v7 will ship with V8 5.4 (There's a node PR already open that will integrate an early version of V8 5.4 branch to node master.)

At least in the current V8 5.4 branch, --harmony flag is needed to use the native async/await. As mentioned in previous comments that's not optimal for Koa. I'm wondering if any of these other options realistic?

  1. Ask V8 people to ship async/await enabled by default in V5.4.
  2. Ask Node.js people to patch V8 to have async/await enabled by default.
  3. Wait 6 months for node v8 and hope V8 has enabled async/await at that time

My own thoughts:

  1. Very likely can't be influenced.
  2. I think node has a policy not to modify V8 feature configuration, for good reasons.
  3. Many, including me, have waited this for a long time. Waiting another 6 or 12 months is not so nice.

Koa documentation already says "To use Koa with 0.11.x you must use the --harmony or --harmony-generators flag.". Maybe the least bad option still is to change that to: "To use Koa 2.0 you must use node v7 and the --harmony flag"

@rattrayalex

@ilkkao appears to be referring to nodejs/node#8317
(just wanted to include it for ease of reference)

@fl0w
fl0w commented Aug 29, 2016 edited

Koa 0.x was released with --harmony requirements back in the day.

I don't see the problem of just having Koa 2 under npm i koa@2 until node (probably v8) releases with async/await out of the box.

@felixfbecker
Contributor

I would vote for requiring --harmony in Node 7. I mean, no user is forced to upgrade to Koa 2.

@aheckmann
Member

If Node 7 includes a version of V8 which has async/await behind a flag,
releasing Koa 2 with a Node 7 + --harmony requirement sounds like a good
path forward. However, I think it should not be released as "latest" on npm
until the --harmony requirement is removed from V8.

On Mon, Aug 29, 2016, 7:31 AM Felix Becker notifications@github.com wrote:

I would vote for requiring --harmony in Node 7. I mean, no user is forced
to upgrade to Koa 2.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#533 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKLstU4VzM5Ov_DVhkr8O0zGEXeWjvhks5qku0ngaJpZM4GP5wF
.

@ljharb
ljharb commented Aug 29, 2016

--harmony was a horrible idea then, and would be a horrible idea now. #533 (comment), at the least, stems the bleeding somewhat.

@EvanCarroll
EvanCarroll commented Aug 29, 2016 edited

I'm for dropping it as official (removing _alpha) when --harmony is available. At that point, I wouldn't have a problem talking about a fall-back to gulp/babel in the docs if you were averse to --harmony. Quite frankly, if you're not using the newest stable version of node, this project has never yet been for you. And, if you are there is no reason /not/ to use harmony and enable those features. I remember doing it for generators. There was no problem back then with it.

@EduardoRFS
EduardoRFS commented Aug 30, 2016 edited

Targos, is working on Node V8 5.4 https://github.com/targos/node/tree/v8-5.4
I'm using and is "perfect" to use in Koa, async await behind --harmony

@chovy
chovy commented Aug 31, 2016

--harmony is fine imo, that's what its there for -- for cases like this. Obviously we'd all want everything in stable, but its either wait another year or hopefully in October with --harmony

@ljharb
ljharb commented Aug 31, 2016

--harmony is there for people testing for bugs in v8. It's absolutely not there for people to use features in production before they are ready. If it was production-ready, it wouldn't be behind a flag.

It was never OK to advocate using --harmony in production - it caused immeasurable harm to the community - and doing it again will be nothing short of a disaster.

@rattrayalex

@ljharb I find your assertions surprising. Can you provide some links for context?

@fundon
Contributor
fundon commented Aug 31, 2016 edited

https://github.com/targos/node/blob/v8-5.4/deps/v8/BUILD.gn#L430

Maybe the flag is --harmony_async_await or --harmony-async-await.

@EvanCarroll
EvanCarroll commented Aug 31, 2016 edited

For summary, we have two options now with the upcoming release Node v7,

  1. release and require --harmony until Node v8. Alternatively require build system like Gulp/Babel.
  2. wait for a stable release at a much later point in time when --harmony isn't required.

Maybe we should get @tj in on this,

For what it's worth, I plan to start developing with --harmony asap, and will run in production if need be. I'd rather have code future-safe and not bother with babel. I don't believe the async/await part of the spec is that mutable at this point. For instance, the last change was five months ago and it was about debugging the source text for the async function.. Most of the spec is years old.

@ljharb
ljharb commented Aug 31, 2016

@rattrayalex https://nodejs.org/en/docs/es6/ says:

All shipping features, which V8 considers stable, are turned on by default on Node.js and do NOT require any kind of runtime flag.
Staged features, which are almost-completed features that are not considered stable by the V8 team, require a runtime flag: --harmony.
In progress features can be activated individually by their respective harmony flag, although this is highly discouraged unless for testing purposes. Note: these flags are exposed by V8 and will potentially change without any deprecation notice.

This has always been the case, and is not new information.

@tj
Member
tj commented Sep 1, 2016 edited

I think going with --harmony is fine personally, I have yet to use a harmony feature that wasn't already pretty stable, plus we can just clearly document that it could potentially be sketchy. That said I think we'll know verrrry quickly if it is going to cause problems or not, it shouldn't be tricky to find out.

Plenty of people used Node itself in production long before 1.0, what really matters is if servers running with this WIP feature are stable (enough) or not. I recall zero problems with generators for Koa 1.x when it was behind --harmony.

Either way, if it's well-documented (or left as alpha), it's up to the developer(s) to decide. I would leave it as alpha/beta personally, that actually represents the state, versioning is not important, what's important is we don't have to use babel!

@felixfbecker
Contributor

I would say we do it like NPM and TypeScript and put 1.x under latest and 2.0 under next dist tag

@Kovensky Kovensky referenced this issue in targos/node Sep 1, 2016
Closed

Fix V8 5.4 for Node #1

@EduardoRFS

I'm using targos v8 5.4 on production ten day ago and for me is fine, 70k views per day, with "complex" async await usage. Only fun without babel

@renesamaral

@EduardoRFS Which version of node.js do you used? I installed the last nightly version of node, v7.0.0-nightly20160831266270e618, and it comes with v8 v5.1.281.81! How can i use the v8 5.4 of targos?

@EduardoRFS

@renesamaral git clone and build, i have edited a package of nodejs-git from archlinux aur. To make more easy.

@ranisalt
ranisalt commented Sep 1, 2016

@EduardoRFS I have interest in that pkgbuild, care to share?

@PlasmaPower
Contributor

@ranisalt I think just remove the #branch=5.x from the source line, but I haven't tried building it yet.

@soft-labs

@EduardoRFS can you point me to any docs on how to use your pkgbuild file? I'm on OSX and trying to make it work but with no success. Thank you.

@EduardoRFS
EduardoRFS commented Sep 16, 2016 edited

@soft-labs man is just to ArchLinux but essentially is easy to compile, clone targos repo and read https://github.com/nodejs/node/blob/master/BUILDING.md

Native async functions have one problem, performance(2x speed of new Promise and 1/2 speed of Promise.resolve), bluebird not work, AsyncFunction ever use internal PromiseThen function and GlobalPromise(es6 native) and apparently native is just a wrapper to generators, im trying to hack using C++ node addon but no works ;-; addon not give access to v8::internal

@soft-labs

@EduardoRFS Thks friend. I was able to build it by following the steps on the script by hand. But I had no success to put async / await to work even with --harmony flag on.

@soft-labs

@EduardoRFS Thanks. Working fine now.

@ilkkao
ilkkao commented Sep 24, 2016

Things are progressing nicely. v8-5.4 was merged to node master. Node v7 in late October will have it. Meanwhile async/await has been already enabled by default without any flags in upstream https://codereview.chromium.org/2356943002/

@saadq
Contributor
saadq commented Sep 24, 2016

So just for clarification, is async/await going to be under a flag in Node v7 or not?

@fl0w
fl0w commented Sep 24, 2016 edited

@saadq no Promises yet (pun intended).

@EduardoRFS
EduardoRFS commented Sep 24, 2016 edited

@saadq yep, in node 7 async/await is under flag(--harmony-async-await), node 7 is v8 5.4, probably in node 8 or a minor update. Only a miracle(or cherry pick), make async await run without flag in node 7

@gerardmrk

Async await is out babyyy!
https://twitter.com/malyw/status/780453672153124864

@ruimarinho
Contributor

It works great on the nightlies (it will still require --harmony or --harmony_async_await on the stable version).

One thing that set me off is that koa@2.0.0 is from March, while koa@2.0.0-alpha.7 (@next) is from September. I think that koa@2.0.0 should be unpublished to avoid confusion.

@ljharb
ljharb commented Sep 28, 2016

It could be deprecated, but thankfully you can't unpublish things anymore.

@ruimarinho
Contributor

If anyone wants to give this a try and is using docker, we've put some node v7 (nightly) alpine-based docker images at seegno/node for testing (e.g. seegno/node:7).

@ShimShamSam

With V8 now supporting async/await, if you use the Node nightly build (v7.x) with the --harmony flag, you don't have to transpile your server code.

@pesho
pesho commented Oct 6, 2016

Regarding the --harmony flag, I was just bitten by this V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=5322 - which affects Node 6.x only when started with --harmony.

Until a few hours ago I was in the camp that thought --harmony is fine for the Koa 2.0 release. Now I'm not so sure.

@ljharb
ljharb commented Oct 6, 2016

The harmony flag's all fun and games until somebody gets a silent runtime bug

@iyobo
iyobo commented Oct 6, 2016 edited

Well....someone has to use it otherwise how do we know the bugs that need to be fixed to get it to full release mode?

--harmony onwards folks :D

@EduardoRFS

@pesho if use only --harmony-async-await is fine no? Guys async / await is not more on flag in chrome canary, see changes in v8 code and if no have changes on async / await area, the current version in node 7 is stable

@fl0w
fl0w commented Oct 6, 2016 edited

@EduardoRFS that's looking at things simplistically. There might be other parts of v8 source code that's indirectly affecting how async/await works, I think what you said is wrong and misleading.

However, there's talk about perhaps bumping node v7 from v8 5.4 (--harmony-async-await) to v8 5.5 (async/await native without flag) when it's due in december, i.e. bumping v8 mid node v7 unstable release (which happened once, if memory serves me right 5.1 to 5.2).

CTC member Targos has (had?) an experimental branch using v8 5.5 and expressed no initial worries about upgrading, though nobody will know for sure until it actually hits the shelves in December.

I think it's unfair to do Koa release comparison between --harmony in node v0.11 and todays situation. This was a different era when node was perhaps a year behind v8 stable (guesstimate). Today, node is chasing edge v8 releases - caution has to be considered, especially when LTS and maintenance is a real concern.

An interesting point; if all goes against everyones wishes/efforts, we won't be seeing async await without a flag until node v8 which is due in april 2017 according to previous timeline.

@EduardoRFS

@fl0w true, but async functions in v8 is just a wrapper to generators, generators with co is faster than async functions. If generators is fine, async functions too. And generators have years.

On actual node 7.x(with --harmony) this issue not occurred https://bugs.chromium.org/p/v8/issues/detail?id=5322 is fixed on this patch https://codereview.chromium.org/2278413003 and his in node 7

@pesho
pesho commented Oct 6, 2016

@pesho if use only --harmony-async-await is fine no?

I haven't tried the nightlies, but should be fine. The actual trigger for the bug was --harmony-tailcalls (which is included in --harmony). Besides, the bug should be fixed already in the nightlies' V8.

If Koa 2 is released before async/await is enabled without a flag, we should definitely recommend only --harmony-async-await instead of the more risky --harmony.

@joshmanders

I talked to @jasnell on twitter regarding this, and he suspects that v7.x release later could have async/await landed if no ABI breakages.

https://twitter.com/jasnell/status/782612553218138112

@EduardoRFS

@joshmanders but node v7 is already in beta, async/await is landed but with --harmony-async-await flag,

@pesho The actual trigger for the bug was --harmony-tailcalls

This issue is already fixed on node 7. With --harmony, but is really better recommend only --harmony-async-await

@joshmanders

@EduardoRFS if you read the tweet, you'll see as long as there is no ABI breakage, you can see async/await removed from --harmony flag in a later release. Could be 7.1, could be 7.9 No idea. All I know is we might not have to wait until v8.

@ilkkao
ilkkao commented Oct 7, 2016

In any case async/await will be available without a flag in six months or sooner. I'd personally like to see koa to promote async/await immediately when node v7 is released.

@callumlocke

Replying to @tj's comment:

People are free to use whichever version they're comfortable with, 2.x doesn't make sense "officially" when compilation of SS code is required. If anything we can clarify in the state in the Readme a bit more.

Awareness of the distinction between Koa v1 and v2 is not the problem. The problem is the painful development experience. Even today I still frequently find myself looking at docs/code for the wrong Koa branch, or the wrong branch of a plugin, or a Stack Overflow answer or blog post about the wrong version.

These problems get worse when you're trying to introduce Koa to a team. Whenever I have to explain anything Koa-related to a new developer, half of what I say seems to be caveats about checking which version a plugin supports. Koa comes across as a minefield.

I understand your misgivings about requiring compilation for the stable branch. I agree that's a bad thing in principle. But it would only be a temporary measure until async/await arrives, and imo the alternative (continuing the painful developer experience, and continuing to generate FUD) is worse in this case.

@DJviolin
DJviolin commented Oct 17, 2016 edited

In my upper posts I talked about the lack of comprehensive documentation. In contrast, It's just joy to read the Express API docs. No need for hunting in github wikis (and switching between trees), everything in one place, every scenerio well documented. One of the reasons why people still using Express, not Koa. What worked for Express, even made by the same guy, why not just copy-paste the Express api docs template? The styling, content organization of the Express doc is just so joy to read, nothing can come close, even Go Iris or any Python framework's docs can't offer this visual joy and well organized structure.

Ok, Koa v2 officially not released, so the lack of documentation is not the case (yet). But do it will change on the release date?

Another problem with Koa v2 is that there's no proper plugin support for handlebars with partials, which for me (was) a deal breaker. Of course, that's not Koa team's fault, they won't developing these plugins, because Koa is not a "kitchen sink". Express is a "kitchen sink" and like a fully functional kitchen sink, it has a proper & unified routing documentation.

Now there is Nunjucks, which is similar to Handlebars and the layouts, partials support handled in templates. So the missing Handlebars partial support for Koa v2 is not a miss anymore (not for me, but for other people maybe).

@tj
Member
tj commented Oct 17, 2016 edited

It's just a tool, no one is forcing you to adopt it :p, do what you like, if you find the docs inadequate that's understandable but they're only a pull-request away.

The Express docs are only good because of the "sale" to StrongLoop that I got bashed for, so you can thank that for happening I guess haha. The Koa team is tiny, I'm not sure anyone has time to completely rewrite docs, but we're definitely open to contributions!

@danneu
danneu commented Oct 18, 2016

I agree with @ljharb, who pointed the following comment out to me made by a Chromium developer yesterday:

nodejs/promises#4 (comment)

I'm glad to hear so much excitement about async/await. However, Node v7 is based on V8 54, whose async/await implementation has some bugs in it (including a nasty memory leak). I would not recommend using --harmony-async-await in production until upgrading to V8 55; the easiest way to achieve that would be to wait for Node 8. A backport of everything to Node v6 would be non-trivial; there would be a lot of merge conflicts. Until Node 8 comes out, I'd recommend using a transpiler.

It seems best to keep holding out on the Koa 2 stable release.

@nickmccurdy

I agree with waiting for a stable release, but maybe there could be a beta or RC when Node 7 comes out.

@tj
Member
tj commented Oct 18, 2016

We have one :D next: '2.0.0-alpha.7', and anyone interested can already transpile, the arguing here is kind of pointless.

@chovy
chovy commented Oct 20, 2016 edited

@tj are you saying the 2.0.0-alpha.7 works with the harmony-async-await flag in node 7?
If so then I don't know what we are arguing about either.

@saadq
Contributor
saadq commented Oct 25, 2016

Node v7.0.0 released! :o

@motss
motss commented Oct 26, 2016

Start upgrading to Node v7.0.0 now~ 😸

@ncwhale
ncwhale commented Oct 26, 2016

7.0.0 is here!

@yeliex
yeliex commented Oct 26, 2016

Node 7.0.0 now ~

@BruceHem

Installed 7.0.0

@Aurelsicoko Aurelsicoko referenced this issue in strapi/strapi Oct 26, 2016
Open

Middleware-Status for Koa 2.0 transition #41

15 of 19 tasks complete
@jonathanong
Member

I agree with waiting for a stable release, but maybe there could be a beta or RC when Node 7 comes out.

next is already RC :) there's no plans for any other changes

@AntSworD
AntSworD commented Nov 7, 2016

waiting for v2.x release..

@nickmccurdy

@AntSworD Have you tried installing next?

@sulliwane
sulliwane commented Nov 15, 2016 edited

Node 7.1.0 is out
but v8 version is not 5.5 yet:

process.versions.v8:
'5.4.500.36'

Maybe more chance with the next version

@fl0w
fl0w commented Nov 15, 2016

@sulliwane a v8 version bump may or may not happen, it all depends on breakage. Compatibility comes first, and by default a v8 bump should (though not exclusively) require a node major semver bump as well. v8 v5.5 is scheduled for release in december.

@marvinhagemeister

@sulliwane as @fl0w already said. At the time node 7.0.0 was branched, v8 5.5 was not stable.

@ilkkao
ilkkao commented Nov 15, 2016 edited

nodejs/node#9618 v8 5.5 may happen soon afterall

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment