feat: transform file paths into hyperlinks

[lekterable]

Closes #8937

Summary

Straightforward change, file paths will now become hyperlinks in terminals that support it. In the ones that don't they will stay the same. I was thinking about displaying the paths somehow (flag??) as they are still clickable and quite useful in the Terminal.app even though they are not exactly hyperlinks.

I've used commonJS modules to import the lib as we don't have esModuleInterop flag in TS config, can you see any reasons for not using it?

Test plan

Hyperlink in ITerm2:

Hyperlink in ITerm2 when hovered with CMD pressed:

Hyperlink in Terminal.app without a fallback:

^ It's ugly, but useful which makes me wonder if it would be worth it to add some kind of flag for it.

[codecov-io]

Codecov Report

Merging #8980 into master will increase coverage by 0.01%.
The diff coverage is 80%.

@@            Coverage Diff             @@
##           master    #8980      +/-   ##
==========================================
+ Coverage    63.9%   63.92%   +0.01%     
==========================================
  Files         277      277              
  Lines       11652    11655       +3     
  Branches     2860     2860              
==========================================
+ Hits         7446     7450       +4     
  Misses       3576     3576              
+ Partials      630      629       -1

Impacted Files	Coverage Δ
packages/jest-reporters/src/get_result_header.ts	47.61% <80%> (+14.28%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 630350a...da3d6a7. Read the comment docs.

[jeysal]

Awesome! Looks like there's no downside to adding this either, given the fallback.
Can we add a test for this?

[thymikee]

I wonder, does it make sense to put this hyperlink there? It only works in iTerm, and there I can cmd+click the relative path anyway (at least on my environment) 🤔

[lekterable]

@thymikee actually it works in all terminals that support hyperlinks so it's not just ITerm and the list will get bigger [Link] and with fallback it shouldn't have an impact on the ones that don't so why not? 🤷‍♂ + even in ITerm the way hyperlink looks makes it more obvious that it's clickable

[thymikee]

Fair point. Now I'm not sure about the absolute paths, as they occupy a lot of space (we could make them less intrusive by dimming the color). And I'm not a fan of adding a flag for that. Maybe we could do this when there's a lot of demand for such feature?

[lekterable]

Agreed, it should be a pretty easy change of adjusting/conditionally removing the fallback if it's needed. Now regarding the test, do you have any ideas for it? I mean testing if it renders a hyperlink when supported would be kinda testing the library itself wouldn't it?

[jeysal]

I think in this case both would be fine:

• Testing that the hyperlink is printed correctly via the library in use (although I'm not sure how easy that is given that it depends on factors like the terminal in use) or
• Mocking the library and testing that it is called correctly and its result is printed

[SimenB]

Not sure if there's a test we can write that can reliably guard against a regression - happy to be proven wrong though 🙂

[rogeliog]

I think the fallback is key for this. So that this is just a progressive enhancement for some terminals, but keep the current behavior for other terminals

[lekterable]

added a test, @jeysal let me know if you have any suggestions

[jeysal]

Nice, that's about one of the options I was thinking of. Only thing that could be added is to mock a return value for terminal-link and check that it is in the output

[lekterable]

this should do it, what do you think @jeysal ?

[lekterable]

bump, I think this one should be ready to merge @jeysal @thymikee

[jeysal]

Sorry, I can assure you I haven't forgot about it, just been very busy. I'll take a look ASAP

[jeysal]

Alright I took another look and left a few nits on the test :)

[jeysal]

Would prefer if we hardcode the expected call argument values here without using formatTestPath/testResult, it kinda reimplements the production code this way and is not easy on the eye.
Also I think toHaveBeenCalledWith simplifies this a lot (4 lines to 1)?

[lekterable]

I've tried hardcoding the formatTestPath result by copy-pasting it from the console, but it contains the parts which are coloured by the chalk library and it seems to get lost when copied, any idea how could I keep it if we still want to go hardcode it?
btw. is reimplementing the production code in tests a bad practice? if so, what's exactly wrong with it?

[jeysal]

Could mock chalk like some other tests do so it just becomes something like <green>text</green>. But that's probably too complicated. Maybe just expect.stringContaining('the test path')?
What I mean re reimplementing: The reason we write tests is to run the code with specific example data that reproduces a case simple enough to wrap our heads around. If we could manage the complexity of all cases in all the code at once, we wouldn't need tests but could just look at the production code and see whether it's correct ;)

[lekterable]

That makes sense, thanks for the explanation @jeysal ! I've hardcoded the expected values, let me know if that's what you had in mind :)

[lekterable]

great, thorough review, thanks for that!

[jeysal]

Thanks a lot @lekterable! These are the kind of UX details that make Jest great! :)

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.