Can you add test for it?

OK, done.

Hmm, you don't need ?raw to get the CSS as a string - that's the default behavior already.

If ?raw is used, the returned css should be the raw, non-compiled CSS instead.

But if you don't add ?raw to get the CSS as a string, the css will change style

That's why I'm considering a change:

// gets the string, but does not insert
import css from './foo.css'

// insert on import, does not generate `export default ...`
import './foo.css'

But semantically es import syntax should not affect behavior so I'm still debating.

But semantically es import syntax should not affect behavior so I'm still debating.

I agree that it is better if they are semantically equivalent. Maybe adding a new special query for this?

// raw file content
import content from './foo.css?raw'

// gets the string, but does not insert
import css from './foo.css?detached'

// insert on import
import css from './foo.css'

Yeah I think another query is somewhat required for now. How about ?inline instead of ?detached?

Also note in the future there might be native behavior for CSS imports: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md (it will likely require a breaking change or a global option like css.importAs but that's when it actually lands.)

At least for me, ?inline makes me think the css will still be applied but it will be inlined in the file somehow (instead of having a separate .css)
Other options ?apart, ?disjoint, ?unused, ?inactive, ?unapply, ?separate, ?unconnect I saw while searching for a name in case they help

I think it's fine if we document it:

?inline allows you to get the compiled CSS as an inlined JavaScript string, however does not inject it automatically. You can manually control how/when to inject it (either by creating a <style> tag or via Constructable Stylesheets)

That's why I'm considering a change:

// gets the string, but does not insert
import css from './foo.css'

// insert on import, does not generate `export default ...`
import './foo.css'

This seems fine to me. The proposed behavior of each is intuitive.

It's exactly what we do in vite-plugin-mdx for "pre-built transclusion".
https://github.com/brillout/vite-plugin-mdx#pre-built-transclusion

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

Any news on this issue? The pull request is already 5 months old.
I would be really happy to see this issue be resolved. In its current state the import is broken for component development using shadow DOM.

This PR has been superseded by e1de8a8

There will be an ?inline in next release

This PR has been superseded by e1de8a8

There will be an ?inline in next release

Perhaps it would be worth adding it to the docs?
https://vitejs.dev/guide/assets.html#importing-asset-as-string

Has anybody been able to get this working when bundling with rollup (with typescript)? rollup-plugin-typescript2 will complain that the file doesn't exist, and it will give the exact location of the file... where it does in fact exist. I have tried @rollup/typescript but haven't been able to get that one to work for anything on multiple projects.

But I digress, using the inline I haven't been able to find a way to get rollup to work with it. During development with Vite it works no problem, but once you try to bundle it is when it won't cooperate.