Linked to #270 (comment) and #315 (comment)

dart-sass is not offering any of this mecanism but is probaly fast enough in compilation time to avoid this need

scssphp is taking seconds to compile BootStrap and is not fast enough to be used in a CMS as a on the fly compilation tool without any cache.

So : or it has to provide it's own caching mecanism, or provide api point to allow the user to provide a cache mecanism.

ScssPhp is using two caching level right now :

• one for the parsing
• one for the complete compilation result

Both are useful. With this, for instance, modifying just the _variables.scss in the BS compilation need only to reparse this file and compile the whole, and this is a real life situation : website development is mainly iterative with modifications on one or some scss files and checking the visual result.

A cache for the whole compiled result could be managed outside scssphp, as long as scssphp is returning enough information like the list of @import resolutions with the useful data to check the resolution is unchanged.

But a cache mecanism for the parsing needs a specific entry point for caching to allow the parser to rely on it.

For now the cache logic is provided by scssphp, but we could consider the user a to rely on an external cache tool IF scssphp is providing the right API for that...