This is already supported via the server option.

const http = require('http');
const { WebSocketServer } = require('ws');

class MyIncomingMessage extends http.IncomingMessage {}
const server = http.createServer({ IncomingMessage: MyIncomingMessage });

const wss = new WebSocketServer({ server });

wss.on('connection', function (ws, request) {
  console.log(request instanceof MyIncomingMessage); // true
});

server.listen(8080);

The server and noServer options are preferable as they offer more control. The port option is just a quick way to start a server without customization and boilerplate code.

This is already supported via the server option.

Actually, that is the reason why I created this PR - to simplify this (when the server is required).

The server and noServer options are preferable as they offer more control. The port option is just a quick way to start a server without customization and boilerplate code.

Totally agree. One could have more flexibility with server/noServer options, but sometimes

without customization and boilerplate code

is exactly what is needed (426 responses by default). @lpinca I know you do not like adding extra options, but this one seems natural to me. We can use an extended WebSocket class with the port option. Why can't we extend the IncomingMessage?

We can use an extended WebSocket class with the port option. Why can't we extend the IncomingMessage.

A custom WebSocket class is a ws thing. You can't pass it as an option to http.createServer().

A custom WebSocket class is a ws thing. You can't pass it as an option to http.createServer().

Agree, but we use things backlog in the options to customize an internally created server. Why could we customize it a bit more with IncomingMessage?

I mean events like connection and upgrade are a part of the Public API, right? The request variable is a part of it, so it could be nice to have a native option to extend it.

This opens the doors to every other option listed here https://nodejs.org/api/http.html#httpcreateserveroptions-requestlistener and here https://nodejs.org/api/https.html#httpscreateserveroptions-requestlistener. I don't want that when the server option exists.

What are the benefits of supporting this option? A total of ~10 lines of boilerplate code removed? Sorry but the cons outweigh the pros.

This opens the doors to every other option listed here https://nodejs.org/api/http.html#httpcreateserveroptions-requestlistener

I disagree. The server itself(when the port options is used) is not exposed as a part of the Public API. So, there is no need to support those options at all, but the IncomingMessage is (connection event etc.). That's why I suggest to include only this option.

The server itself(when the port options is used) is not exposed as a part of the Public API. So, there is no need to support those options at all, but the IncomingMessage is (connection event etc.). That's why I suggest to include only this option.

It does not matter. If the IncomingMessage option is supported why ServerResponse, insecureHTTPParser, etc. are not. They are all options of http.createServer() and the next time someone like you want to support one of those options I can't say no because there is a precedent. The user argument will be "But the IncomingMessage option is supported!".

Again, the server option already allows you to do this easily, so it does not make sense to me.

I'm closing this. Thank you anyway.