What is the expected behavior for root & mount for loadConfiguration's API ?

[JulienPradet]

Hi there!

I've updated my project to Snowpack 3 that was using the beta API for loadConfiguration/startServer and I've noticed a behavior that I find a bit weird but I have a very specific use case so I'm not sure it would be an issue for normal users.

My project is a build tool that abstracts Snowpack (= having fun building a SvelteKit alternative). So my goal is to use a snowpack.config.json file that will never be in the user's folders but in the tool's folder instead. This means that in my snowpack.config.json, if I set mount: { src: "/" } I still want the src to be using the root passed to loadConfiguration, rather than the path of my snowpack.config.json.

// ./tool/cli.js
const snowpackConfig = await loadConfiguration(
  {
    root: path.join(__dirname, "../client"),
  },
  path.join(__dirname, "./snowpack.config.json")
);

// ./tool/snowpack.config.json
{
  "mount": {
    "src": "/"
  }
}

However, if I do this, the files in ./client/src are not properly loaded, because the root of the snowpack.config.json is ./tool/ instead of the one passed to loadConfiguration.

I have a workaround where I remove everything from the snowpack.config.json and put it directly in the config object in loadConfiguration. But this feels a bit odd to me. I would have expected that the root would impact the mount paths even if they come from the json file.

Here is a repo reproducing what I've explained above : https://github.com/JulienPradet/snowpack-ssr-root-issue
There is the master branch with the "issue" and the workaround branch that I've used in my project.

To see the error, you'd have to run:

yarn install
node cli/server.js

In the master branch, Snowpack has a mount issue while in the workaround branch, there is none and there should be a log with [snowpack] test.

If I don't make sense, feel free to tell me! I'll try a better explanation :D

And thank you all for your work on Snowpack! Such a great tool! 🙌

[FredKSchott]

How about using createConfiguration() instead? When you use that API, everything is relative to the root value instead of the loaded config file path. loadConfiguration() should really be used only to load a user's configuration file.

The extends config acts a bit more like what you want (everything extended is still relative to the user's root). You could also use that in combination with createConfiguration.

[JulienPradet]

Ah right! I missed this API. Works like a charm.

Thanks for the tip!