assert: deprecate assert.fail partially #18418

BridgeAR · 2018-01-28T11:19:55Z

Using assert.fail() with more than one argument is not intuitive
to use and has no benefit over using a message on its own.

Therefore this introduces a runtime deprecation in case it is used
in that way.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

Affected core subsystem(s)

assert

lpinca · 2018-01-28T15:08:55Z

doc/api/assert.md

-[`Error.captureStackTrace`]). If no arguments are given, the default message
-`Failed` will be used.
+* `actual` {any} _Deprecated if not used as message (see below)_
+* `expected` {any}_Deprecated (see below)_


Nit: space after first _.

lpinca · 2018-01-28T15:20:16Z

lib/assert.js

+      warned = true;
+      process.emitWarning(
+        'assert.fail() with more than one argument is deprecated. ' +
+          'Please use assert.strictEqual instead or only pass a message.',


Nit: assert.strictEqual() for consistency.

vsemozhetbyt · 2018-01-28T16:00:54Z

doc/api/deprecations.md

+
+Type: Runtime
+
+Using `assert.fail()` with more than one argument has no benefit over writing a


Nit: a individual -> an individual.

BridgeAR · 2018-01-28T16:21:50Z

Comments addressed.

CI https://ci.nodejs.org/job/node-test-pull-request/12786/

joyeecheung · 2018-01-29T05:35:01Z

doc/api/assert.md

@@ -406,27 +406,52 @@ parameter is an instance of an [`Error`][] then it will be thrown instead of the
 ## assert.fail(actual, expected[, message[, operator[, stackStartFunction]]])


The signature here looks rather confusing, since actual and expected looks required here...maybe create another section with assert.fail(message), and deprecate this signature while referencing the new one?

Also, that way we can put a deprecated entry in the YAML so the whole signature would be labeled with deprecated in the TOC.

I agree that it looks confusing. We just never had such a case before but I agree that this is probably the best way to solve this. I will change it shortly.

BridgeAR · 2018-01-29T17:41:45Z

New CI https://ci.nodejs.org/job/node-test-pull-request/12805/

vsemozhetbyt · 2018-01-29T18:13:30Z

doc/api/assert.md

 * `actual` {any}
 * `expected` {any}
-* `message` {any} **Default:** `'Failed'`
-* `operator` {string} **Default:** '!='
+* `operator` {string} **Default:** '!='_


Unnecessary underscore?

jasnell · 2018-01-29T18:16:04Z

doc/api/assert.md

@@ -440,21 +465,11 @@ assert.fail(1, 2, new TypeError('need array'));
 // TypeError: need array
 ```

-*Note*: In the last two cases `actual`, `expected`, and `operator` have no
+*Note*: In the last three cases `actual`, `expected`, and `operator` have no


Perhaps drop the *:Note*: part of this now? It's not super necessary.

jasnell · 2018-01-29T18:16:26Z

doc/api/deprecations.md

@@ -818,6 +818,15 @@ a future version at which point only authentication tag lengths of 128, 120,
 is not included in this list will be considered invalid in compliance with
 [NIST SP 800-38D][].

+<a id="DEP0XXX"></a>
+### DEP0XXX: Using `assert.fail()` with more than one argument.


s/DEP0XXX/DEP00XX

joyeecheung

LGTM with one suggestion

joyeecheung · 2018-02-01T01:43:27Z

test/parallel/test-assert-fail.js

@@ -5,6 +5,12 @@
 const common = require('../common');
 const assert = require('assert');

+common.expectWarning(


Can you put the tests with the valid signatures to another file?

BridgeAR · 2018-02-02T15:21:46Z

Rebased due to conflicts and while doing so I also rewrote common.expectsError to assert.throws and found a mistake in one of the old tests because of that and fixed it. I also addressed @joyeecheung comment to split the tests into two files.

BridgeAR · 2018-02-02T15:22:14Z

New CI https://ci.nodejs.org/job/node-test-pull-request/12909/

mcollina

LGTM but needs a rebase

Using `assert.fail()` with more than one argument is not intuitive to use and has no benefit over using a message on its own. Therefore this introduces a runtime deprecation in case it is used in that way.

BridgeAR · 2018-02-02T18:05:38Z

Landed in 70dcacd

Using `assert.fail()` with more than one argument is not intuitive to use and has no benefit over using a message on its own. Therefore this introduces a runtime deprecation in case it is used in that way. PR-URL: nodejs#18418 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label Jan 28, 2018

BridgeAR force-pushed the deprecate-assert-fail branch from b990b8a to 33671e2 Compare January 28, 2018 12:05

ChALkeR added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jan 28, 2018

lpinca approved these changes Jan 28, 2018

View reviewed changes

vsemozhetbyt reviewed Jan 28, 2018

View reviewed changes

joyeecheung reviewed Jan 29, 2018

View reviewed changes

apapirovski approved these changes Jan 29, 2018

View reviewed changes

vsemozhetbyt reviewed Jan 29, 2018

View reviewed changes

jasnell reviewed Jan 29, 2018

View reviewed changes

jasnell approved these changes Jan 31, 2018

View reviewed changes

joyeecheung approved these changes Feb 1, 2018

View reviewed changes

BridgeAR force-pushed the deprecate-assert-fail branch from 0c6d14a to 34143dd Compare February 2, 2018 15:19

mcollina approved these changes Feb 2, 2018

View reviewed changes

BridgeAR force-pushed the deprecate-assert-fail branch from 34143dd to adc742e Compare February 2, 2018 17:36

assert: deprecate assert.fail partially

bf4ac0c

Using `assert.fail()` with more than one argument is not intuitive to use and has no benefit over using a message on its own. Therefore this introduces a runtime deprecation in case it is used in that way.

BridgeAR force-pushed the deprecate-assert-fail branch from adc742e to bf4ac0c Compare February 2, 2018 17:41

BridgeAR closed this Feb 2, 2018

tniessen added the deprecations Issues and PRs related to deprecations. label Sep 7, 2018

BridgeAR deleted the deprecate-assert-fail branch April 1, 2019 23:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

assert: deprecate assert.fail partially #18418

assert: deprecate assert.fail partially #18418

BridgeAR commented Jan 28, 2018

lpinca Jan 28, 2018

lpinca Jan 28, 2018

vsemozhetbyt Jan 28, 2018

BridgeAR commented Jan 28, 2018

joyeecheung Jan 29, 2018

joyeecheung Jan 29, 2018 •

edited

Loading

BridgeAR Jan 29, 2018

BridgeAR Feb 2, 2018

BridgeAR commented Jan 29, 2018

vsemozhetbyt Jan 29, 2018

jasnell Jan 29, 2018

jasnell Jan 29, 2018

joyeecheung left a comment

joyeecheung Feb 1, 2018

BridgeAR Feb 2, 2018

BridgeAR commented Feb 2, 2018

BridgeAR commented Feb 2, 2018

mcollina left a comment

BridgeAR commented Feb 2, 2018


		Type: Runtime

		Using `assert.fail()` with more than one argument has no benefit over writing a

		@@ -406,27 +406,52 @@ parameter is an instance of an [`Error`][] then it will be thrown instead of the
		## assert.fail(actual, expected[, message[, operator[, stackStartFunction]]])

assert: deprecate assert.fail partially #18418

assert: deprecate assert.fail partially #18418

Conversation

BridgeAR commented Jan 28, 2018

Checklist

Affected core subsystem(s)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BridgeAR commented Jan 28, 2018

Choose a reason for hiding this comment

joyeecheung Jan 29, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BridgeAR commented Jan 29, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BridgeAR commented Feb 2, 2018

BridgeAR commented Feb 2, 2018

mcollina left a comment

Choose a reason for hiding this comment

BridgeAR commented Feb 2, 2018

joyeecheung Jan 29, 2018 •

edited

Loading