plugin-svelte sets compiler options incorrectly, leading to broken sourcemaps

[Rich-Harris]

The Svelte plugin has code like this:

const finalCompileOptions = {
  generate: isSSR ? 'ssr' : 'dom',
  css: false,
  ...compilerOptions, // Note(drew) should take precedence over generate above
  dev: isDev,
  outputFilename: filePath,
  filename: filePath,
};

filePath is the full path to the .svelte file, and is the correct setting for the filename compiler option. But outputFilename should not be filePath, it should be the name of the file that gets written to disk (i.e. /path/to/build/directory/Component.js) and there should be a corresponding cssOutputFilename like /path/to/build/directory/Component.css.

The filename, outputFilename and cssOutputFilename options are used together to populate the sources property of the generated sourcemap, which should typically look something like this:

{
  "version": 3,
  "names":[],
  "sources":["../../src/Component.svelte"],
  "sourcesContent":["..."],
  "mappings":"..."
}

Instead, because filePath is used for outputFilename and cssOutputFilename, the `sources array looks like this:

"sources":["Component.svelte"]

This makes it impossible to reliably locate the source of errors.

One option here would be for plugin load hooks to be passed information about where the output was going to be written to. That would allow the Svelte plugin to set the compiler options correctly.

Another possibility is for Snowpack to automatically set both sources and sourcesContent automatically after invoking load, overriding whatever was returned by the plugin:

map.sources = [path.relative(outputFilepath, filePath)];
map.sourcesContent = [fs.readFileSync(filePath, 'utf-8')];

That would alleviate the burden on plugin authors to figure this stuff out.

[Rich-Harris]

...though it did just occur to me that a plugin could theoretically need to control the sources and sourcesContent arrays itself, in the case where the code being transformed referenced other files that it depended on. So perhaps making output filenames available to plugins is preferable after all.

[FredKSchott]

This makes sense, and I'm on board with passing the output file location data to the load plugin hook.

One question: What should this value be in dev, when there is no build location on disk? During dev we only know the URL that requested the file.

We could pass undefined, or we could just fake it and pass the plugin the would-be build location as if it were running build. But I'm not really sure what's closer to expected behavior.

[FredKSchott]

If we passed filename: url.pathToFileURL(filePath) to the svelte compiler, would that work as expected? It feels like the issue for us is that map.sources is a relative path, which makes less sense in our model where source file is on disk but dev output may be loaded entirely in the browser.

[Rich-Harris]

Unfortunately no, it doesn't recognise file:// URLs as being absolute, which could be considered a bug in Svelte (though honestly I'm a bit fuzzy on what the norms are around sources in a situation like this). Will raise an issue for that on the Svelte tracker

[Rich-Harris]

Although this could be solved within the plugin if filePath was available, by the crude but effective method of mutating the sources array

[Rich-Harris]

It could also be solved by passing a file:// filename but not outputFilename, since if the latter is empty then filename is preserved:

js.map.sources = [
  compile_options.filename ? get_relative_path(compile_options.outputFilename || '', compile_options.filename) : null
];

[FredKSchott]

So are you saying that this should theoretically work?

const finalCompileOptions = {
  generate: isSSR ? 'ssr' : 'dom',
  css: false,
  ...compilerOptions, // Note(drew) should take precedence over generate above
  dev: isDev,
-  outputFilename: filePath,
-  filename: filePath,
+  filename: url. pathToFileURL(filePath),
};

If so would love a quick PR!