You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.The text was updated successfully, but these errors were encountered: