ResponseObject<T> is quite long and can make code a bit cumbersome expecially as it is very often wrapped with Promise like Promise<ResponseObject<ApiResponseBody>>.

It may be nice to have a shorter alias for ResponseObject and maybe a something like AsyncResponse for use with async handlers to help reduce code clutter.

To use session, I think we need to introduce middleware. So I'm thinking that we would need middleware decorators, @before and @after.

@before will be called right before run execute method of a handler.
@after will be called right after ...

npm run dev, npm run start, npx micro, npx prismy don't work and the readme doesn't actually say what to run the server locally.

It would be nice to show how prismy improve DX with GIF.

We need redirectResult and redirect method for BaseHandler

The default error handler doesn't use console.log. It makes debugging with prismy really difficult.
https://github.com/prismyland/prismy/blob/master/src/error.ts

What to do

• Add silent option. It should be false by default
• Use console.error(...)

Maybe https://microsoft.github.io/tsdoc ?

I think I explained enough in the title...!

Expected

const numberSelector: Selector<number> = ...
const stringSelector: Selector<string> = ...

const handler = prismy([numberSelector, stringSelector], (numberValue, stringValue) => {
  ...
})

Typescrirpt should recognize the tuple, [number, string].

Current status

Typescript infers the type as (number | string )[]

To use parameter decorators, we're using class. But I think it is kind of annoying... I guess we could do like the below example.

myHandler.selectors = [Session()]
function myHandler(session: SessionState) {
  
}

export default prismy(myHandler)

• Throw an error if req.body exists for bufferBodySelector, textBodySelector, jsonBodySelector and urlEncodedBody.
• Introduce general bodySelector which behaves just like next.js's body parsing behavior.

API routes of Next.js and Now.sh v2 are parsing body in advance. But our body selectors are trying to consume drained stream again so it is causing api routes fall into limbo.

The power of prismy can be aware when adopters are using it actually in VSCode.

I guess hosting some examples in Codesandbox should be enough!