| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Nit: a errror diff -> an error diff
The sentence seems to be missing some punctuation for clarity. Probably a comma after the second word?
Sorry, something went wrong.
There was a problem hiding this comment.
I am not sure, but maybe it is worth to separate the input with js label (for better highlighting and linting) and the output with diff label.
I cannot find any ```diff insets in .md files in this repo or nodejs.org repo. Are we sure they are rendered to the .html docs properly?
Sorry, something went wrong.
|
I just updated the code. I also improved the diffing algorithm from the first draft. It will now try to optimize the output rudimentary by removing identical lines from the back first, limits the output lines and some other smaller changes. So PTAL |
Sorry, something went wrong.
Sorry, something went wrong.
|
Rebased due to conflicts. I actually changed the tests to use the new assert.throws(fn, obj) pattern instead of try {} catch {} or common.expectsError. |
Sorry, something went wrong.
Sorry, something went wrong.
|
@nodejs/collaborators PTAL. This should be ready but it would be nice to get another LG. |
Sorry, something went wrong.
There was a problem hiding this comment.
We should probably be testing that unix color codes are supported on the current terminal.
Sorry, something went wrong.
There was a problem hiding this comment.
I don’t think we can test that but it might make sense to:
Sorry, something went wrong.
There was a problem hiding this comment.
That would indeed be nice... I will see what I can do but I am not sure if we can properly detect that.
Sorry, something went wrong.
There was a problem hiding this comment.
grammar nit: comma after the first that? Or maybe just start with Error messages which involve objects …?
Sorry, something went wrong.
There was a problem hiding this comment.
Can you name the different error diff modes? It’s really hard to keep track of constants 0, 1 and 2 with distinct meanings, especially in code that spans across files.
Sorry, something went wrong.
There was a problem hiding this comment.
I don’t think we can test that but it might make sense to:
Sorry, something went wrong.
|
@mcollina @addaleax I added a util.hasColors function. It is a very basic way to detect this but it seems like it is better than anything we had so far. As this is probably also something that other users might want to rely on, I added it to the util module, even though I am not sure if it is the best place for it. What do you think about that? @jasnell @Trott @vsemozhetbyt @TimothyGu please also take another look. |
Sorry, something went wrong.
There was a problem hiding this comment.
[stream][] — Missing bottom reference?
Sorry, something went wrong.
|
Rebased and new CI https://ci.nodejs.org/job/node-test-pull-request/12554/ I also addressed the doc comment. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
PR-URL: nodejs#17615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Right now it is very difficult to determine if a terminal supports colors or not. This function adds this functionality by detecting environment variables and checking process. Backport-PR-URL: #19230 PR-URL: #17615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Right now it is very difficult to determine if a terminal supports colors or not. This function adds this functionality by detecting environment variables and checking process. Backport-PR-URL: #19230 PR-URL: #17615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Notable changes:
* assert:
- From now on all error messages produced by `assert` in strict mode
will produce a error diff. (Ruben Bridgewater)
#17615
- From now on it is possible to use a validation object in throws
instead of the other possibilities. (Ruben Bridgewater)
#17584
* crypto:
- allow passing null as IV unless required (Tobias Nießen)
#18644
* fs:
- support as and as+ flags in stringToFlags() (Sarat Addepalli)
#18801
* tls:
- expose Finished messages in TLSSocket (Anton Salikhmetov)
#19102
* tty:
- Add getColorDepth function to determine if terminal supports colors
(Ruben Bridgewater) #17615
* util:
- add util.inspect compact option (Ruben Bridgewater)
#17576
* **Added new collaborators**
- [watson](https://github.com/watson) Thomas Watson
PR-URL: #19428
Notable changes:
* assert:
- From now on all error messages produced by `assert` in strict mode
will produce a error diff. (Ruben Bridgewater)
#17615
- From now on it is possible to use a validation object in throws
instead of the other possibilities. (Ruben Bridgewater)
#17584
* crypto:
- allow passing null as IV unless required (Tobias Nießen)
#18644
* fs:
- support as and as+ flags in stringToFlags() (Sarat Addepalli)
#18801
* tls:
- expose Finished messages in TLSSocket (Anton Salikhmetov)
#19102
* tty:
- Add getColorDepth function to determine if terminal supports colors
(Ruben Bridgewater) #17615
* util:
- add util.inspect compact option (Ruben Bridgewater)
#17576
* **Added new collaborators**
- [watson](https://github.com/watson) Thomas Watson
PR-URL: #19428
| return COLORS_16; | ||
|
|
||
| return COLORS_2; | ||
| }; |
There was a problem hiding this comment.
This code is mostly copy-pasted from https://github.com/chalk/supports-color/blob/master/index.js and https://github.com/isaacs/color-support/blob/master/index.js with minor style tweaks. I don't see any attribution.
Sorry, something went wrong.
There was a problem hiding this comment.
@BridgeAR can you comment on the above?
Sorry, something went wrong.
There was a problem hiding this comment.
Hey, I just came home and saw this, so I could not respond any earlier.
When writing on this I got the #17615 (comment) from @mcollina that I should check for the colors. So I googled a lot about checking color support in terminals and I tried to gather as much information as I could (I actually tried hard not to rely on environment variables at all). In the end I got inspired by multiple sources including chalk, color-support, different gists, stackoverflow and more that I do not remember. I did not think of anything bad when adding this function. I do see the similarities though and I am more than happy to give the attributions. I am just not sure how to do this properly right now as there are multiple licenses.
@sindresorhus shall I just move the function in a new file and add both license texts? I am not sure about the other sources though. Or would it be fine to add something like: This functionality got inspired by multiple sources including 'chalk' by @sindresorhus and 'color-support' by @isaacs?
Sorry, something went wrong.
There was a problem hiding this comment.
Ping @isaacs
Sorry, something went wrong.
There was a problem hiding this comment.
I guess also cc @nodejs/tsc FYI
Sorry, something went wrong.
There was a problem hiding this comment.
@BridgeAR
I think moving the color detection code to an internal lib file and put attributions there would be better than doing it in tty.js. But it still comes down to whether @sindresorhus and @isaacs accept it or not.
Sorry, something went wrong.
TTY tests should almost never be placed in `/parallel/`. Skipping TTY tests there due to missing tty fds just means they will never be run, ever, on any system. This moves the tty-get-color-depth test to `/pseudo-tty/` where the test runner will actually make a pty fd. Refs: nodejs#17615 PR-URL: nodejs#18800 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
From now on all error messages produced by `assert` in strict mode will produce a error diff. PR-URL: nodejs#17615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Instead of having three times the same RegExp, just use a helper. PR-URL: nodejs#17615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Right now it is very difficult to determine if a terminal supports colors or not. This function adds this functionality by detecting environment variables and checking process. PR-URL: nodejs#17615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
PR-URL: nodejs#17615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
TTY tests should almost never be placed in `/parallel/`. Skipping TTY tests there due to missing tty fds just means they will never be run, ever, on any system. This moves the tty-get-color-depth test to `/pseudo-tty/` where the test runner will actually make a pty fd. Refs: nodejs#17615 PR-URL: nodejs#18800 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
|
Requested backport to 8.x in #19230 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The current assert errors are actually pretty bad when it comes to objects. This implements
a simple way to add diffs as default but only in assert strict mode. It relies on another PR that changes the util.inspect output as I use that for the diff. Building the diff differently would likely yield better results but it would also mean more work and this on its own should already be a significant improvement.
So far a few spots are not optimized for performance and I would like to get some general feedback on the solution. I especially do not like the way to distinguish asserts strict mode and legacy mode.
Activating the diff always would mean we have to change all our assert tests and I did not want to do that, besides the fact that some people might partially rely on the message output.
Refs #17576
Checklist
Affected core subsystem(s)
assert, lib, util, errors