-
Notifications
You must be signed in to change notification settings - Fork 15.8k
chore: Extensions architecture POC #31934
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Extensions architecture POC #31934
Conversation
Based on your review schedule, I'll hold off on reviewing this PR until it's marked as ready for review. If you'd like me to take a look now, comment
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #31934 +/- ##
===========================================
+ Coverage 60.48% 72.42% +11.93%
===========================================
Files 1931 584 -1347
Lines 76236 42428 -33808
Branches 8568 4475 -4093
===========================================
- Hits 46114 30728 -15386
+ Misses 28017 10516 -17501
+ Partials 2105 1184 -921
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
904fbd9
to
871787f
Compare
3cde2af
to
f766cc4
Compare
496c566
to
76a4e83
Compare
superset/migrations/versions/2025-03-07_08-35_d4d5115bdeb0_add_extensions_table.py
Outdated
Show resolved
Hide resolved
870c262
to
9f0fbc0
Compare
812f875
to
e34b695
Compare
@villebro I'm creating a task list so we can track what we need to do to merge this PR. Feel free to add/edit items:
|
love the idea of general organization this way
Super great but super disruptive and merge conflicting. Some things are kind of going that way area, you could go one-per-PR. We'd need to identify the set of feature_or_subject_area, some might be pretty tangled up with one-another ... In practice might be hard to segment |
Totally, I've also been pushing for reorganizing the backend like this. Commands should also go directly under the main feature/subject area. I believe we actually already had commands and DAOs under the main feature before, but it was moved in under a centralized package at some point. I propose doing this massive refactor next time the breaking window opens to clean up the backend, as it will make things much more modular. |
"last 3 edge versions" | ||
], | ||
"dependencies": { | ||
"@apache-superset/core": "file:packages/superset-core", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is creating some troubles for me. UI won't boot up...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I know so far...
- nuking node_modules,
npm run prune
, restarting docker, ... - after this PR, running
npm install
changes the package-lock.json - I can only get the UI to boot up on SHAs before this PR
- building before/after this in master, works before, fails after
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
npm install changes the package-lock.json
npm install
may change the lock file because it installs new or updated dependencies, keeping the project up to date during development.
npm ci
never changes the lock file, ensuring that exactly what’s specified in the lock file is installed for guaranteed consistency, especially in CI environments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mistercrunch I opened #34924 to update the referenced version of @apache-superset/core. I tested both dev and built modes:
superset init
npm ci
npm run build (serving from port 8088 OK)
npm run dev-server (serving from port 9000 OK)
Co-authored-by: Ville Brofeldt <[email protected]> Co-authored-by: Ville Brofeldt <[email protected]> Co-authored-by: Ville Brofeldt <[email protected]> (cherry picked from commit a8be5a5)
SUMMARY
This PR introduces new packages and functionality for introducing extensions as proposed in SIP #34162. Example extensions that were used for validating the system have been moved to the following draft PR: #34726
This PR introduces the following packages:
superset-frontend/packages/superset-core
Our package with UI components, utility functions, types, and APIs used by extensions.
superset-core
The host APIs used by backend extensions.
superset-cli
CLI commands to build, bundle and hot-rebuild extensions.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
The Dataset references extension displays relevant information for SQL authors in SQL Lab:
Screen.Recording.2025-06-04.at.10.48.32.mov
TESTING INSTRUCTIONS
1 - Set the
ENABLE_EXTENSIONS
feature flag toTrue
.2 - Run
npm ci
onsuperset-frontend
.3 - Install the development dependencies by running
pip install -r requirements/development.txt
. This will pull in the new cli package that contains thesuperset-extensions
command.4 - Bundle an extension by going into its root folder and executing
superset-extensions bundle
. This will build the extension and generate a.supx
bundle of the extension.5 - Upload the
.supx
file to Superset using Swagger and theextensions
endpoint.6 - Go to
SQL
->SQL Lab
and check the extension.For development mode:
1 - Execute steps 1, 2 and 3 above.
2 - Configure Superset's
LOCAL_EXTENSIONS
variable like:3 - Run in development mode by going into the extension root folder and executing
superset-extensions dev
. This will trigger hot-rebuilding of your frontend assets. Backend assets are currently reloaded by the default reloading mechanisms of Superset usingsuperset run --reload
.4 - Go to
SQL
->SQL Lab
and check the extension.ADDITIONAL INFORMATION