Problem
Currently, developers building Flutter apps with Stac need to add two packages to their pubspec.yaml:
dependencies:
stac:
stac_core:
They also need to use two separate import statements in their screens and theme files:
import 'package:stac/stac.dart'; // Stac.initialize, StacApp, StacNavigator …
import 'package:stac_core/stac_core.dart'; // StacWidget, StacAction, StacTheme, @StacScreen …
This increases the learning curve and causes confusion — developers are constantly asking:
"Which package has StacWidget? Do I need both? Why is @StacScreen not in stac?"
Root Cause
stac_core is a pure-Dart package (no Flutter SDK dependency) that contains:
- All
StacWidget types, StacAction base class, StacParser interface
- Theme foundation (
StacTheme, StacColorScheme, StacTextTheme, etc.)
- Core annotations (
@StacScreen, @StacThemeRef)
- Geometry types (
StacEdgeInsets, StacBorderRadius, etc.)
It exists as a separate package so the Stac CLI and VS Code extension (pure-Dart environments) can depend on it without pulling in Flutter. This architectural split makes sense internally, but it leaks as a public API surface that app developers shouldn't have to know about.
Currently, packages/stac/lib/stac.dart only re-exports a tiny slice of stac_core:
// packages/stac/lib/stac.dart
export 'package:stac_core/stac_core.dart' show StacTheme; // only StacTheme!
Everything else from stac_core is left as a direct import burden on the consumer.
Proposed Solution
Change the stac barrel file to fully re-export stac_core, making it an internal implementation detail:
// packages/stac/lib/stac.dart
export 'package:stac_core/stac_core.dart'; // full re-export
With this change:
- App developers only need
stac: in pubspec.yaml
- A single
import 'package:stac/stac.dart' gives access to everything
stac_core remains a separate published package for the CLI/extension — it just becomes invisible to app developers
Impact
| Before |
After |
pubspec.yaml needs both stac: and stac_core: |
Only stac: needed |
| Two import lines in every screen/theme file |
Single import 'package:stac/stac.dart' |
Developers wonder "which package has StacWidget?" |
Everything in stac |
Questions for Community
- Are there any reasons we want to keep
stac_core as a public API surface for app developers?
- Would a full re-export cause any symbol conflicts or ambiguity?
- Should this be released as a patch or minor version bump?
Looking forward to hearing your thoughts! 🚀
Problem
Currently, developers building Flutter apps with Stac need to add two packages to their
pubspec.yaml:They also need to use two separate import statements in their screens and theme files:
This increases the learning curve and causes confusion — developers are constantly asking:
Root Cause
stac_coreis a pure-Dart package (no Flutter SDK dependency) that contains:StacWidgettypes,StacActionbase class,StacParserinterfaceStacTheme,StacColorScheme,StacTextTheme, etc.)@StacScreen,@StacThemeRef)StacEdgeInsets,StacBorderRadius, etc.)It exists as a separate package so the Stac CLI and VS Code extension (pure-Dart environments) can depend on it without pulling in Flutter. This architectural split makes sense internally, but it leaks as a public API surface that app developers shouldn't have to know about.
Currently,
packages/stac/lib/stac.dartonly re-exports a tiny slice ofstac_core:Everything else from
stac_coreis left as a direct import burden on the consumer.Proposed Solution
Change the
stacbarrel file to fully re-exportstac_core, making it an internal implementation detail:With this change:
stac:inpubspec.yamlimport 'package:stac/stac.dart'gives access to everythingstac_coreremains a separate published package for the CLI/extension — it just becomes invisible to app developersImpact
pubspec.yamlneeds bothstac:andstac_core:stac:neededimport 'package:stac/stac.dart'StacWidget?"stacQuestions for Community
stac_coreas a public API surface for app developers?Looking forward to hearing your thoughts! 🚀