Represent externalised attachments as their own message
- Dominant language
- No language data
- Stars
- 3.4k
- Forks
- 679
- PR merge metrics
- No merged PRs in 30d
Description
### 🤔 What's the problem you're trying to solve?
This is a product of a discussion in Discord, which I will attempt to summarize here.
I maintain a Cypress library whose goal is to implement the Cucumber experience in the Cypress domain. Cypress has an option to record videos in case of test failures, which is useful to put into reports - especially the HTML report, where they can be viewed inline.
A video can be large. A typical, naive message writer and a reader will both read attachments into memory, during writing and parsing, in leue of streaming based JSON writers/readers.
In Cypress, these videos appear on FS after a run, IE. they are _already externalized_.
We came to the conclussion that a pragmatic approach is to emit Attachment envelopes indicating an already externalized attachment, as compared to leaving the job of externalizing it up to the formatter.
The Attachment type on the other hand has a required `body` attribute. I propose to make it optional.
Personally, I enjoy union types in TS, something along the lines of `Attachment = InlineAttachment | ExternalAttachment`, which would leave little room to mix up `body` and `url`.
### ✨ What's your proposed solution?
Make the `body` attribute optional, possible even making the Attachment type a union type, as described above.
### ⛏ Have you considered any alternatives or workarounds?
I can forcefully work around TS and emit an Attachment without body, which the HTML formatter will happily accept and render correctly. However, it feels a bit hacky.
### 📚 Any additional context?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.