mistercrunch commented on issue #33441: URL: https://github.com/apache/superset/issues/33441#issuecomment-2931502902
Reporting back from the Theming branch (https://github.com/apache/superset/pull/31590) where I moved the majority of `src/components/*` to (for now) `@superset-ui/core/components`. Some components in there were tangled up with `src/` for good reasons and remained there as they are more of an app-construct, and some were tangled up for bad reasons and I tried to untangle most of those and move them to `core/`, at least for now. The branch's main focus was the antd-v5 migration, which is complete within that branch, with lots of great side missions like: - getting rid of all the .less files and general .less support in the repo - getting rid of font-awesome in favor of antd's icon package - plugins now rely on `@superset-ui/core/components` for base components instead of a peerDep on antd - killed bootstrap (!) - most (all?) FAB CRUD gone - all themed, there's a PR to bring in an app-level ThemeController in charge of managing themes (retrieve, save, inject, ...) - some tsconfig refactoring, with just a bit of inheritance (ts.base.config.json) for some consistency across the codebase I generally tried to get rid of `default` exports (still some work to do) and to bring components flat into that main namespace, which should make things much easier to move components again if/when we decide so. It'll be good to chat about all this, but doing this work it seemed like a `plugin-sdk` as a common basis on top of core to support plugins (internal and external) would make a lot of sense. Generally cleaning up `core/` would be great, where things like `chart-controls/` clearly are a `plugin-sdk`-type construct, and many packages seem like they don't have a clear function (or maybe I just don't get it) -> `superset-ui-switchboard/` ? `superset-ui-demo/` ? After months of refactoring, it feels there's hope there, including to wrap up long-standing refactor like the ts-migration (looking at you `airbnb/ts-migrate`) and Enzyme -> rtl. As to final the target final state I don't care too much one way or another, but feels right to have all the foundational bits (anything used across sdks and the main app) in a private place, directly linked to the app in the main repo. One big question is whether we clean in-place directly in `core/`, or in a new area say `primitives/` package with the goal of deprecating core over time (?) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
