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

util: change sparse arrays inspection format #11576

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
9 participants
@aqrln
Member

aqrln commented Feb 27, 2017

Missing elements in sparse arrays used to be serialized to empty placeholders delimited with commas by util.inspect() and in some cases the result was a syntactically correct representation of a JavaScript array with shorter length than the original one. This PR implements @TimothyGu's suggestion to change the way util.inspect() formats sparse arrays to something similar to how Firefox shows them.

Fixes: #11570

image

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

util

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Feb 27, 2017

Member

Existing tests are updated, but I'll add a couple of new ones.

UPD: already added.

Member

aqrln commented Feb 27, 2017

Existing tests are updated, but I'll add a couple of new ones.

UPD: already added.

Show outdated Hide outdated lib/util.js
index++;
}
if (emptyElements > 0) {
output.push(ctx.stylize(`[${emptyElements} empty]`, 'special'));

This comment has been minimized.

@TimothyGu

TimothyGu Feb 27, 2017

Member

I still stand by my opinion of using 'undefined' as the color, though I'm not going to block this PR if that's what others prefer.

@TimothyGu

TimothyGu Feb 27, 2017

Member

I still stand by my opinion of using 'undefined' as the color, though I'm not going to block this PR if that's what others prefer.

This comment has been minimized.

@aqrln

aqrln Feb 27, 2017

Member

Well, let's wait and see what others think about it. If there's no specific preference, I'll change it to 'undefined'.

@aqrln

aqrln Feb 27, 2017

Member

Well, let's wait and see what others think about it. If there's no specific preference, I'll change it to 'undefined'.

Show outdated Hide outdated test/parallel/test-util-inspect.js
@@ -832,12 +832,12 @@ checkAlignment(new Map(big_array.map(function(y) { return [y, null]; })));
// Do not backport to v5/v4 unless all of
// https://github.com/nodejs/node/pull/6334 is backported.
{
const x = Array(101);
const x = ','.repeat(100).split(','); // array of 101 empty strings

This comment has been minimized.

@TimothyGu

TimothyGu Feb 27, 2017

Member

new Array(101).fill() might be more semantically correct.

@TimothyGu

TimothyGu Feb 27, 2017

Member

new Array(101).fill() might be more semantically correct.

This comment has been minimized.

@aqrln

aqrln Feb 27, 2017

Member

Right, thanks.

@aqrln

aqrln Feb 27, 2017

Member

Right, thanks.

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Feb 27, 2017

Member

@TimothyGu I've updated the PR to use the 'undefined' color instead of the 'special' one. It indeed seems better.

Member

aqrln commented Feb 27, 2017

@TimothyGu I've updated the PR to use the 'undefined' color instead of the 'special' one. It indeed seems better.

@evanlucas

This comment has been minimized.

Show comment
Hide comment
@evanlucas

evanlucas Feb 27, 2017

Member

I'm on the fence on this one...leaning slightly towards keep existing behavior. I'm not sure that this is in fact more readable... going ahead and marking as semver-major though

Member

evanlucas commented Feb 27, 2017

I'm on the fence on this one...leaning slightly towards keep existing behavior. I'm not sure that this is in fact more readable... going ahead and marking as semver-major though

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Feb 27, 2017

Member

@evanlucas yes, certainly semver-major. An alternative solution that is at least similar to existing behavior yet solves the issue is to add an extra comma if the last element of a sparse array is missing.

Member

aqrln commented Feb 27, 2017

@evanlucas yes, certainly semver-major. An alternative solution that is at least similar to existing behavior yet solves the issue is to add an extra comma if the last element of a sparse array is missing.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Feb 27, 2017

Member

I agree with @evanlucas. I think something a bit more clear would be desired e.g. [3 empty indices skipped]. Not sure that's saving anything then though so...

Member

Fishrock123 commented Feb 27, 2017

I agree with @evanlucas. I think something a bit more clear would be desired e.g. [3 empty indices skipped]. Not sure that's saving anything then though so...

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Feb 27, 2017

Member

I don't feel strongly about it one way or another but one fairly compact approach is to use one . for each omitted index... e.g.

[1, 2, {...}, 6, 7] // three index positions skipped
[1, 2, {..}, 5, 6, 7] // two index positions skipped
[1, 2, {..........}, 13, 14] // ten index positions skipped
Member

jasnell commented Feb 27, 2017

I don't feel strongly about it one way or another but one fairly compact approach is to use one . for each omitted index... e.g.

[1, 2, {...}, 6, 7] // three index positions skipped
[1, 2, {..}, 5, 6, 7] // two index positions skipped
[1, 2, {..........}, 13, 14] // ten index positions skipped
@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Feb 27, 2017

Member

@Fishrock123 changed it to be

> new Array(3)
[ [3 uninitialized elements] ]
> [1, 2, , , , 3, 4, 5]
[ 1, 2, [3 uninitialized elements], 3, 4, 5 ]
> [1, 2, , , , 3, 4, 5, , 2]
[ 1,
  2,
  [3 uninitialized elements],
  3,
  4,
  5,
  [1 uninitialized element],
  2 ]
Member

aqrln commented Feb 27, 2017

@Fishrock123 changed it to be

> new Array(3)
[ [3 uninitialized elements] ]
> [1, 2, , , , 3, 4, 5]
[ 1, 2, [3 uninitialized elements], 3, 4, 5 ]
> [1, 2, , , , 3, 4, 5, , 2]
[ 1,
  2,
  [3 uninitialized elements],
  3,
  4,
  5,
  [1 uninitialized element],
  2 ]
@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Feb 27, 2017

Member

@TimothyGu looks like this is somewhat controversial 😄 As I already suggested above, a better solution might be to leave the current format with a small addition: if a sparse array doesn't have its last element, just append an extra dangling comma. This way the output of util.format() will not be contradicting JavaScript syntax and #11570 will be fixed, though the other way. What do you think about it?

Member

aqrln commented Feb 27, 2017

@TimothyGu looks like this is somewhat controversial 😄 As I already suggested above, a better solution might be to leave the current format with a small addition: if a sparse array doesn't have its last element, just append an extra dangling comma. This way the output of util.format() will not be contradicting JavaScript syntax and #11570 will be fixed, though the other way. What do you think about it?

}
const remaining = value.length - index;

This comment has been minimized.

@addaleax

addaleax Feb 27, 2017

Member

Shouldn’t this be value.length - visisbleLength?

@addaleax

addaleax Feb 27, 2017

Member

Shouldn’t this be value.length - visisbleLength?

This comment has been minimized.

@aqrln

aqrln Feb 27, 2017

Member

No, it shouldn't. visibleLength is the count of... well, printed elements, i.e., 3 in case of [ 1, [10000 uninitialized elements], 2 ] (maybe the variable name isn't that great, though). remaining, on the other hand, is the count of real array indices which values were not printed.

@aqrln

aqrln Feb 27, 2017

Member

No, it shouldn't. visibleLength is the count of... well, printed elements, i.e., 3 in case of [ 1, [10000 uninitialized elements], 2 ] (maybe the variable name isn't that great, though). remaining, on the other hand, is the count of real array indices which values were not printed.

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Feb 27, 2017

Member

@jasnell well, this would be hard to format with respect to inspectOptions.maxArrayLength and inspectOptions.breakLength.

Member

aqrln commented Feb 27, 2017

@jasnell well, this would be hard to format with respect to inspectOptions.maxArrayLength and inspectOptions.breakLength.

@addaleax

addaleax approved these changes Feb 27, 2017 edited

LGTM

(edit: +1 to doing this and +1 to “uninitialized”)

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Feb 27, 2017

Member

if a sparse array doesn't have its last element, just append an extra dangling comma

No, though it's now "correct", it wouldn't be less confusing.

The goal for the message is to be 1) clear/unambiguous, and 2) concise.

Having an extra dangling comma at the end would indeed be unambiguous in the sense of ES compliance, but it would be confusing considering chances are people might have already gotten used to this quirk in Node.js.

That applies also to the suggestion to use {..} as well: it's simply not beginner-friendly.

At the same time, uninitialized seems to convey the same information as, only in a less concise fashion than empty.

Member

TimothyGu commented Feb 27, 2017

if a sparse array doesn't have its last element, just append an extra dangling comma

No, though it's now "correct", it wouldn't be less confusing.

The goal for the message is to be 1) clear/unambiguous, and 2) concise.

Having an extra dangling comma at the end would indeed be unambiguous in the sense of ES compliance, but it would be confusing considering chances are people might have already gotten used to this quirk in Node.js.

That applies also to the suggestion to use {..} as well: it's simply not beginner-friendly.

At the same time, uninitialized seems to convey the same information as, only in a less concise fashion than empty.

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Feb 28, 2017

Member

Having an extra dangling comma at the end would indeed be unambiguous in the sense of ES compliance, but it would be confusing considering chances are people might have already gotten used to this quirk in Node.js.

+1, good point.

So what about the placeholder message? Considering browser examples provided in #11570, I don't really like the way Chromium formats sparse arrays (it isn't less confusing when [undefined] and [undefined × 1] mean two completely different things), the format Firefox uses is more appealing to me, though the word "slots" is rather misleading. Speaking about the message we currently have in this PR, first of all, I think I can change the word element(s) to item(s) because not only it is shorter but it is also the term used in ... N more items message.

Hence the current variants:

  • "empty items"
  • "uninitialized items"

It would be great if anyone has better suggestions. @TimothyGu, @addaleax?

Member

aqrln commented Feb 28, 2017

Having an extra dangling comma at the end would indeed be unambiguous in the sense of ES compliance, but it would be confusing considering chances are people might have already gotten used to this quirk in Node.js.

+1, good point.

So what about the placeholder message? Considering browser examples provided in #11570, I don't really like the way Chromium formats sparse arrays (it isn't less confusing when [undefined] and [undefined × 1] mean two completely different things), the format Firefox uses is more appealing to me, though the word "slots" is rather misleading. Speaking about the message we currently have in this PR, first of all, I think I can change the word element(s) to item(s) because not only it is shorter but it is also the term used in ... N more items message.

Hence the current variants:

  • "empty items"
  • "uninitialized items"

It would be great if anyone has better suggestions. @TimothyGu, @addaleax?

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Feb 28, 2017

Member

I like “uninitialized” because it tells the user how that hole in the array actually came to be – it was simply not initialized to any particular value (except for when somebody does delete arr[i], but I’d say that doesn’t happen very often).

I’d be fine with any of {“empty”, “uninitialized”, “missing”} × {“item(s)”, “element(s)”}, though.

Member

addaleax commented Feb 28, 2017

I like “uninitialized” because it tells the user how that hole in the array actually came to be – it was simply not initialized to any particular value (except for when somebody does delete arr[i], but I’d say that doesn’t happen very often).

I’d be fine with any of {“empty”, “uninitialized”, “missing”} × {“item(s)”, “element(s)”}, though.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Mar 1, 2017

Member

@nodejs/ctc This needs another review from a CTC member. Also, is anybody objecting to the current format ([ 'foo', [1 uninitialized element], 'baz' ])?

Member

addaleax commented Mar 1, 2017

@nodejs/ctc This needs another review from a CTC member. Also, is anybody objecting to the current format ([ 'foo', [1 uninitialized element], 'baz' ])?

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Mar 1, 2017

Contributor

The square bracket use makes it a bit harder to parse. At a quick glance, it looks like a nested array.

Contributor

cjihrig commented Mar 1, 2017

The square bracket use makes it a bit harder to parse. At a quick glance, it looks like a nested array.

@jasnell

jasnell approved these changes Mar 1, 2017

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 1, 2017

Member

I'm good with the [ bracket but a { could work also. Either way I can live with it

Member

jasnell commented Mar 1, 2017

I'm good with the [ bracket but a { could work also. Either way I can live with it

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Mar 1, 2017

Contributor

That would read like an object literal. Maybe < and >. Maybe I'm reading into it too much :-)

Contributor

cjihrig commented Mar 1, 2017

That would read like an object literal. Maybe < and >. Maybe I'm reading into it too much :-)

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Mar 1, 2017

Member

@cjihrig, just wanted to suggest it :)

Member

aqrln commented Mar 1, 2017

@cjihrig, just wanted to suggest it :)

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Mar 1, 2017

Member

Also, what about s/element(s)/item(s) to be consistent with an existing "... N more items" message?

Member

aqrln commented Mar 1, 2017

Also, what about s/element(s)/item(s) to be consistent with an existing "... N more items" message?

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Mar 1, 2017

Member

I think it is a bit excessively long but I don't see good and descriptive options otherwise.

Well, I suppose empty is probably better than uninitialized?

Member

Fishrock123 commented Mar 1, 2017

I think it is a bit excessively long but I don't see good and descriptive options otherwise.

Well, I suppose empty is probably better than uninitialized?

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Mar 1, 2017

Member

uninitialized is more explicit and technically correct but empty is more concise. Though I'm fine with both and I can change it back to empty.

Are there any objections to <N empty item(s)>?

Member

aqrln commented Mar 1, 2017

uninitialized is more explicit and technically correct but empty is more concise. Though I'm fine with both and I can change it back to empty.

Are there any objections to <N empty item(s)>?

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Mar 1, 2017

Member

IMO regarding uninitialized:

  • It implies something is wrong, which may not be the case
  • Harder for newcomers to understand
Member

Fishrock123 commented Mar 1, 2017

IMO regarding uninitialized:

  • It implies something is wrong, which may not be the case
  • Harder for newcomers to understand
@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Mar 1, 2017

Member

I've updated the PR. @addaleax, @jasnell, does it still LGTY?

Member

aqrln commented Mar 1, 2017

I've updated the PR. @addaleax, @jasnell, does it still LGTY?

@TimothyGu

LGTM other than the two nits. Thanks for working on this!

assert(!/1 more item/.test(util.inspect(x, {maxArrayLength: 101})));
}
{
const x = new Array(101).fill();
assert(/^\[ ... 101 more items ]$/.test(
util.inspect(x, {maxArrayLength: 0})));

This comment has been minimized.

@TimothyGu

TimothyGu Mar 1, 2017

Member

nit: I know the regex is there already, but it doesn't seem to be needed, since assert.strictEqual(util.inspect(x, {maxArrayLength: 0}), '[ ... 101 more items ]') should accomplish the same.

@TimothyGu

TimothyGu Mar 1, 2017

Member

nit: I know the regex is there already, but it doesn't seem to be needed, since assert.strictEqual(util.inspect(x, {maxArrayLength: 0}), '[ ... 101 more items ]') should accomplish the same.

This comment has been minimized.

@aqrln

aqrln Mar 1, 2017

Member

I think it's better to open a new PR and change it for the whole group of tests here so that they look consistent and this PR doesn't modify the tests which are not related to its changes.

@aqrln

aqrln Mar 1, 2017

Member

I think it's better to open a new PR and change it for the whole group of tests here so that they look consistent and this PR doesn't modify the tests which are not related to its changes.

This comment has been minimized.

@aqrln

aqrln Mar 1, 2017

Member

Other that these two and analogous Uint8Array test (line 873), there are tests where a regex can be reduced to a simple .endsWith() check.

@aqrln

aqrln Mar 1, 2017

Member

Other that these two and analogous Uint8Array test (line 873), there are tests where a regex can be reduced to a simple .endsWith() check.

util.inspect(x, {maxArrayLength: 0})));
}
{
const x = Array(101);
assert(/^\[ ... 101 more items ]$/.test(
util.inspect(x, {maxArrayLength: 0})));

This comment has been minimized.

@TimothyGu

TimothyGu Mar 1, 2017

Member

Ditto.

@TimothyGu

TimothyGu Mar 1, 2017

Member

Ditto.

@cjihrig

cjihrig approved these changes Mar 1, 2017

@targos

targos approved these changes Mar 2, 2017

@addaleax addaleax added this to the 8.0.0 milestone Mar 4, 2017

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Mar 4, 2017

Member

@addaleax I guess CITGM failures aren't related to this patch

Member

aqrln commented Mar 4, 2017

@addaleax I guess CITGM failures aren't related to this patch

util: change sparse arrays inspection format
Missing elements in sparse arrays used to be serialized to empty
placeholders delimited with commas by util.inspect() and in some cases
the result was a syntactically correct representation of a JavaScript
array with shorter length than the original one. This commit implements
@TimothyGu's suggestion to change the way util.inspect() formats sparse
arrays to something similar to how Firefox shows them.

Fixes: #11570
@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Mar 7, 2017

Member

Squashed the commits into one.

Member

aqrln commented Mar 7, 2017

Squashed the commits into one.

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln
Member

aqrln commented Mar 9, 2017

@addaleax ping

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Mar 9, 2017

Member

@aqrln Thanks for the ping, I’m busy but I’ll land this later today if nobody beats me to it

Member

addaleax commented Mar 9, 2017

@aqrln Thanks for the ping, I’m busy but I’ll land this later today if nobody beats me to it

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Mar 10, 2017

Member

Landed in ec2f098, thanks for the PR!

Member

addaleax commented Mar 10, 2017

Landed in ec2f098, thanks for the PR!

@addaleax addaleax closed this Mar 10, 2017

addaleax added a commit that referenced this pull request Mar 10, 2017

util: change sparse arrays inspection format
Missing elements in sparse arrays used to be serialized to empty
placeholders delimited with commas by util.inspect() and in some cases
the result was a syntactically correct representation of a JavaScript
array with shorter length than the original one. This commit implements
@TimothyGu's suggestion to change the way util.inspect() formats sparse
arrays to something similar to how Firefox shows them.

Fixes: #11570
PR-URL: #11576
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

@aqrln aqrln deleted the aqrln:inspect-sparse-arrays branch Mar 10, 2017

@aqrln aqrln referenced this pull request Mar 10, 2017

Closed

test: refactor test-util-inspect.js #11779

2 of 2 tasks complete

aqrln added a commit to aqrln/node that referenced this pull request Mar 10, 2017

test: refactor test-util-inspect.js
* Enclose tests that used to introduce module-level variables into
  their own scopes.
* Replace ES5 anonymous functions with arrow functions where it makes
  sense.
* And make one arrow function a regular function thus fixing a bug in a
  getter inside an object created in "Array with dynamic properties"
  test.  This getter has never been invoked though, so the test hasn't been
  failing.
* Convert snake_case identifiers to camelCase.
* Make some variable names more readable.
* Replace regular expressions in maxArrayLength tests with simple
  assert.strictEquals() and assert(...endsWith()) checks, as suggested
  in <nodejs#11576 (comment)>.

jasnell added a commit that referenced this pull request Mar 15, 2017

test: refactor test-util-inspect.js
* Enclose tests that used to introduce module-level variables into
  their own scopes.
* Replace ES5 anonymous functions with arrow functions where it makes
  sense.
* And make one arrow function a regular function thus fixing a bug in a
  getter inside an object created in "Array with dynamic properties"
  test.  This getter has never been invoked though, so the test hasn't been
  failing.
* Convert snake_case identifiers to camelCase.
* Make some variable names more readable.
* Replace regular expressions in maxArrayLength tests with simple
  assert.strictEquals() and assert(...endsWith()) checks, as suggested
  in <#11576 (comment)>.

PR-URL: #11779
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

jungx098 added a commit to jungx098/node that referenced this pull request Mar 21, 2017

util: change sparse arrays inspection format
Missing elements in sparse arrays used to be serialized to empty
placeholders delimited with commas by util.inspect() and in some cases
the result was a syntactically correct representation of a JavaScript
array with shorter length than the original one. This commit implements
@TimothyGu's suggestion to change the way util.inspect() formats sparse
arrays to something similar to how Firefox shows them.

Fixes: nodejs#11570
PR-URL: nodejs#11576
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

jungx098 added a commit to jungx098/node that referenced this pull request Mar 21, 2017

test: refactor test-util-inspect.js
* Enclose tests that used to introduce module-level variables into
  their own scopes.
* Replace ES5 anonymous functions with arrow functions where it makes
  sense.
* And make one arrow function a regular function thus fixing a bug in a
  getter inside an object created in "Array with dynamic properties"
  test.  This getter has never been invoked though, so the test hasn't been
  failing.
* Convert snake_case identifiers to camelCase.
* Make some variable names more readable.
* Replace regular expressions in maxArrayLength tests with simple
  assert.strictEquals() and assert(...endsWith()) checks, as suggested
  in <nodejs#11576 (comment)>.

PR-URL: nodejs#11779
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

aqrln added a commit to aqrln/node that referenced this pull request Mar 21, 2017

test: refactor test-util-inspect.js
* Enclose tests that used to introduce module-level variables into
  their own scopes.
* Replace ES5 anonymous functions with arrow functions where it makes
  sense.
* And make one arrow function a regular function thus fixing a bug in a
  getter inside an object created in "Array with dynamic properties"
  test.  This getter has never been invoked though, so the test hasn't been
  failing.
* Convert snake_case identifiers to camelCase.
* Make some variable names more readable.
* Replace regular expressions in maxArrayLength tests with simple
  assert.strictEquals() and assert(...endsWith()) checks, as suggested
  in <nodejs#11576 (comment)>.

PR-URL: nodejs#11779
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

@jasnell jasnell referenced this pull request Apr 4, 2017

Closed

8.0.0 Release Proposal #12220

evanlucas added a commit that referenced this pull request May 2, 2017

test: refactor test-util-inspect.js
* Enclose tests that used to introduce module-level variables into
  their own scopes.
* Replace ES5 anonymous functions with arrow functions where it makes
  sense.
* And make one arrow function a regular function thus fixing a bug in a
  getter inside an object created in "Array with dynamic properties"
  test.  This getter has never been invoked though, so the test hasn't been
  failing.
* Convert snake_case identifiers to camelCase.
* Make some variable names more readable.
* Replace regular expressions in maxArrayLength tests with simple
  assert.strictEquals() and assert(...endsWith()) checks, as suggested
  in <#11576 (comment)>.

PR-URL: #11779
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment