Choosing plugin (build/load) output directory on a per-file basis

[m4rrc0]

Hey,
I'd like to output a file in a different relative path than the one it is in the src folder.

Practically, I have a special directory src/_pages holding .svelte files and I would like to output an .html file for each one of these files to mount my .js files on. Obviously, these html files would need to be placed relative to the build/ directory directly instead of build/_dist_/_pages/.

Is that something you are willing to support?

I was thinking we could be able to define the output path in this kind of way:

// plugin.js
module.exports = function plugin(snowpackConfig, pluginOptions) {
  return {
    name: "name",
    resolve: {
      input: [".svelte"],
      output: [".js", ".css", ".html"],
    },
    async load({ contents, filePath, defaultOutputPath }) {
      // ... some implementation
      return {
        ".js": js && js.code,
        ".css": css && css.code,
        ".html": {
          output: htmlContent,
          outputPath: defaultOutputPath.replace("_dist_/_pages/", ""),
        },
      };
    },
  };
};

If outputPath is not provided, then Snowpack knows it is the default and in any case, it just needs to append the file extension to the path to create the file.

Incidentally, it would also allow for transforming the name of the output file if we want to set every file name as lowercase for example or create cleaner paths in any way...

[m4rrc0]

For reference, my current workaround for development is:

• using snowpack build instead of snowpack dev
• in my plugin, I fs.writeFile() my html files as needed
• then using nodemon as suggested in this comment to rebuild on change. nodemon -e js,svelte --watch src --exec 'snowpack build'
• I use another dev server to serve my static files

That is kind of cumbersome. haha... ^^

[FredKSchott]

This is a really interesting! I'd love to support this, although right now our build system assumes that file names don't change as a part of build, and I think moving the file path would fit that description.

It sounds like you need support to add new files inside of a plugin. Instead of having you modify and fork the official Svelte plugin, it would be better to give you a way to do this yourself (basic workflow: check each file in a build, if it lives in _pages/, output a new file to the build at a new path).

Lets give our new plugin system a few days to settle down post 2.7 release, and then would love to spin this into an official issue / would love a PR if you were interested in adding.

[m4rrc0]

I am happy to help on any PR that would go on the right direction. My static site generator (as discussed in this other thread) will be completely open source any way so anything you feel like supporting in core or official plugins, I am happy to help integrate.

Nonetheless, I am not sure it makes sense to give the 'canonical' svelte plugin too much functionality. I suppose most people using Svelte simply want a SPA. In that case, we would just clutter the plugin code base and make it harder to understand for anyone wanting to tweak it.

Moreover, a SSG usually makes some assumptions and, if not opinionated, provides defaults to lower the entry barrier. These assumptions and opinions should not be part of the svelte plugin.

Anyway, that is my case for 2 distinct plugins...

But coming back to this thread, I think generating random files from a plugin should be a core feature. It would allow easier integrations of custom code.
This issue is also symptomatic of the fact that we can't easily interact with what is going on with the dev server.
BTW, I didn't check the code but I suppose all files are kept in memory during dev?

A possibly easy solution to implement in core would be to have a devOption to build files 'for real' instead of keeping the dev process in memory. That way, anyone can simply mess with the files inside or outside of a plugin. No harm no foul.

A more elegant way, and also more generic that the one I suggested in my initial message, could be to expose a function -let's say writeSnowFile- that translates into a classic writeFile on build (when actual files are created) and into any other magical equivalent function to do the same on dev.
Then my example above would become:

// plugin.js
module.exports = function plugin(snowpackConfig, pluginOptions) {
  return {
    name: "name",
    resolve: {
      input: [".svelte"],
      output: [".js", ".css"],
    },
    async load({
      contents,
      filePath,
      defaultOutputPath,
      methods: { writeSnowFile },
    }) {
      // ... some implementation
      const htmlPath = defaultOutputPath.replace("_dist_/_pages/", "");
      const htmlOutput = outputHtml({ contents, filePath });
      await writeSnowFile(htmlPath, htmlOutput);

      return {
        ".js": js && js.code,
        ".css": css && css.code,
      };
    },
  };
};

[m4rrc0]

BTW, if you are willing to discuss the SSG thing, I have got other challenges related to manipulating files that may be related to this feature.

Let me know if I should expand on how it works.

[FredKSchott]

A possibly easy solution to implement in core would be to have a devOption to build files 'for real' instead of keeping the dev process in memory. That way, anyone can simply mess with the files inside or outside of a plugin. No harm no foul.

We have #376 which roughly matches what you're describing here.

Also /cc @drwpow on this thread

[m4rrc0]

We have #376 which roughly matches what you're describing here.

Yep, read it and gave me the idea of using nodemon as a wrokaround for now. That would definitely be a start.

I wrote more about my workflow for the static site generator in #673. It confirms that we would need this feature and give more context for a wider set of features regarding file manipulation.