Support loading of CSS results / Constructable Stylesheets

[glromeo]

I am working on a project where we follow this pattern to style our custom elements:

import styles from "./my-element-style.css";

class MyElement extends LitElement {
  get styles() {
    return styles;
  }
}

There is a build that generates "my-element-style.css.js" from "my-element-style.scss" using node-sass and wrapping the css text in:

import {css} from "lit-element";
export default cssResult = css`.my-element-class {...}`

Since this pattern is the suggested from open-wc I thought it would be nice to have a css bundler in snowpack doing the work for us so that we can simply import the sass file.

This would require the bundler to behave differently from what it does at the moment because the javascript proxy should export the css result rather than loading it in the page.

I think it's worth considering this extension because it means that the bundler can support constructable stylesheets and custom elements with shadow dom.

[FredKSchott]

Thanks for creating this discussion! Right now, we support this with our existing plugin API, but only if you use a custom file extension in your source file (ex: my-element-style.css.txt).

As mentioned in another thread, we could allow you to override the default CSS loader, but it just makes it very easy to do so in a way that breaks bundlers since CSS is one of the native web build outputs that we support for bundling.

[glromeo]

I tried writing a plugin-lit-css that extends the lit-sass plugin:

const toCssResult = code => `// [snowpack] lit-css wrapper
import {css} from "/web_modules/lit-element.js";
export default css\`
    ${code.replace(/([$`\\])/g, "\\$1")}
\``;

module.exports = function litCssPlugin(_, pluginOptions) {

    const pluginSass = require("../plugin-sass/plugin").apply(this, arguments);

    return {
        name: "@snowpack/plugin-lit-css",
        resolve: {
            input: ['.scss', '.sass'],
            output: ['.lit-css.js'],
        },
        onChange({filePath}) {
            pluginSass.onChange({filePath});
        },
        async load({filePath, isDev}) {
            const contents = await pluginSass.load({filePath, isDev});
            return toCssResult(contents);
        }

    };
};

with the intent of providing .lit-css.js files.

The first obstacle I ran into was that the function:

export function getInputsFromOutput(fileLoc: string, plugins: SnowpackPlugin[]) {
  const srcFile = replaceExt(fileLoc, '.map', ''); // if this is a .map file, try loading source
  const {baseExt} = getExt(srcFile);

  const potentialInputs = new Set([srcFile]);
  for (const plugin of plugins) {
    if (plugin.resolve && plugin.resolve.output.includes(baseExt)) {
      plugin.resolve.input.forEach((input) =>
        potentialInputs.add(replaceExt(srcFile, baseExt, input)),
      );
    }
  }
  return Array.from(potentialInputs);

by using baseExt instead of extendedExt doesn't let a plugin have .whatever.js extensions which I thought would have been meaningful because I want the file to be treated as .js from the pipeline from this stage on.
So I hacked getInputsFromOutput and I moved on but then I ran into another issue which is finalizeResponse where:

      // Verify that the requested file exists in the build output map.
      if (!output[requestedFileExt] || !Object.keys(output)) {
        return null;
      }
      const {code, map} = output[requestedFileExt];

gives me null despite my output has my intended key. I am not sure about the meaning of that if. It makes sense to bail out if the output doesn't have the extension required but again since requestedFileExt is just .js that again stops plugin developers from loading .ext.js.
I tried something like

      let matchingExtendedExt = Object.keys(output).find(key => key.endsWith(requestedFileExt));
      if (!matchingExtendedExt) {
        return null;
      }
      const {code, map} = output[matchingExtendedExt];

and my example lit-element project works as expected! 🎉

Do you think an approach like this could work?

[glromeo]

@FredKSchott let me know your thoughts about #1909, that would solve the problems I mentioned in my previous post

[FredKSchott]

Nice! Looking forward to taking a look at that PR

[claviska]

I've been struggling with this today and it's by far the biggest pain point I've run into with Snowpack. My use case is custom elements that need to have styles inlined rather than injected into the head.

I was hoping to do something like this:

import styles from 'my-element.scss'; // using snowpack's sass plugin

class MyElement extends HTMLElement {
  constructor() {
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.innerHTML = `
      <style>${styles}</styles>
      ...
    `;
  }
}

Unfortunately, the closest I've come to something that works is a hacky plugin that grabs the Sass file, processes it, and injects the resulting CSS with a nasty string replace. Alas, this approach means style changes don't reload the dev server.

@FredKSchott: Right now, we support this with our existing plugin API, but only if you use a custom file extension in your source file (ex: my-element-style.css.txt).

After seeing this, I may try to use PostCSS and the .pcss extension next. Appreciate the tip!

[sanmai-NL]

@claviska Have you arrived at a better solution in the meantime?

[claviska]

No, sorry, I ended up using esbuild.

[sanmai-NL]

esbuild with snowpack? I use that too.

[claviska]

Just esbuild

[andrewlevada]

I think this might be just the best solution of this problem: https://github.com/calebdwilliams/snowpack-lit-scss-plugin