Interesting. Thanks for raising the issue and PR. It looks like it makes sense to preserve import statements if possible.

I'm not too familiar with this, but just looking at your sample source map, I wonder if it affects Vitest's coverage (probably in a good way). I'll ping a Vitest member just in case.

@AriPerkkio Do you know if this changes anything on Vitest coverage? With your recent PR vitest-dev/vitest#5423, it looks like coverage will ignore lines without source map, but this fix would maybe add them back, so it's a good thing?

Yes, code coverage (both V8 and Istanbul) consider all code that is present in source maps as user's source code. We do some exclusion for lines that are just causing noise already: https://github.com/vitest-dev/vitest/blob/6157282cc04494afc85085775d1f565c0d0dbb5a/packages/coverage-v8/src/provider.ts#L385-L390. We might need to add these patterns there as well.

I actually ran into this same issue in another Vitest related issue. Debuggers cannot stop on top of files that Vite SSR transform has transpiled due to missing source maps on import statements: vitest-dev/vitest#5355 (comment)

I tried to do similar fix as in #16356 (AriPerkkio@3707b9a#diff-cfc76e75093a8c9e1513ea8238e17e2cfa0fbb5751a0f3d0d10ab157fbfab6f3) but eventually ended patching Vite-node's source maps so that it will always work: https://github.com/vitest-dev/vitest/blob/6157282cc04494afc85085775d1f565c0d0dbb5a/packages/vite-node/src/source-map.ts#L51-L54.

@AriPerkkio Thanks for chiming in! It's good to know you have investigated before.

I suppose fixing this would help ecosystem in general. I wonder if there are other heavy source map consumers other than Vitest and the OP of this issue. Depending on that, Vite team can maybe prioritize this.