sync: "sync" | "async"
Whether or not Sass should generate a source map. If it does, the source map will be available as CompileResult.sourceMap.
⚠️ Heads up!
Sass doesn't automatically add a
sourceMappingURL comment to the generated CSS. It's up to callers to do that, since callers have full knowledge of where the CSS and the source map will exist in relation to one another and how they'll be served to the browser.
Map Include Sources
Whether Sass should include the sources in the generated source map.
This option has no effect if sourceMap is
The OutputStyle of the compiled CSS.
Additional built-in Sass functions that are available in all stylesheets. This option takes an object whose keys are Sass function signatures like you'd write for the
@function rule and whose values are CustomFunctions.
When writing custom functions, it's important to make them as user-friendly and as close to the standards set by Sass's core functions as possible. Some good guidelines to follow include:
Value.assert*methods, like Value.assertString, to cast untyped
Valueobjects to more specific types. For values that were passed directly as arguments, pass in the argument name as well. This ensures that the user gets good error messages when they pass in the wrong type to your function.
Individual classes may have more specific
assert*methods, like SassNumber.assertInt, which should be used when possible.
When manipulating values like lists, strings, and numbers that have metadata (comma versus space separated, bracketed versus unbracketed, quoted versus unquoted, units), the output metadata should match the input metadata.
When in doubt, lists should default to comma-separated, strings should default to quoted, and numbers should default to unitless.
In Sass, lists and strings use one-based indexing and use negative indices to index from the end of value. Functions should follow these conventions. Value.sassIndexToListIndex and SassString.sassIndexToStringIndex can be used to do this automatically.
0xD83D, whereas in Sass
str-slice("a😊b", 1, 1)returns
"😊". Functions should follow Sass's convention. SassString.sassIndexToStringIndex can be used to do this automatically, and the SassString.sassLength getter can be used to access a string's length in code points.
Loads are resolved by trying, in order:
The importer that was used to load the current stylesheet, with the loaded URL resolved relative to the current stylesheet's canonical URL.
Each load path in loadPaths, in order.
If none of these return a Sass file, the load fails and Sass throws an error.
If this is
true, the compiler will exclusively use ASCII characters in its error and warning messages. Otherwise, it may use non-ASCII Unicode characters as well.
If this is
true, the compiler will use ANSI color escape codes in its error and warning messages. If it's
false, it won't use these. If it's undefined, the compiler will determine whether or not to use colors depending on whether the user is using an interactive terminal.
If this option is set to
true, Sass won’t print warnings that are caused by dependencies. A “dependency” is defined as any file that’s loaded through loadPaths or importer. Stylesheets that are imported relative to the entrypoint are not considered dependencies.
This is useful for silencing deprecation warnings that you can’t fix on your own. However, please also notify your dependencies of the deprecations so that they can get fixed as soon as possible!
By default, Dart Sass will print only five instances of the same deprecation warning per compilation to avoid deluging users in console noise. If you set
true, it will instead print every deprecation warning it encounters.