Per reviewer feedback: @apache-superset/core/colors should expose the interface for
accessing color schemes (types, ColorSchemeGroup enum, registry bridge functions) but
leave the implementation details — which palettes exist and their hex values — to the
host app.
- Delete categorical/ and sequential/ palette data dirs from @apache-superset/core/colors
- Restore all 13 categorical and 2 sequential @superset-ui/core scheme files to owning
their own palette data (revert thin wrappers)
- Slim @apache-superset/core/colors/index.ts to: ColorSchemeGroup, ColorSchemeConfig,
SequentialSchemeConfig types + registry bridge functions only
- Restore setupColors.ts to import CategoricalScheme arrays from @superset-ui/core
- Update colors.test.ts to cover only ColorSchemeGroup enum and registry bridge
- Restore @superset-ui/core/src/color/types.ts to define ColorSchemeGroup directly
- Remove now-unnecessary palette exclusions from check-custom-rules.js
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add ColorSchemeGroup enum and ColorSchemeConfig/SequentialSchemeConfig types,
all 13 categorical palette definitions, both sequential palette groups, a barrel
index, and a test suite to packages/superset-core. This makes @apache-superset/core
the single source of truth for Superset color palette data, usable by both the
host app and extensions.
Also excludes the new palette data dirs from the no-literal-colors custom lint rule.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
