Is grey currently only used for stack trace lines that point to node internals? If so, perhaps we should use a different color for cwd to avoid confusion?

@mscdex

Is grey currently only used for stack trace lines that point to node internals?

Yes, currently only node internal stack frames are grey. It was meant as "this is probably not important" (no matter what it represented), focus on the rest.

If so, perhaps we should use a different color for cwd to avoid confusion?

Do you have a concrete suggestion? I fear using colors would actually highlight the cwd instead of moving it to the background.

@tniessen

I am wondering if it would be better to use the directory containing the first package.json instead. The cwd is not necessarily where the code is (even though it probably is most of the time).

This would require util.inspect() to read files in directories sync and that is something I would rather not do. If code is run somewhere that has nothing to do with the cwd, the whole path is still visible. If it is the cwd, it's probably fine to just move it to the background as it's something "already known", no matter if the code is run there or not (some code has to be run there, otherwise it's not going to be marked grey).

@tniessen

I am wondering if it would be better to use the directory containing the first package.json instead. The cwd is not necessarily where the code is (even though it probably is most of the time).

This would require util.inspect() to read files in directories sync and that is something I would rather not do. If code is run somewhere that has nothing to do with the cwd, the whole path is still visible. If it is the cwd, it's probably fine to just move it to the background as it's something "already known", no matter if the code is run there or not (some code has to be run there, otherwise it's not going to be marked grey).

I totally get that, and I don't object to using the working directory. I just thought we are probably reading the package.json anyway at some point (e.g., to check if it's a "type": "module") so we might as well use that directory.

@tniessen I just tried to figure out how to implement something like that and could not think of a good way to do so. We do not always have a package.json or have multiple ones in different sub directories, in what case I would only want to grey out the main part, not the sub directory for the executed code. Could you give me a hint how you would implement something like that and how it would behave for the mentioned situations? That would help :-)

@BridgeAR That does make it difficult, you are right. I am not too worried about using cwd, we can probably change the exact conditions later without breaking anything (if we ever want to).

We could, maybe, determine a prefix of all loaded JS modules, but that seems out of scope here, and I am not even sure if that would be reliable.

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

@tniessen I agree, we can definitely improve the implementation later. Are you fine with the change as is in general?

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

Are you fine with the change as is in general?

It seems reasonable to me. The only super tiny nit I have is that, personally, I believe that the first / should be gray as well (e.g., highlight test.js instead of /test.js) because the highlighted part of the path should be relative to cwd, not an absolute path.

I updated it to be a relative path:

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

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

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

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

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

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

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

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

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

Landed in 2fe4e94...7cfd5f1