using csz's file import in snowpack setup breaks the dev server's hmr.

i have put this question on pika discuss forum as well. putting it here as i think its intertwined with snowpack’s way of importing css files. i have one component.css file which i am importing like this in component.tsx file.

const componentStyle = css`/component.css`

// usage
<div className={componentStyle}>
// ..some html here//
</div>

since this css file is not imported using top level import but is inside csz’s template literal. any changes made to this landing.css file doesn’t reflect … i have to restart the snowpack’s dev server to see the new changes. i explored my sources tab in chrome’s console tool. since snowpack didn’t encountered any import of css file it was not served and hence this doesn’t work. but some where down the line csz’s framework takes care of that adding the style to the dom. i am not sure this is the ideal scenario for snowpack to pick up file (which is not imported using import but is inside css string literal )and serve it. is there a setup or repo which i can use it as a reference where csz is used in a snowpack setup and also css files are imported in .jsx/.tsx files.

[lukejacksonn]

Ahh cool. So maybe my assumptions about HMR getting all its graph data from parsing code wasn’t correct then 😅

Regards relative links, it wasn’t really a choice either! This was due to lack of support for import.meta which allows you to infer the location of the location of the calling script. From there you can build up relative paths.

Until then I think we are stuck with absolute links… but I would be interesting in seeing an implementation ready for when import meta is standardised!

[Manish3323]

Sure thing. i have put this same question on pika discuss also .i’m sure the moderators will have say in this. meanwhile i’ll learn about es-module-shims.