Bjorn Lu

We currently [don't generate sourcemaps for JSON files](https://github.com/vitejs/vite/blob/f367453ca2825bc8a390d41c5d13b161756f2b41/packages/vite/src/node/plugins/json.ts#L83) so the mapping for `e=JSON.parse(...),` part should've been a [single length segment](https://tc39.es/ecma426/#sec-mappings) that signals not mapping to anything. Looks like right now...

The repro link doesn't look right, but here's a [repro](https://stackblitz.com/edit/github-rdbeht?file=src%2Fpages%2Findex.astro,src%2Fcomponents%2FTest.astro) based on the description. This seems to be a compiler issue.

No issues for me too.

Closing as it's caused by a browser extension

I didn't notice this was caused by the built-in translator in Chrome too. Perhaps there's more to look into in that case. Re-opening.

Since `@import` with globs isn't part of the [spec](https://developer.mozilla.org/en-US/docs/Web/CSS/@import), I think we should introduce a new API if we want to support this, and `@import-glob` might be the best choice....

Interesting, maybe rewriting the plugin with Postcss 8's plugin would solve this issue, so we don't have to carve out an API to put plugins before Vite's (which I'm not...

Can you resolve the conflict? I can't do it here as it looks like your repo has blocked maintainer edits.

Re no1, I suppose the only way it to test against EPERM errors and stat the filesystem again for the new change, but you won't be able to find out...

That's fair. Another option is to figure out a workaround on macos, maybe there's a system/bash command that could fix this [like linux](https://vite.dev/guide/troubleshooting.html#requests-are-stalled-forever).