[JavaScript API] Consider adding a way to retrieve dependencies even when the compilation fails

[ericmorand]

We have been using dart-sass (and previously node-sass) on our custom node-based build system. This system retrieves the list of files that were involved in the compilation (i.e. the dependencies) to watch them and trigger a new compilation run on change.

It is working perfectly when the compilation is a success: the Result Object returned by the JavaScript API contains a stats object with the list of included files and the entry point:

https://sass-lang.com/documentation/js-api#result-object

But it is not as reliable when an error occurs. The reason is that the Error Object only provide the file where the error occurred:

https://sass-lang.com/documentation/js-api#error-object

It means that it is impossible to get the list of all files involved in the compilation to watch them and trigger a new compilation run on change.

Let's take an actual example:

index.scss

@use "foo" as foo;

.bar {
    color: foo.$primary-color;
} 

foo.scss

$secondary-color: red;

Obviously, compiling index.scss would fail, because the variable $primary-color is not exported by the foo module. The Error Object would then give us the file where the error occurred (index.scss) but not the foo.scss file even though it was involved in the compilation.

It means that changing foo.scss to add the missing variable would not trigger a new compilation because our tool has no way to know that it needs to watch foo.scss.

It would be great if the JavaScript API could provide a way to retrieve the list of all the dependencies involved in the compilation of the entry, whatever the result of the compilation, either by:

• Emitting a "file" event everytime dart-sass import a resource from one of its importers
• Returning the Result Object even when an error occurs - it would obviously have its css and map properties undefined but every other properties would be perfectly valid and make sense
• Attaching the statistics to the Error Object alongside its file, line and other custom properties

I'd like to provide a PR for this, but only if it's something that make sense to you. It makes a lot of sense for us tool builders, where controlling the files we watch and automating rebuilds as much as possible are a priority.

[jathak]

In the long term, this use case should be covered by #2745.

In the short term, adding support for the stats property on an error object seems reasonable, but since the JS API is considered part of the language specification, any change would need to go through the proposal process. I've moved this to the language repo to track this process.