koa 3.0 roadmap

[dead-horse]

There are lots of PRs are blocked due to breaking change, and maybe it's time to make a plan for koa 3.0 now, if anyone has other suggestion, please post in this issue. :)

• https://github.com/koajs/koa/issues/1044
• https://github.com/koajs/koa/issues/1008
• https://github.com/koajs/koa/issues/998
• https://github.com/koajs/koa/issues/904
• https://github.com/koajs/koa/pull/1011

[fl0w]

Is it to early to create a v3 branch? I have some spare time coming up and wouldn’t mind doing some work.

[dead-horse]

All these pending PRs are not so emergency to me, so if anyone has any thoughts or some feature / refactor required, post in the issue to help us decide when to start create v3 branch. :)

[fl0w]

How about officially dropping support for < node.js 8?

[iyuq]

koa-compose could rewrite using async/await

[iyuq]

totally rewrite using TypeScript

[fl0w]

I'm personally against introducing TypeScript, adding external typings should be easy enough for those in need.

[marswong]

How about officially dropping support for < node.js 8?

koa-compose could rewrite using async/await

@fl0w @iyuq according to community practice, engines support should always follow the Node.js release schedule :)

[marswong]

totally rewrite using TypeScript

like what @fl0w said above, just one more thing: koa is quite vary from egg、express and any other framework. It's just a pure http request middleware close to Node.js as you can see. So we can just feel free to write in pure JavaScript, follow the traditional convention and trust Node.js :)

[jonathanong]

if you have any breaking changes you'd like to introduce, please state them now :)

[fl0w]

Let's announce EOL for Koa v1.

[zhangxiang958]

How about support HTTP/2 ? https://nodejs.org/api/http2.html

[marswong]

@zhangxiang958 koa already support it since 2.3.0, u can simply setup a koa app over HTTP/2 like this:

const fs = require('fs');
const http2 = require('http2');
const Koa = require('koa');

const app = new Koa();

app.use(ctx => {
  ctx.body = 'Hello Koa'; // or any other stream
});

const options = {
  key: fs.readFileSync('xxx.key'),
  cert: fs.readFileSync('xxx.crt'),
};
const server = http2.createSecureServer(options, app.callback());

server.listen(443);

[hiroqn]

How about publish koa and official middleware module under @koajs/ ?

[urugator]

Adjust naming to follow WHATWG URL Standard. Eg: request.path should be request.pathname etc

[likegun]

I think #1044 has already been solved by this commit

[tiendq]

I think context.res and context.req are not good names and they make people confused with context.response and context.request. Is it better if we can name them behind NodeJS names, so context.res becomes context.serverResponse and context.req becomes context.incomingRequest?

[ng-]

@tiendq I completely agree! I keep mixing up req/request and res/response. I vote for something like

{
req:<koa request>,
res:<koa response>:,
raw:{
   req:<node request>,
   res:<node response>
}}

[damianobarbati]

How to access the http2 stream on ctx object to push assets to client using koa? It this supported right now?

[mike-tobia]

I second @damianobarbati , would be great to get an implementation snippet that displays the compatibility and its usage. For example, would the stream be accessible through ctx.res.stream?

I've been seeing a bit of chatter on HTTP/2 support for Koa - I agree that we don't need to define config just to "enable" out of the box. What we do need however, is an interface to utilize HTTP/2, let's say if the request type is HTTP/2, maybe context could be formed at this stage.

I believe that the moment the Koa community takes a stance on HTTP/2, this would promote its usage for the next generation of servers built using Koa. To me, this is a great step forward.

What I envision, as a mode of compatibility and usage, is to add ctx.stream if the request is in an HTTP/2 context. As a start, we could yield the benefits of pushing from the stream and get a grip on how to manage push streams without ending the connection prematurely.

[tajnymag]

How about publish koa and official middleware module under @koajs/ ?

Why not simply @koa/?

[Hiswe]

Here is my little suggestions

• ~~#1044 because more and more people are using next/nuxt applications (or maybe not by I am…)~~
• and as said by @Tajnymag a @koa namespace can be useful:
  • @koa/cors is already namespaced
  • it will be clearer what are the official middleware
  • for new adopter, it makes more easy what to safely start with. IMO “official” guaranties that it plays nicely with the framework and will be maintained over time
• optional some typescript types if needed as this language is getting more and more traction

[EDIT]

In fact everything's working perfectly. The application doesn't crash and we have a warn.
Up to us to fix that by sending the headers before next/nuxt rendering.

[fl0w]

Note, I am not privileged to make this decision. This is my personal opinion.

I'd like to chime in that I agree that namespace:ing npm-releases under npm:@koa is a good idea.

One or two caveats thought.

1. Only for packages that reside in github:@koajs
2. Don't namespace Koa core, i.e. npm i koa still resolves as expected.

Bug reports for 3rd party packages often end up in @koajs/koa#issues, which is burdensome for both maintainers and the user. This might clear things up a bit.

I also haven't considered possible implications of moving the packages (e.g. does npm have tooling for moving origins?).

[maticrivo]

+1 on #1044

[mytecor]

Please do normal error handling. The ability to set content type

[catsalive]

+1 on #998

[dolsup]

I suggest #1326

[Hanggi]

Is there any timeline or schedule for 3.0?

[libook]

Need some help?

[tinovyatkin]

I think removing next parameter from middleware and just awaiting all middleware can be most useful breaking change in 3.0. Debugging something like bellow is a nightmare:

app.use(async (ctx, next) => {
 // ... do something
 await next();
// ... do some more staff
})
app.use(async (ctx, next) => {
 // ... do something
 await next();
// ... do some more staff
})

while removing next will make composition simple and koa-compose will not be needed:

// koa-compose will not be needed, just do this:
  async handleRequest(ctx) {
    const res = ctx.res;
    res.statusCode = 404;
   try {
     for (const handler of this.middleware) {
        await handler(ctx);
     }
    respond(ctx);
   } catch (err) {
     ctx.onerror(err);
  } finally {
    // any finalisation logic here
  }
}

if something need to be guaranteed last handler then it can use events or better composition and .state

[octet-stream]

@tinovyatkin What if you need to do something after the next() call? For example, I'm using this scenario in multipart middleware:

import {parse} from "then-busboy"
import {unlink} from "promise-fs"

const unlinkFile = ({path}) => unlink(path)

const methods = ["post", "put"]

async function multipart(ctx, next) {
  if (!methods.includes(ctx.method.toLowerCase())) {
    return next()
  }

  if (!ctx.is("multipart/form-data")) {
    return next()
  }

  const body = await parse(ctx.req)

  ctx.request.body = body

  await next()

  // Cleanup files
  return Promise.all(Array.from(body.files.values()).map(unlinkFile))
    .catch(err => err.code !== "ENOENT" && Promise.reject(err))
}

export default multipart

How can I do so without next() as simple as this?