It turns out my original reimplementation of the sass parser wasn't the most fortunate thing to do :)

TL;DR: the current implementation uses 'sass' to actually compile sass code and its' deps. The new implementation uses regex to find @import, @use and @forward at-rules and finds dependencies from import paths of these rules.

The original implementation with sass.compileString() method contained an untested bug. After sass code was compiled, the loadedUrls property of returned object included all the modules that entered the compilation. This included transitive dependencies, that direct dependencies of the processed sass files depended on. This was incorrect. At the same time the 'sass' compiler doesn't allow compiling a code without processing all the dependencies. There's no way to filter only "shallow"/direct depdencies from loadedUrls.

That's why native sass compilation was replaced with custom resolution logic that parses sass/scss files as follows:

1. It looks for @use, @import and @forward at-rules and extracts module names
2. module names have prefixes and suffixes (extensions) added and code checks if such files exist on a path relative to the processed file.
3. If a module is not detected as a relative path to an existing file, the dependency name is extracted using 'require-package-name' package

Updated fake_modules/sass and spec file test these additional scenarios:

• partials ("_" file prefix) are detected as relative path imports even if imported without prefix
• transitive deps that are imported from within node_modules are not detected as deps