Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[connect] Add missing property originalUrl to req parameter #40776

Merged
merged 1 commit into from Dec 17, 2019

Conversation

@trygveaa
Copy link
Contributor

trygveaa commented Dec 2, 2019

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

This comment has been minimized.

Copy link
Contributor

typescript-bot commented Dec 2, 2019

@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

This comment has been minimized.

Copy link
Contributor

typescript-bot commented Dec 2, 2019

👋 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.

Copy link
Contributor

EvanHahn left a comment

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

This comment has been minimized.

Copy link
Contributor Author

trygveaa commented Dec 5, 2019

@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 typescript-bot moved this from Waiting for Reviewers to Needs Author Attention in Pull Request Status Board Dec 5, 2019
@typescript-bot

This comment has been minimized.

Copy link
Contributor

typescript-bot commented Dec 5, 2019

@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!

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
@trygveaa trygveaa force-pushed the trygveaa:connect-req-add-originalUrl branch from 3e3533e to fe6e40c Dec 5, 2019
@trygveaa

This comment has been minimized.

Copy link
Contributor Author

trygveaa commented Dec 5, 2019

@EvanHahn: I've added the test.

@typescript-bot

This comment has been minimized.

Copy link
Contributor

typescript-bot commented Dec 5, 2019

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

@@ -18,11 +18,15 @@ declare function createServer(): createServer.Server;
declare namespace createServer {
export type ServerHandle = HandleFunction | http.Server;

export class IncomingMessage extends http.IncomingMessage {
originalUrl?: http.IncomingMessage["url"];

This comment has been minimized.

Copy link
@EvanHahn

EvanHahn Dec 5, 2019

Contributor

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

This comment has been minimized.

Copy link
@trygveaa

trygveaa Dec 5, 2019

Author Contributor

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 typescript-bot moved this from Needs Author Attention to Check and Merge in Pull Request Status Board Dec 5, 2019
@typescript-bot

This comment has been minimized.

Copy link
Contributor

typescript-bot commented Dec 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

orta commented Dec 17, 2019

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

@orta orta merged commit 7408c5d into DefinitelyTyped:master Dec 17, 2019
3 checks passed
3 checks passed
DefinitelyTyped.BenchmarkPR #26020 succeeded
Details
DefinitelyTyped.DefinitelyTyped #20191205.33 succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Pull Request Status Board automation moved this from Check and Merge to Done Dec 17, 2019
@trygveaa trygveaa deleted the trygveaa:connect-req-add-originalUrl branch Dec 17, 2019
@typescript-bot

This comment has been minimized.

Copy link
Contributor

typescript-bot commented Dec 17, 2019

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

@@ -18,11 +18,15 @@ declare function createServer(): createServer.Server;
declare namespace createServer {
export type ServerHandle = HandleFunction | http.Server;

export class IncomingMessage extends http.IncomingMessage {

This comment has been minimized.

Copy link
@siraajahmed

siraajahmed Dec 17, 2019

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.

This comment has been minimized.

Copy link
@trygveaa

trygveaa Dec 17, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@siraajahmed

siraajahmed Dec 17, 2019

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

trygveaa added a commit to trygveaa/typescript that referenced this pull request Dec 18, 2019
connect now has it's own IncomingMessage class which inherits from http
and includes the originalUrl property. The request instances here are
coming from connect, so they should use this class.

The IncomingMessage class from connect was added in
DefinitelyTyped/DefinitelyTyped#40776
trygveaa added a commit to trygveaa/typescript that referenced this pull request Dec 18, 2019
connect now has it's own IncomingMessage class which inherits from http
and includes the originalUrl property. The request instances here are
coming from connect, so they should use this class.

The IncomingMessage class from connect was added in
DefinitelyTyped/DefinitelyTyped#40776
kevinmarrec added a commit to nuxt/typescript that referenced this pull request Dec 18, 2019
connect now has it's own IncomingMessage class which inherits from http
and includes the originalUrl property. The request instances here are
coming from connect, so they should use this class.

The IncomingMessage class from connect was added in
DefinitelyTyped/DefinitelyTyped#40776
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.