http: revert deprecation of client property by targos · Pull Request #1852 · nodejs/node

targos · 2015-05-31T11:28:04Z

Reason: breaks a feature in the request module

thefourtheye · 2015-05-31T11:47:48Z

Why don't we define client in this instead of IncomingMessage.prototype and issue the deprecation warning as it is in the old code?

I'm not against it

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.

Wouldn't something like this work ?
// define it once somewherevarclientProperty={configurable: true,enumerable: true,get: util.deprecate(function(){returnthis._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 constructorObject.defineProperty(this,'client',clientProperty)

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.

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?».

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?

@mscdex Would make test-npm cover testing with request module?

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

targos · 2015-05-31T15:51:11Z

moved the Object.defineProperty call inside the constructor. Deprecation message is now "client is deprecated, use socket instead".

targos · 2015-05-31T15:53:02Z

make test passes, running make test-npm

targos · 2015-05-31T15:59:27Z

make test-npm fails, but it seems to be unrelated to the ssl issue (first time I am running this task):

2> npm ERR! tar pack Error reading /Users/mzasso/git/targos/io.js/test-npm
2> npm ERR! addLocalDirectory Could not pack /Users/mzasso/git/targos/io.js/test-npm to /var/folders/4x/ffqx483s2wddw7mlzt10cgmm0000gp/T/npm-test-77672/npm_cache/npm/2.11.0/package.tgz
2> npm ERR! addLocal Could not install /Users/mzasso/git/targos/io.js/test-npm
2> npm ERR! Darwin 14.3.0
2> npm ERR! argv "/usr/local/bin/iojs" "/Users/mzasso/git/targos/io.js/test-npm/bin/npm-cli.js" "install" "/Users/mzasso/git/targos/io.js/test-npm"
2> npm ERR! node v2.1.0
2> npm ERR! npm v2.11.0
2> npm ERR! path /Users/mzasso/git/targos/io.js/test-npm/node_modules/inherits/README.md
2> npm ERR! code ENFILE
2> npm ERR! errno -23
2> npm ERR! syscall open
2> 2> npm ERR! ENFILE: file table overflow, open '/Users/mzasso/git/targos/io.js/test-npm/node_modules/inherits/README.md'
2> npm ERR! 2> npm ERR! If you need help, you may report this error at:
2> npm ERR! <https://github.com/npm/npm/issues>
2> 2> npm ERR! Please include the following file with any support request:
2> npm ERR! /private/var/folders/4x/ffqx483s2wddw7mlzt10cgmm0000gp/T/npm-test-77672/root/npm-debug.log
2> not ok 1 node "/Users/mzasso/git/targos/io.js/test-npm/bin/npm-cli.js" install "/Users/mzasso/git/targos/io.js/test-npm"
1..1
/Users/mzasso/git/targos/io.js/test-npm/test/run.js:192
if (er) throw er
^
Error: failed node "/Users/mzasso/git/targos/io.js/test-npm/bin/npm-cli.js" install "/Users/mzasso/git/targos/io.js/test-npm"
at /Users/mzasso/git/targos/io.js/test-npm/test/run.js:104:10
at ChildProcess.exithandler (child_process.js:692:5)
at emitTwo (events.js:87:13)
at ChildProcess.emit (events.js:172:7)
at maybeClose (child_process.js:953:16)
at Socket.<anonymous> (child_process.js:1114:11)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at Pipe._onclose (net.js:472:12)
npm ERR! Darwin 14.3.0
npm ERR! argv "/usr/local/bin/iojs" "/usr/local/bin/npm" "run" "test-legacy"
npm ERR! node v2.1.0
npm ERR! npm v2.10.1
npm ERR! code ELIFECYCLE
npm ERR! npm@2.11.0 test-legacy: `node ./test/run.js`
npm ERR! Exit status 1
npm ERR! npm ERR! Failed at the npm@2.11.0 test-legacy script 'node ./test/run.js'.
npm ERR! This is most likely a problem with the npm package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node ./test/run.js
npm ERR! You can get their info via:
npm ERR! npm owner ls npm
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /Users/mzasso/git/targos/io.js/test-npm/npm-debug.log
npm ERR! Darwin 14.3.0
npm ERR! argv "/Users/mzasso/git/targos/io.js/out/Release/iojs" "/Users/mzasso/git/targos/io.js/test-npm/cli.js" "run-script" "test-all"
npm ERR! node v2.2.1
npm ERR! npm v2.11.0
npm ERR! code ELIFECYCLE
npm ERR! npm@2.11.0 test-all: `npm run test-legacy && npm test`
npm ERR! Exit status 1
npm ERR! npm ERR! Failed at the npm@2.11.0 test-all script 'npm run test-legacy && npm test'.
npm ERR! This is most likely a problem with the npm package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! npm run test-legacy && npm test
npm ERR! You can get their info via:
npm ERR! npm owner ls npm
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /Users/mzasso/git/targos/io.js/test-npm/npm-debug.log
make: *** [test-npm] Error 1

Fishrock123 · 2015-05-31T16:08:04Z

@targos See #1850 (comment) -- it appears there is a 2nd error.

Edit: wait that looks different, can you try it again?

ChALkeR · 2015-05-31T16:16:23Z

The commit message is wrong atm.
The commit doesn't revert the deprecation after changes, it fixes it.

silverwind · 2015-05-31T16:17:24Z

LGTM regarding fixing the issue. I can't get test-npm to complete (https://gist.github.com/silverwind/a94589df8e3aae1907e1), but at least the SSL error is gone with this and the deprecation prints correctly.

silverwind · 2015-05-31T16:40:31Z

Suggesting http: fix deprecation of client property as the commit message.

thefourtheye · 2015-05-31T16:50:18Z

Shouldn't this be http.IncomingMessage?

you are right, updated

Yep, thanks for catching that.

Fishrock123 · 2015-05-31T17:17:45Z

LGTM. If people would rather just revert this deprecation altogether that also LGTM.

bnoordhuis · 2015-05-31T18:00:03Z

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

othiym23 · 2015-05-31T18:10:51Z

We know now that people use the property so let's keep it around for now.

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.

targos · 2015-05-31T18:12:46Z

moved again to a revert of the deprecation

bnoordhuis · 2015-05-31T18:16:40Z

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/

thefourtheye · 2015-05-31T18:20:56Z

@bnoordhuis LGTM, and I cannot land it :D

silverwind · 2015-05-31T18:24:56Z

If it matters, it was this.socket instead of socket before:

1eec5f0#diff-f7d8a311cc7ac30522e414465bda2229L52

ChALkeR · 2015-05-31T18:27:07Z

@silverwind No, it shouldn't matter.

silverwind · 2015-05-31T18:28:37Z

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: #1852Fixes: #1850 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Roman Reiss <me@silverwind.io>

silverwind · 2015-05-31T18:40:07Z

Landed in 4d6b768

ChALkeR · 2015-05-31T18:42:51Z

Yay. Could we have a 2.2.1 now?

Fishrock123 · 2015-06-01T00:38:37Z

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.

@othiym23 Yeah, but only a couple of us have access to an npm clone to statically analyze with @chrisdickinson 's estoc (myself not included). I've made an issue over on that repo for issues that we need static analysis for, but unfortunately this landed without it. chrisdickinson/estoc#1

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

othiym23 · 2015-06-01T06:09:18Z

@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#1852Fixes: nodejs/node#1850 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Roman Reiss <me@silverwind.io>

thefourtheye reviewed May 31, 2015
View reviewed changes

targos force-pushed the revert-client branch from 50d96a3 to 26547feCompare May 31, 2015 15:49

targos force-pushed the revert-client branch from 26547fe to cd2c6fcCompare May 31, 2015 16:27

thefourtheye reviewed May 31, 2015
View reviewed changes

othiym23 mentioned this pull request May 31, 2015
Error code: ESSL when trying to install npm/npm#8406
Closed

Fishrock123 mentioned this pull request May 31, 2015
http: clean up dead code and unused properties #1572
Closed

targos force-pushed the revert-client branch 2 times, most recently from d3f52bb to f2ad68fCompare May 31, 2015 17:04

targos changed the title ~~http: revert deprecation of client property~~http: fix deprecation of client propertyMay 31, 2015

mscdex added the http Issues or PRs related to the http subsystem. label May 31, 2015

http: revert deprecation of client property
fad5d5f
Reason: breaks a feature in the request module used by the bundled npm

targos force-pushed the revert-client branch from f2ad68f to fad5d5fCompare May 31, 2015 18:09

targos changed the title ~~http: fix deprecation of client property~~http: revert deprecation of client propertyMay 31, 2015

ChALkeR mentioned this pull request May 31, 2015
Replace '.client' with '.socket' as the former was deprecated in 2.2.0. request/request#1615
Merged

silverwind closed this May 31, 2015

rvagg mentioned this pull request Jun 1, 2015
Release proposal: v2.2.1 #1856
Merged

targos deleted the revert-client branch June 1, 2015 04:01

Uh oh!

Uh oh!

Conversation

targos commented May 31, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

targos commented May 31, 2015

Uh oh!

targos commented May 31, 2015

Uh oh!

targos commented May 31, 2015

Uh oh!

Fishrock123 commented May 31, 2015

Uh oh!

ChALkeR commented May 31, 2015

Uh oh!

silverwind commented May 31, 2015

Uh oh!

silverwind commented May 31, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fishrock123 commented May 31, 2015

Uh oh!

bnoordhuis commented May 31, 2015

Uh oh!

othiym23 commented May 31, 2015

Uh oh!

targos commented May 31, 2015

Uh oh!

bnoordhuis commented May 31, 2015

Uh oh!

thefourtheye commented May 31, 2015

Uh oh!

silverwind commented May 31, 2015

Uh oh!

ChALkeR commented May 31, 2015

Uh oh!

silverwind commented May 31, 2015

Uh oh!

silverwind commented May 31, 2015

Uh oh!

ChALkeR commented May 31, 2015

Uh oh!

Fishrock123 commented Jun 1, 2015

Uh oh!

othiym23 commented Jun 1, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants