Providing custom Loader implementation

[RianFuro]

I wanted to write a custom Loader implementation, but I found that I cannot replicate the needed API without copying over the Core and Parser classes into my project, which would introduce a hard to track dependency.

Instead of doing that, would you accept a pull request that refactors FileSystemLoader and friends and isolates the loading behavior so it does not depend on the parsing logic? This would most certainly be a breaking change, since the interface would change to something akin to (path) => Promise<string>, but i doubt anyone who's ever written a custom loader would be against not having to provide the parser.

Alternatively, we could also just properly export the Core class, so I can import and use it directly.

[madyankin]

It might be a good idea. Could you tell more what exactly would you like to do with a custom loader?

I'm thinking of completely rewriting the plugin and would like to have a better understanding what people actually want to use

[RianFuro]

@Outpunk Basically, integration with Rollup.

This plugin is used by egoist/rollup-plugin-postcss and Rollup allows a plugin to define custom loaders to resolve imports.

I wrote myself a plugin to use astroturf to extract css without writing it to disk (their recomendation for rollup is to use their babel plugin directly and clean up the mess afterwards), so now, to make that work, I'll need to submit a pull request to egoist/rollup-plugin-postcss to pass a custom loader to this plugin, that resolves files through rollup, but I wanted to resolve this issue beforehand.

[madyankin]

@RianFuro let's try to isolate the parsing logic from the loader, feel free to make a PR.