Additional extension support

[benmccann]

It seems like you couldn't use wmr with .svelte files yet, which is something I'd be very interested to check out

Main blocker: https://github.com/preactjs/wmr/blob/master/src/wmr-middleware.js#L169-L184

Will probably also need file watching support

I might be possible to support .svelte directly, but dynamically import the Svelte compiler so that the dependency isn't pulled in unless used. Or perhaps there should be a way to register extension handling plugins that provide a transformer

[lukeed]

Getting rollup-plugin-svelte to work is fairly easy. There are some kinks (discussed) but there's no actual svelte-stuff that wmr has to do. The missing bits are:

• enabling non-prefix based access to NonRollup.transform
• ensuring custom file extensions (or everything loaded?) is mounted onto file watcher
• ensuring custom extensions invalidate/replace the previously built file(s) on change*

Discussed the last one with @developit – it's definitely happening, which doesn't seem right. Haven't been able to dig in & figure out why yet.

[developit]

The way I'd envision this working:

• code does import './foo.svelte', which requests a module /foo.svelte.
• The server middleware handles that request by first asking any plugins if they'd like to customize loading of the foo.svelte module ID.
• If a plugin is registered that returns a non-null value from load() for that .svelte module ID, the result is assumed to be a JavaScript module, and execution actually calls into the rest of the JS middleware to transform and return the generated module source.
• Otherwise it falls back to the current disk asset loading+serving strategy.

Another option would be to use the HTTP Accept request header to determine that the /path/to/foo.svelte request should be handled as a JS mimetype even though the extension is not [cm]js|jsx?|tsx?|. I don't feel strongly either direction, though we have so far managed to avoid varying responses based on the Accept header so that loading URLs in a browser tab returns the same content as loading them via fetch() or importing them.

[intrnl]

The way Vite does it is that it adds a ?import suffix to each import declaration, initially it was done through checking the Referer headers, but it doesn't seem to work on Safari due to it sending a different header than Chrome/Firefox

[developit]

Yeah - we might need to switch to this at some point. Currently we add an ?asset suffix URLs to prevent them from being interpreted as imports, but that's sortof backwards.

On the plus side: instead of ?import, we could put the file's mtime in the querystring (instead of using ?t=Date for HMR like we currently do).