Add "type" to context API to control render strategy

[jaybeeuu]

Is your feature request related to a problem? Please describe.

I would like to add a link to a file to my report. For example intuitively doing something like:

addContext(this, { title: 'My file', value: './file.txt' });

In practice it looks like this falls through the cracks of the regexp used to identify the type of the context and gets rendered as text. I have found that this can be the case for some other context types also - you end up second guessing the rules (or as i did looking up the source) and crafting your context values in order to have mochawesome render them correctly.

Describe the solution you'd like

It would be nice to tell mochawesome how I would like it to render the context I have given it by supplying a type. For example:

addContext(this, { title: 'My file', value: './file.txt', type: `link` });

Falling back to the existing regexp if no "type" has been supplied would maintain back compatibility.

If a type has been supplied i would expect mochawesome to trust that I have given it a correctly formatted URL and render it as a link without changing it in any way. i.e. without adding a protocol for example.

Describe alternatives you've considered

This could be solved by increasing the complexity of the regexp which is already in place - I think that is a bad choice because:

1. Adding a type is simpler, both too maintain, and to use.
2. There are likely more edge cases that have not been solved by this regexp that a type would also solve.

Additional context

I think this library is great and I would be happy to have a crack at implementing this if you would like and would accept a PR. :)

[adamgruber]

I have found that this can be the case for some other context types also

Can you explain this more? Which other types are problematic?

What other types would you consider aside from link?

[jaybeeuu]

Hey @adamgruber, sorry i got distracted with some other life stuff.

To answer your questions;

Can you explain this more? Which other types are problematic?

I was having some trouble with images - I went back repro'd it and it turns out to be a subtly different, but related, problem and I think my proposal would solve the issue too.

(For reasons) we have image names like -ahd3fh4.png or f3sch5a.png which we would like to embed with relative src. In the latter case (without the -) the regexp here identifies it as a url without a protocol & prefixes it - breaking the link. I have worked around it be prefixing all file names with - but it would be nicer not to have to.

The part of my proposal whereby specifying the type would prompt mochawesome to use the supplied value verbatim would solve the problem.

What other types would you consider aside from link?

I would suggest all the context types currently supported via autodetection. i.e. url, image, base64Image, video, text & data. It seems like that would be the least surprising thing to do.

In future of course this strategy would lubricate the way to supporting other types, for example, markdown (would that ever be useful?) or user supplied custom renderers.

[mistic100]

I second this request.

My use case : Mochawesome is used in Cypress, where I also generate a text file containing the browser logs. I do not want to add the whole log to the context, as it can be very long. So I have a context similar to OP :

cy.addTestContext({
    title: 'logs file',
    value: `./${Cypress.spec.name}.txt`,
});

I would like this to render as a link with a relative path.

---

Also supporting markdown content could be useful.