[connect] Add missing property originalUrl to req parameter

[trygveaa]

This adds a new class IncomingMessage which extends from
http.IncomingMessage and adds the originalUrl property which was
previously missing. This new class is used for the req parameter in
HandleFunction.

The originalUrl property is added to req here:
https://github.com/senchalabs/connect/blob/3.4.0/index.js#L133

originalUrl is present in the version specified in these type definitions, so I didn't change the version.

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:
If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/senchalabs/connect/blob/3.4.0/index.js#L133
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

[typescript-bot]

@trygveaa Thank you for submitting this PR!

🔔 @SomaticIT @EvanHahn - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#40776	diff
Batch compilation
Memory usage (MiB)	63.6	63.5	-0.2%
Type count	8398	8419	0%
Assignability cache size	901	903	0%
Language service
Samples taken	89	89	0%
Identifiers in tests	89	89	0%
getCompletionsAtPosition
Mean duration (ms)	308.4	308.6	0.0%
Mean CV	11.8%	10.9%
Worst duration (ms)	439.9	388.8	-11.6%
Worst identifier	http	app
getQuickInfoAtPosition
Mean duration (ms)	305.8	309.8	+1.3%
Mean CV	10.4%	11.9%	+14.7%
Worst duration (ms)	361.7	371.3	+2.7%
Worst identifier	IncomingMessage	res

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[EvanHahn]

Rejecting because I have a question:

Should we test that a request handler still works with http.IncomingMessage? For example, should we have a test like this?

app.use((req: http.IncomingMessage, res: http.ServerResponse) => {
  console.log(req, res);
  res.end();
});

[trygveaa]

@EvanHahn: Not sure if it's a question for me, or another maintainer. But sure, I can add that test if you want. I agree that it's a good idea.

[typescript-bot]

@trygveaa One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits or comments. Thank you!

[trygveaa]

@EvanHahn: I've added the test.

[typescript-bot]

🔔 @EvanHahn - Thanks for your review of this PR! Can you please look at the new code and update your review status if appropriate?

[EvanHahn]

I'm not a TypeScript expert. What does this line do?

[trygveaa]

http.IncomingMessage["url"] is a reference to the type of the url property in http.IncomingMessage, so it's setting the type of originalUrl to be the same as the type of url. It's called lookup types, documented here.

[typescript-bot]

A definition owner has approved this PR ⭐️. A maintainer will merge this PR shortly. If it shouldn't be merged yet, please leave a comment saying so and we'll wait. Thank you for your contribution to DefinitelyTyped!

[orta]

Looks good and thanks for the test to verify existing code doesn't break 👍

[typescript-bot]

I just published @types/connect@3.4.33 to npm.

[siraajahmed]

This should be "implements" as http.IncomingMessage is an interface.

My code will no longer compile in typescript 3.7.2 because of this issue.

Full error is "node_modules/@types/connect/index.d.ts(21,42): error TS2689: Cannot extend an in
terface 'http.IncomingMessage'. Did you mean 'implements'?"

Please can we fix this ASAP.

[trygveaa]

According to the types in this repo, http.IncomingMessage is a class. Where are you getting your types from?

[siraajahmed]

Ah thanks for that. Turns out we were using an older version of node @types where the http.IncomingMessage was an interface. Thanks for your prompt response