To avoid long discussions about details on Gantry in other discussions, I'm creating this specific issue to collect info. Once we identify specific needs that should go in scssphp, we'll create dedicated issues to track them.

Gantry5 is extending the compiler.

Here is what I can see being done:

• registering custom functions through registerFunction in __construct => a composition-based approach might work as a replacement as inheritance is not necessary to achieve the registration
• registering a url function through the Compiler::lib* discovery => can be migrated to registerFunction as this does not override a core function
• configuration methods for the implementation of custom functions => not relevant for scssphp. They would be moved to wherever the custom functions go when using composition
• override get to catch any exception, and treat them as echoing the exception message (no idea where it would end up) and return an empty string as the value
• overriding Compiler::parserFactory
• overriding Compiler::addParsedFile and getParsedFiles with almost the same logic than upstream
• overriding Compiler::importFile
• adding Compiler::$streamNames
• overriding Compiler::handleImportLoop to use $streamNames instead of $sourceNames

@mahagr can you give us some explanations about the use cases for overriding get, overriding parseFactory, reimplementing the parsedFiles feature and replacing Compiler::importFile ?

Regarding Compiler::importFile, I'm wondering in particular if your use case could be solved in other ways:

• adding a callable in the importPaths, which allows custom resolution
• overriding Compiler::findImport rather than Compiler::importFile (and if this has to be done over using a callable in importPaths, why is it necessary ?)

Edit: see https://github.com/gantry/gantry5/blob/feature/v5.5.0/src/classes/Gantry/Component/Stylesheet/ScssCompiler.php for the new version of the code