My CSS file gets build (using gulp-sass) with the CSS comment on the same line that the last } (I'm redacting a lot of CSS content before that, and the actual source map, as the file is huge):
.vertical-align-middle {
vertical-align: middle;
}/*# sourceMappingURL=data:application/json;charset=utf-8;base64,<REDACTED>*/
When my storybook setup tries to process this file in Vite (which uses this library), the logic fails.
Vite first tries to load from source, and then tries to load from file: https://github.com/vitejs/vite/blob/e6e9fc9e4cbefc482e068d03a19401fb7d9226cc/packages/vite/src/node/server/sourcemap.ts#L207-L213
Because commentRegex is anchored at the beginning of the line, fromSource will fail to match.
However, mapFileCommentRegex is not anchored and will match when attempting to fallback to fromMapFileSource.
This ends up passing data:application/json;charset=utf-8;base64,<REDACTED> as filename to the readMap function (which is not handled properly in Vite as it expects a file name and will attempt to read such file name, which triggers an error in the filesystem APIs due to the file name being too long).
To me, the root cause of the issue is in this convert-source-map package. fromSource should support comments that are not alone on their line, just like fromMapFileSource does. This would make the Vite code work correctly for that case as the data URI would be handled by ``fromSource`
My CSS file gets build (using
gulp-sass) with the CSS comment on the same line that the last}(I'm redacting a lot of CSS content before that, and the actual source map, as the file is huge):When my storybook setup tries to process this file in Vite (which uses this library), the logic fails.
Vite first tries to load from source, and then tries to load from file: https://github.com/vitejs/vite/blob/e6e9fc9e4cbefc482e068d03a19401fb7d9226cc/packages/vite/src/node/server/sourcemap.ts#L207-L213
Because
commentRegexis anchored at the beginning of the line,fromSourcewill fail to match.However,
mapFileCommentRegexis not anchored and will match when attempting to fallback tofromMapFileSource.This ends up passing
data:application/json;charset=utf-8;base64,<REDACTED>as filename to thereadMapfunction (which is not handled properly in Vite as it expects a file name and will attempt to read such file name, which triggers an error in the filesystem APIs due to the file name being too long).To me, the root cause of the issue is in this
convert-source-mappackage.fromSourceshould support comments that are not alone on their line, just likefromMapFileSourcedoes. This would make the Vite code work correctly for that case as the data URI would be handled by ``fromSource`