-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
http: revert deprecation of client property #1852
Conversation
@@ -47,7 +47,7 @@ function IncomingMessage(socket) { | |||
// response (client) only | |||
this.statusCode = null; | |||
this.statusMessage = null; | |||
this._client = socket; // deprecated | |||
this.client = socket; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we define client
in this
instead of IncomingMessage.prototype
and issue the deprecation warning as it is in the old code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not against it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, but then we will be creating many functions, whenever we create a new object. It might impact the performance. Not sure if it is okay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't something like this work ?
// define it once somewhere
var clientProperty = {
configurable: true,
enumerable: true,
get: util.deprecate(function() {
return this._client;
}, 'client is deprecated, use socket or connection instead'),
set: util.deprecate(function(val) {
this._client = val;
}, 'client is deprecated, use socket or connection instead')
});
// IncomingMessage constructor
Object.defineProperty(this, 'client', clientProperty)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya. That should work. Are you going to change it or wait for TSC guys?
Edit: I think you have an extra paren at the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A quick question: why suggest using «socket or connection» instead of just one of those? «Use socket instead» would be more straightforward.
.connection
is from the first version of the http module, .socket
got there when the http module was replaced with the second version. Then .connection
got back in for compatibility. Both of those go as far as node 0.1.90 (node 0.2.0).
There is no actual need for keeping both of them, except for backwards compatibility. If one of those would be deprecated in further versions, the current message would add more inconvenience to the migration process:
— «client is deprecated, use socket or connection instead»
— ok, connection
— «connection is deprecated, use socket instead»
— …
Why not choose one of them now and recommend it? socket
is used internally atm.
I do not agitate for immediate .connection
deprecation, I just wanted to say that altering the message a bit would make further deprecation of one of those in some later version (if that happens) more convenient. Also it would not raise an extra question «should I use socket
or connection
here instead of client
?».
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say that socket
and connection
are used far more than client
, so I would hold off on making deprecation messages for them.
Regarding Object.defineProperty()
in the constructor, did you try this change with the request
module to make sure it is ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mscdex Would make test-npm
cover testing with request
module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mscdex
Your comment looks like you thought that I suggested deprecating one of those.
I just suggested to change the deprecation message for .client
to mention just one of those.
moved the Object.defineProperty call inside the constructor. Deprecation message is now "client is deprecated, use socket instead". |
make test passes, running make test-npm |
make test-npm fails, but it seems to be unrelated to the ssl issue (first time I am running this task):
|
@targos See #1850 (comment) -- it appears there is a 2nd error. Edit: wait that looks different, can you try it again? |
The commit message is wrong atm. |
LGTM regarding fixing the issue. I can't get |
Suggesting |
enumerable: true, | ||
get: util.deprecate(function() { | ||
return this.socket; | ||
}, 'http.IncomingRequest.client is deprecated, use .socket instead'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be http.IncomingMessage
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right, updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, thanks for catching that.
d3f52bb
to
f2ad68f
Compare
LGTM. If people would rather just revert this deprecation altogether that also LGTM. |
Let's just revert the deprecation warning. We know now that people use the property so let's keep it around for now. |
Reason: breaks a feature in the request module used by the bundled npm
I think it would be a good idea to recognize (or even make policy) that the determining factor for whether an object property on something created by Node is "used" shouldn't be whether that property is documented or used within the Node code base itself. Node has been around long enough that it shouldn't be a surprise to people that the ecosystem may be relying on attributes or behavior that Node itself isn't. |
moved again to a revert of the deprecation |
LGTM. Next one to LGTM should land it. (See what I did there?) CI: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/738/ |
@bnoordhuis LGTM, and I cannot land it :D |
If it matters, it was |
@silverwind No, it shouldn't matter. |
Okay, landing |
The improper deprecation of the property broke a feature in the request module used by the bundled npm. This reverts the deprecation part of this change. PR-URL: #1852 Fixes: #1850 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Roman Reiss <me@silverwind.io>
Landed in 4d6b768 |
Yay. Could we have a 2.2.1 now? |
@othiym23 Yeah, but only a couple of us have access to an npm clone to statically analyze with @chrisdickinson 's |
Notable Changes: * http: reverts the removal of an undocumented `client` property on client connections, this property is being used in the wild, most notably by https://github.com/request/request which is used by npm. (Michaël Zasso) [nodejs#1852](nodejs#1852).
PR-URL: nodejs#1856 Notable Changes: * http: reverts the removal of an undocumented `client` property on client connections, this property is being used in the wild, most notably by https://github.com/request/request which is used by npm. (Michaël Zasso) [nodejs#1852](nodejs#1852).
PR-URL: nodejs#1856 Notable Changes: * http: reverts the removal of an undocumented `client` property on client connections, this property is being used in the wild, most notably by https://github.com/request/request which is used by npm. (Michaël Zasso) [nodejs#1852](nodejs#1852).
@Fishrock123 I didn't mean that we should assay the corpus or use fancy static analysis tools, although those are other potential solutions. That is always going to be at least partially heuristic. I meant that the project as a whole should be conservative about removing or deprecating things, because we can't know what's being relied upon by third parties. Node is a semi-mature product, and should act like it. |
The improper deprecation of the property broke a feature in the request module used by the bundled npm. This reverts the deprecation part of this change. PR-URL: nodejs/node#1852 Fixes: nodejs/node#1850 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Roman Reiss <me@silverwind.io>
Reason: breaks a feature in the request module
See #1850
Replaces #1851
/cc @mscdex