CSS build errors not shown in dev mode when using Lit SSR

[lschierer]

Type of Change

Bug

Summary

build and dev mode show different behaviors with typescript. Something that works in dev should at least build.

Details

• if you check out https://github.com/lschierer/greenwood-repoductions/tree/bare-css-typescript (note the branch)
• look at the header.ts file in components. there are 3 import lines, 2 of which are commented out.
  • The first, as I understand it, is the recommended way to import. This does not work at all.
  • The second will run with
    pnpm run dev
    but will show a runtime error saying it cannot find the module. The component will not render. If you run
    pnpm run build
    you will be told

ReferenceError [Error]: CSSStyleSheet is not defined
    at file:///Users/lschiere/src/schierer/greenwood-repoductions/node_modules/.pnpm/@[email protected]/node_modules/@spectrum-css/tokens/dist/index.css:1:15
    at ModuleJob.run (node:internal/modules/esm/module_job:268:25)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:543:26)
    at async executeRouteModule (file:///Users/lschiere/src/schierer/greenwood-repoductions/node_modules/.pnpm/@[email protected]_@[email protected][email protected]/node_modules/@greenwood/plugin-renderer-lit/src/execute-route-module.js:18:7)
    at async executeModule (file:///Users/lschiere/src/schierer/greenwood-repoductions/node_modules/.pnpm/@[email protected]/node_modules/@greenwood/cli/src/lib/ssr-route-worker.js:6:16)
    at async MessagePort.<anonymous> (file:///Users/lschiere/src/schierer/greenwood-repoductions/node_modules/.pnpm/@[email protected]/node_modules/@greenwood/cli/src/lib/ssr-route-worker.js:12:3)

• The third will run with pnpm run dev and the component will render. However, if you run pnpm run build you get

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/node_modules/@spectrum-css/tokens/dist/index.css' imported from /Users/lschiere/src/schierer/greenwood-repoductions/src/components/header.ts
  at finalizeResolution (node:internal/modules/esm/resolve:257:11)
  at moduleResolve (node:internal/modules/esm/resolve:913:10)
  at defaultResolve (node:internal/modules/esm/resolve:1037:11)
  at nextResolve (node:internal/modules/esm/hooks:748:28)
  at resolve (file:///Users/lschiere/src/schierer/greenwood-repoductions/node_modules/.pnpm/@[email protected]/node_modules/@greenwood/cli/src/loader.js:91:10)
  at nextResolve (node:internal/modules/esm/hooks:748:28)
  at Hooks.resolve (node:internal/modules/esm/hooks:240:30)
  at handleMessage (node:internal/modules/esm/worker:199:24)
  at Immediate.checkForMessages (node:internal/modules/esm/worker:141:28)
  at process.processImmediate (node:internal/timers:491:21) {
code: 'ERR_MODULE_NOT_FOUND',
url: 'file:///node_modules/@spectrum-css/tokens/dist/index.css'
}

This has been reproduced with 0.30.2 and with 0.31.0-alpha.0

This description has been updated to remove portions that were not in fact bugs but reflected failures of my understanding.

[thescientist13]

So there are a couple of issues here but to try and break them down

it will fail saying that HTMLElement is not defined in header.ts.

So the issue here is that Lit's SSR capability does not support native HTMLElement, which is what is happening when the prerender: true flag is being set in your greenwood.config.js. So basically if you are using Lit + SSR, you would always have to be using LitElement base class.

I could have sworn I had this called out in the caveat's section but it is not there, so I have opened a PR to document this, so thanks for catching this! 👀

edit: I agree not seeing the error during development is annoying, and so we plan to bring the prerender workflow to development soon - #1249

---

also using the 0.31.0 alpha.0 release, in my HP_Stuff repo that I've used in other reports, I see that the line
import SpectrumCard from "@spectrum-css/card/dist/index.css" with { type: "css" };
works in dev mode, but results in a module not found error at build. I've not yet reproduced that one in the greenwood-reproductions repo because I keep hitting various other type not defined errors at build like noted just above.

Based on the demo repo I have been validating these changes in, I was able to confirm all the Spectrum JS and CSS imports work in both dev and prod builds and you can see a production build here hosted on Vercel.
https://greenwood-lit-ssr-yp27-git-demo-74cdbd-thescientist13s-projects.vercel.app

Do note I use the bare specifier when calling it from JavaScript
https://github.com/thescientist13/greenwood-lit-ssr/pull/24/files#diff-722cfecf5ea0a6fe1f48c236297b7945594a72d211a78bc5680de5bfbf85a8afR12

import SpectrumCard from '@spectrum-css/card' with { type: 'css' };

console.log({ SpectrumCard });

The path you're using looks to be more of their recommendation when using @import in a CSS file
https://github.com/adobe/spectrum-css?tab=readme-ov-file#including-assets

Let me add an example of the CSS flavor that to that demo though just to make sure I don't forget any use cases.

(Also keeping in mind this is all in alpha stage, I would ask that we use Discord for this kind of pre-release feedback, or the existing issue if one exists to help keep the conversations in one place)

[thescientist13]

So added a demonstration of using @import but found an issue when the @imports are nested within another @import that seems specific to usage with node_modules, so let me look into getting that out in the next alpha release for all this ecosystem compat work. 👍

[lschierer]

Oh. I forgot to put I had also tested in 0.30.2, what I was actually trying to type was that it was still there.

[thescientist13]

Oh. I forgot to put I had also tested in 0.30.2, what I was actually trying to type was that it was still there.

Sorry, could you clarify to which of the above points you are referring to here?

[lschierer]

when I filed the bug, I first observed the behaviors listed with

    "@greenwood/cli": "~0.30.2",
    "@greenwood/plugin-google-analytics": "^0.30.2",
    "@greenwood/plugin-postcss": "^0.30.2",
    "@greenwood/plugin-renderer-lit": "^0.30.2",
    "@greenwood/plugin-typescript": "^0.30.2",

and then upgraded to the alpha to see if the changes fixed them. I reported only after seeing that they persisted. From our further discussions, I realize that the first bullet point about the html element is almost certainly me misunderstanding the prerendering and the lit renderer plugin, so I'm exploring that more.

[lschierer]

Updated the description to reflect the part that remains an outstanding bug now that you've explained things to me. The tip of the branch now has a better minimal reproduction.

[thescientist13]

look at the header.ts file in components. there are 3 import lines, 2 of which are commented out.

Hmm, I'm not seeing the commented out lines that you reference in your description?
https://github.com/lschierer/greenwood-repoductions/blob/bare-css-typescript/src/components/header.ts

That said, this error

ReferenceError [Error]: CSSStyleSheet is not defined

This Is unfortunately expected when using Lit+SSR for prerendering or SSR routes. The is item no. 3 in the caveats section
https://github.com/ProjectEvergreen/greenwood/tree/master/packages/plugin-renderer-lit#caveats

I think they are open to PRs adding it to their DOM Shim though.

The third will run with pnpm run dev and the component will render. However, if you run pnpm run build you get

Because of the above issue, I don't see any other error and maybe also because I don't see that example in the branch you shared? 🤔

---

I think this is better tracked as discussion for now as we work through the multiple items being covered here Q & A style (we can have one comment thread per item that way if the migration doesn't get too funky), and then happy to extract any reproductions we find into their own issue once we've landed on them concretely.

[lschierer]

okay, so after playing with the css loaders in the thread that links to for a while, and hitting all sorts of errors that are far from intuitive, I decided to try using lit elements without using the lit renderer.

https://github.com/lschierer/greenwood-repoductions/blob/no-lit/src/components/test-element.ts is the result.

on the main index page, if you run pnpm run dev on that, it'll display an example table. In the file on lines 7-20 you can see several different versions of the import for @spectrum-css/tokens. Each behaves slightly differently. I've not fully tested in that I didn't run the serve command after the build command. I know from past experience that some things that build do not render correctly.

[thescientist13]

//fails in dev mode, because the module path does not start with . or /,
//able to buildif prerender is false.
//tsc does not like this.
//import SpectrumTokens from "@spectrum-css/tokens" with { type: "css" };

So this one should be working though when using the latest alpha, right? (I see in that package.json you are on 0.30.2)

//fails in dev mode with a 404 error on the css page request.
//able to buildif prerender is false.
//tsc does not like this.
//import SpectrumTokens from "/node_modules/@spectrum-css/tokens/" with { type: "css" };

Yeah, for dev mode this is more likely an issue with where PNPM installs things (Greenwood only assumed node_modules are in the same root directory as your greenwood.config.js) and so while not solved in v0.30.0-alpha.0, we will make specifiers that users manually start with /node_modules work as well.

//works in develop mode
//fails in build mode, Error: ENOENT: no such file or directory, open '/node_modules/@spectrum-css/tokens/dist/index.css'
//tsc prefers this version so long as declaration.d.ts (or a file with its contents) exists.
import SpectrumTokens from "/node_modules/@spectrum-css/tokens/dist/index.css" with { type: "css" };

Same reason as above regarding assumed location of node_modules directory, so let me get v0.31.0-alpha.1 out and this should probably work as expected. Will make notes of these to either confirm and / or make sure to improve the documentation, favoring bare specifiers for node modules (in theory using /node_modules/path/to/thing/ would only be needed in rare exceptions but would still like it to support the same resolution logic as we are doing for import maps, so it just works the same either way 🤞 )

//These two imports need to be adjusted to whichever verseion of the token's import you pick from above, or the error(s) will simply move to these lines.
import SpectrumTypography from "/node_modules/@spectrum-css/typography/dist/index.css" with { type: "css" };
import SpectrumTable from "/node_modules/@spectrum-css/table/dist/index.css" with { type: "css" };

Seems similar as above I think.

---

Thanks for providing all this feedback, will keep these in mind for my internal testing of all this PNPM / no hardcoding of node_modules location, and definitely this will also help in making sure its clearer in the docs what patterns are recommended for when, but ideally Greenwood will work either way, just need to align the resolution algorithm.

Good news is though we should be able to get v0.31.0-alpha.1 out pretty soon!

[thescientist13]

Confirmed that with the latest patches based on #1341 that this is all working now just using bare specifiers, which is generally preferred when working with resources in node_modules.
https://github.com/thescientist13/greenwood-lit-ssr/pull/24/files#diff-4aedfcc4bc035e4a438404691562927ff873d8d2a1f6afa126ea8f020ae27a45R12

import SpectrumCard from '@spectrum-css/card' with { type: 'css' };
import SpectrumTokens from "@spectrum-css/tokens" with { type: "css" };

console.log({ SpectrumCard, SpectrumTokens });

And can also confirm that this would work in CSS as well (although still need to fix (#1338, which I will work on tomorrow)
https://github.com/thescientist13/greenwood-lit-ssr/pull/24/files#diff-25d6a3ff17a1c8acb9b8e63e990597d94ef65730407b2e171edbf73b7515df3d

@import url('/node_modules/@spectrum-web-components/styles/all-large-dark.css');

---

So seems like this and #1301 should all get resolved after the next alpha release, which I will plan to release this weekend

[thescientist13]

On the topic of CSSStyleSheet is not defined error, I presented on this issue from the Lit SSR caveats section and specifically asked if they would open to an issue / PR adding minimal support for a CSSStyleSheet implementation in their DOM Shim (like WCC has) and they were open to it. 🥳

So here is the new issue I made to follow along to and I will see if I can get a PR to them next weekend to help remove this entire caveat from using Lit+SSR (in Greenwood). Should be a quick one and not much to review, so don't expect it will take too long to see it merged and published from their end. 🤞

[lschierer]

Thanks for the update , fingers crossed indeed.