Can Dart Sass 2.0's async-only importers/functions be used in low-traffic projects without increasing build complexity?

Background

Dart Sass 2.0 removed the legacy synchronous JavaScript API, requiring custom importers and functions to use the async-only API. This forces projects with custom Sass logic to adopt async compilation patterns, even for simple use cases.

For low-traffic projects, the primary cost is developer time spent refactoring build tooling rather than computational overhead. The question is whether the async migration path introduces unnecessary complexity for projects that previously relied on synchronous compilation.

Constraints

• Projects using custom Sass functions for asset path resolution or dynamic imports
• Build scripts that were simple Node.js wrappers around `renderSync`
• No bundler plugins that abstract the API changes
• Need to maintain readable output for debugging

Unresolved Behavior

The new synchronous `compile`/`compileString` APIs do not support custom importers or functions at all—they are async-only. This means projects cannot use the simpler sync API if they need custom logic.

Key Questions

1. Does the async API introduce measurable build time overhead for typical low-traffic project sizes?
2. Can async compilation be integrated into simple npm scripts without requiring additional tooling or Promise handling?
3. What is the recommended migration pattern for projects that need both custom importers and fast, readable builds?