Support TypeScript for non-component source code

[Rich-Harris]

I guess we just need to recognise file extensions other than .js, and update the webpack config in sapper-template

[Conduitry]

I'm a tad worried by this change. If we support TypeScript out of the box (and make everyone using sapper-template download its compiler whether they use it or not), why not [language X that compiles to js]? Would this be better handled by some sort of plugin architecture?

[EmilTholin]

That's a good point. Maybe just make sapper recognize .ts files, but don't change sapper-template? An entry in the sapper-template Wiki on how to add TypeScript could suffice, or do you think that is just another version of the [language X that compiles to js] problem?

[Conduitry]

I don't think there's a problem with having a wiki entry on how to support typescript - but I think it'd still bug me making a change to this regex in sapper itself. The way it is now, supporting additional file types can be done from outside of sapper (by adding new webpack plugins/loaders), but supporting additional file extensions requires changes to sapper. I feel a better solution is to let that regex be configurable when calling sapper() to create the middleware instance.

[Rich-Harris]

I think I agree re leaving sapper-template alone and making it a documentation concern — it should be possible to use TypeScript (or whatever else people are into) but we probably shouldn't clutter up the default config with something that will be extraneous to most people.

I feel a better solution is to let that regex be configurable when calling sapper() to create the middleware instance.

What if we recognised all files in routes (except those with underscore prefixes), and separated out the ones with an .html or .svelte extension? That seems like a nice easy way to support whatever languages people are into. Any thoughts?