➜ 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)
Summary
Observed that the greenwood-getting-started repo after the v0.29.0 release has started emitting this warning from WCC
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)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 theconsole.log
So the question is:
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
Will open an issue downstream with WCC.