Skip to content
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

feat: transform file paths into hyperlinks #8980

Merged
merged 7 commits into from
Oct 14, 2019

Conversation

lekterable
Copy link
Contributor

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:
Zrzut ekranu 2019-09-25 o 19 33 57

Hyperlink in ITerm2 when hovered with CMD pressed:
Zrzut ekranu 2019-09-25 o 19 15 11

Hyperlink in Terminal.app without a fallback:
Zrzut ekranu 2019-09-25 o 19 16 14
^ 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
Copy link

codecov-io commented Sep 25, 2019

Codecov Report

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

Impacted file tree graph

@@            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.

Copy link
Contributor

@jeysal jeysal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@thymikee
Copy link
Collaborator

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
Copy link
Contributor Author

@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
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Contributor

jeysal commented Sep 26, 2019

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

Copy link
Member

@SimenB SimenB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@rogeliog rogeliog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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

@lekterable lekterable changed the title WIP feat: transform file paths into hyperlinks feat: transform file paths into hyperlinks Oct 2, 2019
@jeysal
Copy link
Contributor

jeysal commented Oct 2, 2019

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
Copy link
Contributor Author

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

@lekterable
Copy link
Contributor Author

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

@jeysal
Copy link
Contributor

jeysal commented Oct 13, 2019

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

Copy link
Contributor

@jeysal jeysal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

const call = terminalLink.mock.calls[0];

expect(terminalLink).toHaveBeenCalled();
expect(call[0]).toBe(formatTestPath(globalConfig, testResult.testFilePath));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

great, thorough review, thanks for that!

Copy link
Contributor

@jeysal jeysal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

thymikee added a commit that referenced this pull request May 2, 2020
thymikee added a commit that referenced this pull request May 2, 2020
thymikee added a commit that referenced this pull request May 2, 2020
thymikee added a commit that referenced this pull request May 2, 2020
thymikee added a commit that referenced this pull request May 2, 2020
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add hyperlinks in default reporter
7 participants