This is already provided and typed correctly in UrlObject (now InputUrlObject)

For clarification on "input" and "output" types: #18766 (comment)

I took a look into the docu and I have the feeling some widening is needed for Url:
https://nodejs.org/dist/latest-v8.x/docs/api/url.html#url_url_format_urlobject tells that querystring#stringify is used by url#format.
https://nodejs.org/dist/latest-v8.x/docs/api/querystring.html#querystring_querystring_stringify_obj_sep_eq_options tells It serializes the following types of values passed in obj: <string> | <number> | <boolean> | <string[]> | <number[]> | <boolean[]> Any other input values will be coerced to empty strings.
Not sure if the Any other input values will be coerced to empty strings. part is really needed by anyone as and it may hide real issues but boolean and number (value and Array) sounds reasonable.

In that case, query: any makes sense as the input for url.format, but it's currently used as the output of url.parse. Should we swap them?

E.g.

// this represents the input of url.format
interface UrlObject {
  query?: any;
}

// this represents the output of url.parse
interface Url extends UrlObject {
  query: string | null | ParsedUrlQuery;
}

I would not go that far as e.a. a single RegEx/Array are not allowed. What about following as input for format:

interface Url extends UrlObject {
  // other fields
  query?: string | null | { [key: string]: undefined | null | boolean | number | string | Array<boolean | number | string> }
}

I know that this does not allow any type in the properties as it is in javascript. But as indicated above I would argue that such use of the api is questionable and at least I prefer that typescript tells me about this and I have to add a cast or toString().
The more relaxed variant would be following which is still better then a plain any.

interface Url extends UrlObject {
  // other fields
  query?: string | null | { [key: string]: any }
}

That makes sense, however Url is currently the output of parse, not the input of format. Are you suggesting swapping them?

Seems I did a copy paste issue here sorry.
I don't think we should swap them as this would be a similar action as renaming which has shown to cause side effects to other modules.

By the sounds of it, Url is supposed to represent the input of format. As you have pointed out, it accepts wider types than UrlObject because, if provided as arguments to format, Node will coerce them. Do I understand correctly? If this is the case, it seems an error to me that Url is currently used as the output of parse and UrlObject is used as the input of format. When parsing a query string, I do not want TypeScript to think my query string values are any!

I don't know the full history of node typings as I don't use it that long. Current state is that url.format() gets an UrlObject and url.parse() returns an Url. Changing the names which would be nice has bad side effects so I don't think we should do this now.

format accepts wider types then parse returns (at least for port and query). I'm not really a fan of expressing this by extending an interface - but it is like it is - don't know why.

What about creating three types: UrlObjectCommon holding the comon part, UrlObject extends it by adding the properties special to format and Url extends it by adding the properties special to parse. This would be still backward compatible.

Good suggestions! I've just pushed some changes, see what you think? @Flarna