CSS sourcemaps

[Rich-Harris]

Clear and concise description of the problem

CSS sourcemaps aren't currently supported, which can make it difficult to track down where a particular style was authored. It would be cool if they were preserved in both build (<link>) and dev (<style>) mode.

You can see this with a vanilla app (npm init @vitejs/app and choose 'vanilla'), and inspecting the #app styles in both dev and serve. In dev:

In serve:

Ideally the top right would say 'style.css' in both cases.

Suggested solution

I don't pretend to know exactly what would be involved, but elsewhere in the codebase magic-string is used for a similar purpose. Presumably the relevant plugin is https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/css.ts. I could take a run at it if someone gave me a pointer or two.

[dominikg]

I think I stumbled into this a while back 😔

vite/packages/vite/src/node/plugins/css.ts

Line 211 in fa85749

map: { mappings: '' }

the map could be available from the compileCss result a few lines above

[dominikg]

Spent some time on this recently and here's what i found.

• sourcemaps didn't work in vite1 too [1]
• simply returning the map from compileCss in vite:css [2] doesn't work [3] as it would need to be transformed to an actual SourceMap first [4]
• returning the correct sourcemap from vite:css alone does not help much, it needs to be passed on to the client too

Figuring out how to pass on the sourcemaps is different for dev and build, both coming with their own set of challenges.
During dev, css is served from special js modules managing style nodes on the fly. So i think the easiest shot at this would be to add inline sourcemaps to that.

For build it's a lot more difficult as css gets bundled too and sourcemaps have to be updated to reflect that and on top esbuild css minification needs to be accounted for too.

One Idea i had about this is to keep the css sourcemap inline as long as possible to avoid having to change any api where currently only code is passed on, extracting them to .map at the last second if it's configured for external.

Building all of this at once could prove challanging and hard to review, so i suggest to split it into smaller goals, which can be described in more detail separately and implemented on top of each other, for example

1. add inline sourcemap for dev - which seems to be the easiest to implement and most helpful for users
2. add build support for inline sourcemaps
3. extend build support to cover external sourcemap options

and also state which compromises can be made, eg

• no support for external sourcemaps on dev
• no support for hidden sourcemap on build (not a feature of esbuild css minification)
• ....

Would love some more 👀 on this.

-- links
[1] #649
[2] #4880
[3] #4939
[4] #4951

[benmccann]

I see there's a build.sourcemap option. Should that option be split into two? If there's an issue the in CSS sourcemap handling (which seems potentially likely for the first couple releases after it's added) it'd be nice to potentially be able to disable just it and leave the JS sourcemap support on.