"no custom element class found for this file" warning when prerendering with WCC

[thescientist13]

Summary

Observed that the greenwood-getting-started repo after the v0.29.0 release has started emitting this warning from WCC

➜  greenwood-getting-started git:(master) npm run build

> greenwood-getting-started@1.0.0 build
> greenwood build

-------------------------------------------------------
Welcome to Greenwood (v0.29.0) ♻️
-------------------------------------------------------
Initializing project config
Initializing project workspace contexts
Generating graph of workspace files...
building from local sources...
Running Greenwood with the build command.
pages to generate
 /blog/first-post/
 /blog/second-post/
 /
 /404/
No custom element class found for this file
generated page... /blog/first-post/
No custom element class found for this file
generated page... /blog/second-post/
No custom element class found for this file
generated page... /
No custom element class found for this file
generated page... /404/
success, done generating all pages!
bundling static assets...
optimizing static pages....
copying directory... src/assets/
copying file... src/assets/greenwood-logo.png
copying file... src/favicon.ico
copying file... .greenwood/manifest.json

Details

It seems as part of the addition of #1135 and us persisting the configuration to the document in a <script> tag (and this would likely also apply to GraphQL or static router)

<script>
  globalThis.__GWD_BASE_PATH__ = '';
</script>    

This is now being passed as a dependency URL to WCC in renderToHtml and because this script doesn't contain a custom element, it will "trip" this code in WCC which causes the console.log

So the question is:

1. Should WCC just ignore / swallow this? Would these chunks be needed to supplement dependencies passed into WCC?
2. Or should Greenwood be smart enough to figure out the right scripts to send to WCC?

---

I'm leaning towards 1 since after looking into it a bit, WCC is always assuming a valid custom element as the entry point, so this seems to warrant some basic error handling at minimum

async function renderToString(elementURL, wrappingEntryTag = true, props = {}) {
  // ...
  const elementInstance = await initializeCustomElement(elementURL, undefined, undefined, definitions, isEntry, props);

  const elementHtml = elementInstance.shadowRoot
    ? elementInstance.getInnerHTML({ includeShadowRoots: true })
    : elementInstance.innerHTML;
   
  //....
}

Will open an issue downstream with WCC.

[thescientist13]

Reported the issue with WCC - ProjectEvergreen/wcc#124