Plugins

[nsaunders]

I see that there is a "Plugins" section in the Svelte guide, but I'm not sure whether that refers to the plugins for Webpack, Rollup, Metalsmith, et cetera; or implies that we will be able to write plugins that extend the Svelte compiler in the future. Hopefully the latter!

[Rich-Harris]

It refers to runtime plugins that extend Svelte with things like custom event handlers and, when we get round to implementing them, transitions.

But extending the compiler is an interesting concept – maybe we could create plugins that (for example) baked Redux support into components, rather than having to add glue code.

The API for building loader plugins is very small, and is documented on the README.

[dschulten]

Or allow to have css precompilers for component styles. Great, I'll have a look into the readme.

[dschulten]

I have looked into the README and I do not see an API for building loader plugins there, or at least not what I hoped to find. What do you mean by loader plugins, plugins to the svelte-cli?

[dschulten]

Possible extension points might be parse/read/script/style.js and parse/read/script.js - the extension point could allow to redefine them with functions that take the same arguments (parser, start, attributes) but can process the content, e.g. based on the style rel or script type attribute. Would that be a good way to go about this?

[Rich-Harris]

Loader plugins refers to things like rollup-plugin-svelte and svelte-loader — i.e. integrations with existing build tools that makes it easy to use Svelte in your app.

CSS precompilers would presumably be handled as a compiler option — if it was implemented it would probably look something like this:

const { code, map } = svelte.compile( source, {
  preprocess: {
    less ( code ) {
      // some code happens
      return { code, map };
    },
    coffeescript ( code ) {
      // some code happens
      return { code, map };
    }
  }
});

Then templates would have <style type='less'> or <script type='coffeescript'> or whatever. But those features are tracked at https://github.com/sveltejs/svelte/issues/181 (gah, just seen you commented there at about the same time!) and https://github.com/sveltejs/svelte/issues/98.

[nsaunders]

@Rich-Harris, just a reminder (in case you missed my comment in #181 in particular) that LESS compilation is asynchronous to my knowledge, and I would bet it isn't the only preprocessor like that. Therefore, I think that svelte.compile itself should be made async in version 2, even if we don't get around to adding plugin support right away. (Then, when we do add it, it won't be a breaking API change.) Otherwise, I like the preprocess API you suggested.

[PaulBGD]

@therealnicksaunders That's a really good point, svelte.compile should return a promise or accept a callback. How should we make that breaking change? We could provide another method like svelte.compileAsync then disallow any async processors/plugins in svelte.compile.

[Rich-Harris]

This can be closed, since we now have svelte.preprocess for handling things like LESS.