TypeScript issue when using a custom listen handler

[rtcpw]

I am following the guide to setup SSR for my TypeScript-based project:
https://quasar.dev/quasar-cli-vite/developing-ssr/ssr-webserver#serverless

The problem appears to be the ssrListen wrapper, which declares the following type for the callback:

export type SsrListenCallback = (
  params: SsrListenParams
) => Promise<Server>;

It does not allow the type

{ handler: any }

to be returned. Am I doing something wrong, or is this a bug in the type declarations? I tried to submit this as an issue but the StackBlitz projects suggested for forking when submitting an issue do not use TypeScript.

[rtcpw]

Actually that entire sample code appears to be non-functional:

export async function listen ({ app, port, ssrHandler }) {
  if (process.env.DEV) {
    await isReady()
    return await app.listen(port, () => {
      if (process.env.PROD) {
        console.log('Server listening at port ' + port)
      }
    })
  }
  else { // in production
    // "ssrHandler" is a prebuilt handler which already
    // waits for all the middlewares to run before serving clients

    // whatever you return here is equivalent to module.exports.<key> = <value>
    return { handler: ssrHandler }
  }
}

Because the function is marked as async, it will always return a promise. So in production (the else branch is taken), the return type will be Promise<{ handler: any }>, and this will be exported as module.exports.default = Promise<{ handler: any }>. This is clearly wrong. I am not even sure why the default is there as part of the exports, that's not how CJM should export defaults. But it is there nevertheless.

[yusufkandemir]

Say that your serverless service requires you to:

module.exports.handler = __your_handler__

Then what you’d need to do is:
...

It's just stating the requirements and what you need to do to address those requirements. listen function is an ESM named export, Quasar CLI calls your listen(...) function, awaits it, and makes sure that handler CJS export exists in the final dist/ssr/index.js. So, what you are saying is completely incorrect.

quasar/app-vite/templates/entry/ssr-prod-webserver.js

Lines 157 to 161 in de58b98

	export default listen({
	isReady,
	ssrHandler,
	...middlewareParams
	})

The code example in the docs is incorrect as you said. The function should not have an async modifier to avoid forcing a Promise as the return value:

export function listen ({ app, port, ssrHandler }) {
  if (process.env.DEV) {
    return isReady().then(() => {
	  app.listen(port, () => {
        console.log('Server listening at port ' + port)
      })
    })
  }
  else { // in production
    // "ssrHandler" is a prebuilt handler which already
    // waits for all the middlewares to run before serving clients

    // whatever you return here is equivalent to module.exports.<key> = <value>
    return { handler: ssrHandler }
  }
}

After making this change the exports will be like this: module.exports.default = { handler: ... }. Which means whatever you return here is equivalent to module.exports.<key> = <value> mention is not correct either. So, the docs need to be updated.

[dongwa]

@yusufkandemir

Hi. In fact, there are some issues here.

1. If we follow the documentation's syntax, we will encounter a TypeScript type error, as shown below. I addressed the issue using the approach below. Maybe we should export the SsrListenParams for users or refactor the return type of ssrListen.

2. The content in index.js of the built artifact does differ from what is described in the documentation. I have shared a story about it in this article and provided a solution: : Deploy quasar to netlify with ssr mode #16565

[dongwa]

😂 While I was editing the article, you changed your perspective.

[yusufkandemir]

@dongwa I updated my comment just before you posted yours.

Regarding the type problem, see my comment: #16726 (comment)
Also, SsrListenParams is being exported by @quasar/app-vite, so you can already use it as a workaround. But, the listener callback type should be updated as the main fix.

The export problem is more complicated due to ESM/CJS interop stuff.

[dongwa]

You can only annotate the types of the parameters in the 'listen' function and remove the 'async' identifier if you don't need it.

import {
  ssrListen,
} from 'quasar/wrappers';

type SsrListenParams = Parameters<Parameters<typeof ssrListen>[0]>[0];

export const listen = ({ app, port, isReady, ssrHandler }: SsrListenParams) => {
  if (process.env.DEV) {
    isReady();
    return app.listen(port, () => {
      if (process.env.PROD) {
        console.log('Server listening at port ' + port);
      }
    });
  } else {
    // 生产环境下：
    return { handler: ssrHandler };
  }
};

[yusufkandemir]

The return type should be Server | Record<string, any> | Promise<Server | Record<string, any>> or even just any to support any potential cases. This needs to be addressed.

[dongwa]

The return type should be Server | Record<string, any> | Promise<Server | Record<string, any>> or even just any to support any potential cases. This needs to be addressed.

I hope you can also export the SsrListenParams

[yusufkandemir]

It's already possible

import type { SsrListenParams } from '@quasar/app-vite';

[dongwa]

@yusufkandemir

Is it true? I noticed there is no 'export' here.

[yusufkandemir]

OK, I was wrong, but you can use this instead:

type Params = Parameters<SsrListenCallback>[0]

it's simpler then going another round from typeof ssrListen

[dongwa]

OK, I was wrong, but you can use this instead:

type Params = Parameters<SsrListenCallback>[0]

it's simpler then going another round from typeof ssrListen

I made a mistake 😂. It seems to be work well.

But,why it can be imported without been exported🤔

[filiocorp]

I have spent quite a bit of time using quasar ssr with firebase, but no success after many days; I thought the best way to show you is to record my screen and show you what I have done. I would appreciate anyone taking a look at this:
My recorded screen

I also shared firebas.json; server.js, and functions/index.js for your reference. Any help would be appreciated

firebase.json

server.js

import express from 'express'
import compression from 'compression'
import * as functions from "firebase-functions";
import {
  ssrClose,
  ssrCreate,
  ssrListen,
  ssrRenderPreloadTag,
  ssrServeStaticContent
} from 'quasar/wrappers'
export async function listen({ app, port, ssrHandler }) {
  if (process.env.NODE_ENV === 'development') {
    await isReady();
    return await app.listen(port, () => {
      // we're ready to serve clients
      console.log(`Server is listening on port ${port}`);
    });
  } else { // in production
    return {
      handler: functions.https.onRequest(ssrHandler)
    };
  }
}

functions/index.js

const functions = require("firebase-functions");
const ssrApp = require("./ssr/index.js");
exports.ssr = functions.https.onRequest(ssrApp);

[rstoenescu]

Enhancements are coming in q/app-webpack v4.0.0-beta.17 and q/app-vite v2.0.0-beta.16

[yusufkandemir]

Further improvements were made by #18052 and #18050. It's been released on @quasar/app-vite v2.3.0 and @quasar/app-webpack v4.3.0 a while back. So, this issue should be completely eliminated now.