Importing CSS as string shouldn't also inject it into HTML's head

tbroyer commented 3 years ago

Describe the bug

When importing a CSS as string, e.g.

import styles from "./styles.css";

the CSS is also extracted into a CSS file and injected into the HTML's head. This means that the CSS is duplicated as both "pure CSS" and a JavaScript String. This cause bloats and could also cause conflicts if the strings are intended to be injected into shadow doms, isolated from each another (a .foo selector in one shadow dom can be a completely different .foo in another one, and of course of a .foo in the main page; those isolated stylesheets could also use element selectors: a, etc. as they're intended to be isolated into a shadow dom). The JS String is also not minified, which contributes to the bloat.

I can't see a reason why one would want both behaviors at the same time, and even then there would also be an easy workaround if one really wanted it:

import "./styles.css"; // inject the stylesheet into the HTML
import styles from "./styles.css"; // get the stylesheet's content as a JS string

(this is why I'm filing this as a bug report; feel free to reclassify as a request for enhancement)

Reproduction

See https://github.com/covidtrackerfr/vitemadose-front, deployed at https://vitemadose.covidtracker.fr The project imports the styles as string to inject them into web components' shadow DOM.

The styles/global.scss here is duplicated both in the generated assets/index.*.css and as a JS string, but that's expected as it's imported both "for side-effects" (import "./styles/global.scss", to apply to the HTML page content) and "as string" (import globalCss from "../styles/global.scss", to be injected into web components' shadow dom, as they're isolated from the page). (this is bad as it leads to 222KB of duplicated content, but that's another issue, unrelated to Vite; the JS string is not minified CSS though, with >11KB of line breaks, and I haven't even looked at white space; this probably deserves a separate issue though).

All other stylesheets are only imported as strings, but they also end up in the assets/index.*.css file, unnecessarily. In this project, fortunately (or because they've been coded that way as a workaround), they don't cause conflicts, only bloat.

System Info

Output of npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers:

  System:
    OS: Linux 5.11 Arch Linux
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
    Memory: 877.99 MB / 15.52 GB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 16.0.0 - /usr/bin/node
    Yarn: 1.22.10 - /usr/bin/yarn
    npm: 7.11.2 - /usr/bin/npm
  Browsers:
    Firefox: 88.0
  npmPackages:
    vite: 2.1.5 => 2.1.5

Used package manager: npm

Before submitting the issue, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the docs.
[x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[x] Provide a description in this issue that describes the bug.
[x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[x] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

patak-dev commented 3 years ago

For reference, there were already some discussions about this in this PR https://github.com/vitejs/vite/pull/2148#issuecomment-784738508

tmayr commented 3 years ago

Sort of a +1, same use case regarding shadow-dom.

And at least in my use case, using the CSS as string not only duplicates the output as @tbroyer mentions, but also, HMR doesn't seem to trigger on the string on updates. Maybe this should be filled as a different bug tho. It's just a bit more obvious when dealing with shadow-dom, as the update only appends to <head> and not visible at all to the shadow-dom.

franktopel commented 3 years ago

This makes Vite essentially a non-option when developing web components.

What we've been using when configuring our previous build stack was explicitly excluding files named *.shadow.css from being bundled into the css bundle for the whole application.

Maybe such a convention-based configuration option would make this easier to implement?

css: { exclude: ['**/*.shadow.css'] }

This would still allow bundling CSS for web components/modules that don't use shadow DOM or rely on the styling information from the light DOM (in case of web components using slots).

franktopel commented 3 years ago

Please consider implementing this in a way that seems likely to be compatible with the upcoming CSS module scripts.

urapadmin commented 3 years ago

Same problem here, importing sass into a lit component. All the styles occur additionally in a style.css. Could anybody find at least a workaround for the time being?

tarnishablec commented 3 years ago

Same problem here, importing sass into a lit component. All the styles occur additionally in a style.css. Could anybody find at least a workaround for the time being?

use ?inline and manually insert style string to component

urapadmin commented 3 years ago

Same problem here, importing sass into a lit component. All the styles occur additionally in a style.css. Could anybody find at least a workaround for the time being?

use ?inline and manually insert style string to component

I am not sure I understand. You mean I should write the css inline into the component directly instead of importing an external file?

franktopel commented 3 years ago

import styles from "./styles.css?inline";

urapadmin commented 3 years ago

import styles from "./styles.css?inline";

that is more than a workaround. It solves it for me. Thanks a bunch!

patak-dev commented 3 years ago

Closing this issue. See https://github.com/vitejs/vite/commit/e1de8a888ea9adb9dc415cf74aec43dfa83aa526 for reference 👍🏼

vitejs / vite