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

assert.fail() accept a single argument or two arguments #12293

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
@Trott
Member

Trott commented Apr 9, 2017

First commit:

assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'

Second commit: Remove lint rule that flags use of assert.fail() with a single argument.

Third commit: Remove common.fail() in tests since assert.fail() with a single argument works as expected.

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)
@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Apr 9, 2017

Member

Isn't this semver-major? a change in a stable API?

Member

refack commented Apr 9, 2017

Isn't this semver-major? a change in a stable API?

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Apr 9, 2017

Member

Isn't this semver-major? a change in a stable API?

I won't argue if someone thinks it's major. But to answer the question from my view: I think it's minor because using the current API with only one or two arguments will provide a message that I would describe as broken.

assert.fail('one arg') results in AssertionError: 'one arg' undefined undefined. With this change, it results in AssertionError: one arg.

assert.fail(1, 2) results in AssertionError: 1 undefined 2. With this change, it results in AssertionError: 1 != 2.

It's hard for me to imagine a situation where the current behavior is desirable or expected.

Member

Trott commented Apr 9, 2017

Isn't this semver-major? a change in a stable API?

I won't argue if someone thinks it's major. But to answer the question from my view: I think it's minor because using the current API with only one or two arguments will provide a message that I would describe as broken.

assert.fail('one arg') results in AssertionError: 'one arg' undefined undefined. With this change, it results in AssertionError: one arg.

assert.fail(1, 2) results in AssertionError: 1 undefined 2. With this change, it results in AssertionError: 1 != 2.

It's hard for me to imagine a situation where the current behavior is desirable or expected.

@Trott

This comment has been minimized.

Show comment
Hide comment
@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Apr 9, 2017

Member

A typo in the message of the first commit:

supplied but arguments 1 2 and 4 all flasy) but also adds the far more

Member

aqrln commented Apr 9, 2017

A typo in the message of the first commit:

supplied but arguments 1 2 and 4 all flasy) but also adds the far more

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Apr 9, 2017

Member

It's hard for me to imagine a situation where that behavior is desirable or expected.

Code in the wild got used to it (maybe someone tests the exception text or whatever other silly things people do), I agree you only change the message, but it's not a "Bug Fix" per se.

"not an actual bug fix" ⚖ "change only in message text"

Although I'm an anarchist at heart, and am pro change, I would vote major

Anyway this discussion is kinda mute since v8 (ohh hello ambiguity 🤦) is just around the corner...

Member

refack commented Apr 9, 2017

It's hard for me to imagine a situation where that behavior is desirable or expected.

Code in the wild got used to it (maybe someone tests the exception text or whatever other silly things people do), I agree you only change the message, but it's not a "Bug Fix" per se.

"not an actual bug fix" ⚖ "change only in message text"

Although I'm an anarchist at heart, and am pro change, I would vote major

Anyway this discussion is kinda mute since v8 (ohh hello ambiguity 🤦) is just around the corner...

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Apr 9, 2017

Member

Anyway this discussion is kinda mute since v8 (ohh hello ambiguity 🤦) is just around the corner...

The plan with that was to call it Node 8, as it's as easy to say as v8 and a whole lot clearer. There's an issue discussing it somewhere.

Member

gibfahn commented Apr 9, 2017

Anyway this discussion is kinda mute since v8 (ohh hello ambiguity 🤦) is just around the corner...

The plan with that was to call it Node 8, as it's as easy to say as v8 and a whole lot clearer. There's an issue discussing it somewhere.

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Apr 9, 2017

Member

Node 8

Nodate isn't that a verb? Not that Nodge is unambiguous (darn it Ryan. And Douglas 😩)
BTW Nod (נוד) is Hebrew slang for [redacted by author, if you're curious google it]...

Member

refack commented Apr 9, 2017

Node 8

Nodate isn't that a verb? Not that Nodge is unambiguous (darn it Ryan. And Douglas 😩)
BTW Nod (נוד) is Hebrew slang for [redacted by author, if you're curious google it]...

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Apr 9, 2017

Member

test/windows-fanned — running tests

Yay, I just learned how to retrigger just windows-fanned. One small step...

Member

refack commented Apr 9, 2017

test/windows-fanned — running tests

Yay, I just learned how to retrigger just windows-fanned. One small step...

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Apr 9, 2017

Member

For what it's worth:

  • I agree it's not just a bug fix. It's a new feature at a minimum. So semver-minor at a minimum. But yeah, I said I wouldn't argue against major if others thought it was major, so I'll stop there.

  • I've been sticking to "version 8" although I know "Node.js 8" has its proponents too. Whatever the shortcomings of these things, all of them are better than calling the Node.js version "v8". :-D

Member

Trott commented Apr 9, 2017

For what it's worth:

  • I agree it's not just a bug fix. It's a new feature at a minimum. So semver-minor at a minimum. But yeah, I said I wouldn't argue against major if others thought it was major, so I'll stop there.

  • I've been sticking to "version 8" although I know "Node.js 8" has its proponents too. Whatever the shortcomings of these things, all of them are better than calling the Node.js version "v8". :-D

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Apr 9, 2017

Member

@aqrln Typo in commit message fixed. Thanks!

Member

Trott commented Apr 9, 2017

@aqrln Typo in commit message fixed. Thanks!

@refack refack added semver-major and removed semver-minor labels Apr 9, 2017

if (arguments.length === 1)
message = actual;
if (arguments.length === 2)
operator = '!=';

This comment has been minimized.

@addaleax

addaleax Apr 10, 2017

Member

You could just write message = actual, operator = '!=', stackStartFunction = undefined as part of the function arguments, right?

@addaleax

addaleax Apr 10, 2017

Member

You could just write message = actual, operator = '!=', stackStartFunction = undefined as part of the function arguments, right?

This comment has been minimized.

@Trott

Trott Apr 11, 2017

Member

There are at least three issues with that.

First, that introduces additional behavior changes I was hoping to avoid.

Current behavior preserved in this PR:

> assert.fail()
AssertionError: undefined undefined undefined

With the default parameters change:

> assert.fail()
AssertionError: undefined != undefined

Second, it breaks the two-argument feature added here.

Current PR:

> assert.fail('first', 'second');
AssertionError: 'first' != 'second'

With the suggested change:

> assert.fail('first', 'second')
AssertionError: first

Third, and most importantly, it breaks one of the two current usable argument combinations for the function.

Current behavior also preserved in this PR:

> assert.fail('first', 'second', undefined, 'operator')
AssertionError: 'first' operator 'second'

With the default parameters as suggested replacing the arguments.length checks:

> assert.fail('first', 'second', undefined, 'operator')
AssertionError: first

There's no doubt a way around this, and maybe the problem is my lack of familiarity with default parameters?

@Trott

Trott Apr 11, 2017

Member

There are at least three issues with that.

First, that introduces additional behavior changes I was hoping to avoid.

Current behavior preserved in this PR:

> assert.fail()
AssertionError: undefined undefined undefined

With the default parameters change:

> assert.fail()
AssertionError: undefined != undefined

Second, it breaks the two-argument feature added here.

Current PR:

> assert.fail('first', 'second');
AssertionError: 'first' != 'second'

With the suggested change:

> assert.fail('first', 'second')
AssertionError: first

Third, and most importantly, it breaks one of the two current usable argument combinations for the function.

Current behavior also preserved in this PR:

> assert.fail('first', 'second', undefined, 'operator')
AssertionError: 'first' operator 'second'

With the default parameters as suggested replacing the arguments.length checks:

> assert.fail('first', 'second', undefined, 'operator')
AssertionError: first

There's no doubt a way around this, and maybe the problem is my lack of familiarity with default parameters?

Show outdated Hide outdated test/parallel/test-assert-fail.js

@Trott Trott referenced this pull request Apr 11, 2017

Closed

8.0.0 Release Proposal #12220

@targos

targos approved these changes Apr 12, 2017

@targos targos added the ctc-review label Apr 12, 2017

Trott added some commits Apr 9, 2017

assert: improve assert.fail() API
assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'
tools: remove assert.fail() lint rule
assert.fail() has been updated to accept a single argument so that is no
longer an error. Remove lint rule that checks for assert.fail() with a
single argument.
test: remove common.fail()
common.fail() was added to paste over issues with assert.fail() function
signature. assert.fail() has been updated to accept a single argument so
common.fail() is no longer necessary.
@Trott

This comment has been minimized.

Show comment
Hide comment

Trott added a commit to Trott/io.js that referenced this pull request Apr 12, 2017

assert: improve assert.fail() API
assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Trott added a commit to Trott/io.js that referenced this pull request Apr 12, 2017

tools: remove assert.fail() lint rule
assert.fail() has been updated to accept a single argument so that is no
longer an error. Remove lint rule that checks for assert.fail() with a
single argument.

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Trott added a commit to Trott/io.js that referenced this pull request Apr 12, 2017

test: remove common.fail()
common.fail() was added to paste over issues with assert.fail() function
signature. assert.fail() has been updated to accept a single argument so
common.fail() is no longer necessary.

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

@Trott Trott added lts-watch-v6.x and removed ctc-review labels Apr 12, 2017

@Trott Trott added this to the 8.0.0 milestone Apr 12, 2017

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Apr 12, 2017

Member

Landed in 758b8b6, 6f202ef, and 06c29a6.

Even though this is currently labeled semver-major, I'm marking it for lts-watch-v6.x on the grounds that:

  • It's not clear that it's actually semver-major.
  • If it is semver-major, it's barely semver-major.
  • Our LTS policy allows us to land semver-majors in some cases.
  • This touches a big enough number of files that there is potential for many merge conflicts in back porting if it doesn't land.

Not going to fervently make the case that it needs to land in v6.x, just want it to be considered. @nodejs/lts

Leaving dont-land-on-v4.x because that's in maintenance mode and should only get minimal updates anyway.

Member

Trott commented Apr 12, 2017

Landed in 758b8b6, 6f202ef, and 06c29a6.

Even though this is currently labeled semver-major, I'm marking it for lts-watch-v6.x on the grounds that:

  • It's not clear that it's actually semver-major.
  • If it is semver-major, it's barely semver-major.
  • Our LTS policy allows us to land semver-majors in some cases.
  • This touches a big enough number of files that there is potential for many merge conflicts in back porting if it doesn't land.

Not going to fervently make the case that it needs to land in v6.x, just want it to be considered. @nodejs/lts

Leaving dont-land-on-v4.x because that's in maintenance mode and should only get minimal updates anyway.

@Trott Trott closed this Apr 12, 2017

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Apr 13, 2017

Member

@sam-github

Node.js 7.9.0 and earlier:

> assert.fail('one arg')
AssertionError: 'one arg' undefined undefined
...
> assert.fail(1, 2)
AssertionError: 1 undefined 2
...

With this change:

> assert.fail('one arg')
AssertionError: one arg
...
> assert.fail(1, 2)
AssertionError: 1 != 2
...
Member

Trott commented Apr 13, 2017

@sam-github

Node.js 7.9.0 and earlier:

> assert.fail('one arg')
AssertionError: 'one arg' undefined undefined
...
> assert.fail(1, 2)
AssertionError: 1 undefined 2
...

With this change:

> assert.fail('one arg')
AssertionError: one arg
...
> assert.fail(1, 2)
AssertionError: 1 != 2
...
@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Apr 13, 2017

Member

@aqrln thanks, but nodes=win-vs2015 doesn't have a testReport :(

Member

refack commented Apr 13, 2017

@aqrln thanks, but nodes=win-vs2015 doesn't have a testReport :(

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Apr 13, 2017

Member

@Trott Thanks, very helpful. Doesn't look semver-major to me.

Add this to my list of why node shouldn't expose its internal utility functions as APIs.

Member

sam-github commented Apr 13, 2017

@Trott Thanks, very helpful. Doesn't look semver-major to me.

Add this to my list of why node shouldn't expose its internal utility functions as APIs.

@refack refack referenced this pull request Apr 19, 2017

Closed

[wip] path: improve parse => format combination #12511

0 of 4 tasks complete

@cjihrig cjihrig referenced this pull request Apr 25, 2017

Merged

test: add cwd ENOENT known issue test #12343

3 of 3 tasks complete

@refack refack referenced this pull request Apr 26, 2017

Closed

Retire fedora22 buildbot? #688

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Jun 18, 2017

Member

This should land with #12343 if it lands on v6.x.

Member

gibfahn commented Jun 18, 2017

This should land with #12343 if it lands on v6.x.

@gibfahn gibfahn referenced this pull request Jun 18, 2017

Closed

Review semver-minor backports #228

5 of 8 tasks complete

@targos targos referenced this pull request Jul 18, 2017

Closed

[v6.x backport] tools: update ESLint to v4.0.0 #14340

2 of 2 tasks complete

@refack refack referenced this pull request Jul 23, 2017

Merged

assert: fix assert.fail with zero arguments #13974

4 of 4 tasks complete
@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Aug 14, 2017

Member

@nodejs/lts do we want to backport this?

Member

MylesBorins commented Aug 14, 2017

@nodejs/lts do we want to backport this?

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Sep 19, 2017

Member

I think yes, it touched ~50 test files, if we don't backport it we'll get conflicts soon (or already?) when backporting tests.

Member

sam-github commented Sep 19, 2017

I think yes, it touched ~50 test files, if we don't backport it we'll get conflicts soon (or already?) when backporting tests.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Sep 19, 2017

Member

Gave a quick look, its got lots of conflicts, so will need some backport TLC if we agree we want it.

Member

sam-github commented Sep 19, 2017

Gave a quick look, its got lots of conflicts, so will need some backport TLC if we agree we want it.

@BridgeAR

This comment has been minimized.

Show comment
Hide comment
@BridgeAR

BridgeAR Sep 19, 2017

Member

I am also +1 for backporting. Out of my perspective this use case is the only suitable one for assert.fail() and it is actually weird that it used to use more arguments than one.

Member

BridgeAR commented Sep 19, 2017

I am also +1 for backporting. Out of my perspective this use case is the only suitable one for assert.fail() and it is actually weird that it used to use more arguments than one.

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Sep 19, 2017

Member

@BridgeAR does #14427 make assert.fail usable in v6.x?

Member

refack commented Sep 19, 2017

@BridgeAR does #14427 make assert.fail usable in v6.x?

Trott added a commit to Trott/io.js that referenced this pull request Sep 19, 2017

assert: improve assert.fail() API
assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Trott added a commit to Trott/io.js that referenced this pull request Sep 19, 2017

tools: remove assert.fail() lint rule
assert.fail() has been updated to accept a single argument so that is no
longer an error. Remove lint rule that checks for assert.fail() with a
single argument.

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Trott added a commit to Trott/io.js that referenced this pull request Sep 19, 2017

test: remove common.fail()
common.fail() was added to paste over issues with assert.fail() function
signature. assert.fail() has been updated to accept a single argument so
common.fail() is no longer necessary.

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 19, 2017

Member

Backport #15479

Member

Trott commented Sep 19, 2017

Backport #15479

Trott added a commit to Trott/io.js that referenced this pull request Sep 29, 2017

assert: improve assert.fail() API
assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Trott added a commit to Trott/io.js that referenced this pull request Sep 29, 2017

tools: remove assert.fail() lint rule
assert.fail() has been updated to accept a single argument so that is no
longer an error. Remove lint rule that checks for assert.fail() with a
single argument.

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Trott added a commit to Trott/io.js that referenced this pull request Sep 29, 2017

test: remove common.fail()
common.fail() was added to paste over issues with assert.fail() function
signature. assert.fail() has been updated to accept a single argument so
common.fail() is no longer necessary.

PR-URL: nodejs#12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 10, 2017

assert: improve assert.fail() API
assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 10, 2017

tools: remove assert.fail() lint rule
assert.fail() has been updated to accept a single argument so that is no
longer an error. Remove lint rule that checks for assert.fail() with a
single argument.

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 10, 2017

test: remove common.fail()
common.fail() was added to paste over issues with assert.fail() function
signature. assert.fail() has been updated to accept a single argument so
common.fail() is no longer necessary.

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 10, 2017

assert: improve assert.fail() API
assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 10, 2017

tools: remove assert.fail() lint rule
assert.fail() has been updated to accept a single argument so that is no
longer an error. Remove lint rule that checks for assert.fail() with a
single argument.

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 10, 2017

test: remove common.fail()
common.fail() was added to paste over issues with assert.fail() function
signature. assert.fail() has been updated to accept a single argument so
common.fail() is no longer necessary.

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

@MylesBorins MylesBorins referenced this pull request Oct 17, 2017

Merged

v6.12.0 proposal #16263

MylesBorins added a commit that referenced this pull request Oct 25, 2017

assert: improve assert.fail() API
assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.

This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.

assert.fail('boom');
// AssertionError: boom

assert.fail('a', 'b');
// AssertionError: 'a' != 'b'

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 25, 2017

tools: remove assert.fail() lint rule
assert.fail() has been updated to accept a single argument so that is no
longer an error. Remove lint rule that checks for assert.fail() with a
single argument.

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Oct 25, 2017

test: remove common.fail()
common.fail() was added to paste over issues with assert.fail() function
signature. assert.fail() has been updated to accept a single argument so
common.fail() is no longer necessary.

Backport-PR-URL: #15479
PR-URL: #12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

@MylesBorins MylesBorins referenced this pull request Nov 3, 2017

Merged

v4.8.6 proposal #16500

MylesBorins added a commit that referenced this pull request Nov 6, 2017

2017-11-07, Version 6.12.0 'Boron' (LTS)
Notable Changes:

* assert:
  - assert.fail() can now take one or two arguments (Rich Trott)
    #12293
* crypto:
  - add sign/verify support for RSASSA-PSS (Tobias Nießen)
    #11705
* deps:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu)
    #16691
  - upgrade libuv to 1.15.0 (cjihrig)
    #15745
  - upgrade libuv to 1.14.1 (cjihrig)
    #14866
  - upgrade libuv to 1.13.1 (cjihrig)
    #14117
  - upgrade libuv to 1.12.0 (cjihrig)
    #13306
* fs:
  - Add support for fs.write/fs.writeSync(fd, buffer, cb) and
    fs.write/fs.writeSync(fd, buffer, offset, cb) as documented
    (Andreas Lind) #7856
* inspector:
  - enable --inspect-brk (Refael Ackermann)
    #12615
* process:
  - add --redirect-warnings command line argument (James M Snell)
    #10116
* src:
  - allow CLI args in env with NODE_OPTIONS (Sam Roberts)
    #12028)
  - --abort-on-uncaught-exception in NODE_OPTIONS (Sam Roberts)
    #13932
  - allow --tls-cipher-list in NODE_OPTIONS (Sam Roberts)
    #13172
  - use SafeGetenv() for NODE_REDIRECT_WARNINGS (Sam Roberts)
    #12677
* test:
  - remove common.fail() (Rich Trott)
    #12293

PR-URL: #16263

MylesBorins added a commit that referenced this pull request Nov 7, 2017

2017-11-07, Version 6.12.0 'Boron' (LTS)
Notable Changes:

* assert:
  - assert.fail() can now take one or two arguments (Rich Trott)
    #12293
* crypto:
  - add sign/verify support for RSASSA-PSS (Tobias Nießen)
    #11705
* deps:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu)
    #16691
  - upgrade libuv to 1.15.0 (cjihrig)
    #15745
  - upgrade libuv to 1.14.1 (cjihrig)
    #14866
  - upgrade libuv to 1.13.1 (cjihrig)
    #14117
  - upgrade libuv to 1.12.0 (cjihrig)
    #13306
* fs:
  - Add support for fs.write/fs.writeSync(fd, buffer, cb) and
    fs.write/fs.writeSync(fd, buffer, offset, cb) as documented
    (Andreas Lind) #7856
* inspector:
  - enable --inspect-brk (Refael Ackermann)
    #12615
* process:
  - add --redirect-warnings command line argument (James M Snell)
    #10116
* src:
  - allow CLI args in env with NODE_OPTIONS (Sam Roberts)
    #12028)
  - --abort-on-uncaught-exception in NODE_OPTIONS (Sam Roberts)
    #13932
  - allow --tls-cipher-list in NODE_OPTIONS (Sam Roberts)
    #13172
  - use SafeGetenv() for NODE_REDIRECT_WARNINGS (Sam Roberts)
    #12677
* test:
  - remove common.fail() (Rich Trott)
    #12293

PR-URL: #16263

msoechting added a commit to hpicgs/node that referenced this pull request Feb 7, 2018

2017-11-07, Version 6.12.0 'Boron' (LTS)
Notable Changes:

* assert:
  - assert.fail() can now take one or two arguments (Rich Trott)
    nodejs#12293
* crypto:
  - add sign/verify support for RSASSA-PSS (Tobias Nießen)
    nodejs#11705
* deps:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu)
    nodejs#16691
  - upgrade libuv to 1.15.0 (cjihrig)
    nodejs#15745
  - upgrade libuv to 1.14.1 (cjihrig)
    nodejs#14866
  - upgrade libuv to 1.13.1 (cjihrig)
    nodejs#14117
  - upgrade libuv to 1.12.0 (cjihrig)
    nodejs#13306
* fs:
  - Add support for fs.write/fs.writeSync(fd, buffer, cb) and
    fs.write/fs.writeSync(fd, buffer, offset, cb) as documented
    (Andreas Lind) nodejs#7856
* inspector:
  - enable --inspect-brk (Refael Ackermann)
    nodejs#12615
* process:
  - add --redirect-warnings command line argument (James M Snell)
    nodejs#10116
* src:
  - allow CLI args in env with NODE_OPTIONS (Sam Roberts)
    nodejs#12028)
  - --abort-on-uncaught-exception in NODE_OPTIONS (Sam Roberts)
    nodejs#13932
  - allow --tls-cipher-list in NODE_OPTIONS (Sam Roberts)
    nodejs#13172
  - use SafeGetenv() for NODE_REDIRECT_WARNINGS (Sam Roberts)
    nodejs#12677
* test:
  - remove common.fail() (Rich Trott)
    nodejs#12293

PR-URL: nodejs#16263
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment