In an attemot to test SSR'ing of a component wrapping the <lightning-combobox> we came across an Error trying to execute renderToMarkup without any additional hint about what could possibly have gone wrong. After a lengthy debugging session trying to narrow down the culprit, we ended up seeing that taking the <lightning-base-combobox-item> out of the DOM suddenly made the complation at least pass. Looking into that component - trying to figure out the root cause - two things became apparent:
The component uses a custom render method conditionally returning one of two possible templates.
None of the two templates is using the component's name.
The moment we introduced a third template with the component's name (without even importing/referencing this template somewhere), the problem went away. So there must be a subtle issue/difference in the way the LWC compiler behaves in the test runner compared to other stacks like LWR or existing Jest tests.
In an attemot to test SSR'ing of a component wrapping the
<lightning-combobox>we came across an Error trying to executerenderToMarkupwithout any additional hint about what could possibly have gone wrong. After a lengthy debugging session trying to narrow down the culprit, we ended up seeing that taking the<lightning-base-combobox-item>out of the DOM suddenly made the complation at least pass. Looking into that component - trying to figure out the root cause - two things became apparent:rendermethod conditionally returning one of two possible templates.The moment we introduced a third template with the component's name (without even importing/referencing this template somewhere), the problem went away. So there must be a subtle issue/difference in the way the LWC compiler behaves in the test runner compared to other stacks like LWR or existing Jest tests.