fix: render Jinja templates in ORDER BY adhoc metrics

When processing adhoc metrics in ORDER BY clauses during query execution,
Jinja templates were not being rendered because `processed=True` was
passed without providing template processing.

This commit:
1. Updates adhoc_metric_to_sqla() to apply template processing even when
   processed=True (meaning SQL is already sanitized)
2. Passes template_processor when converting orderby adhoc metrics
3. Removes obsolete test that expected error handling removed in commit
   add087cbfe

The fix ensures that:
- During validation: SQL is sanitized but Jinja templates are preserved
  (template_processor=None)
- During execution: Jinja templates are rendered (template_processor
  provided, processed=True skips re-sanitization)

Fixes test: test_chart_data_table_chart_with_time_grain_filter

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

.github/CODEOWNERS

@@ -33,7 +33,6 @@
 
 # Notify PMC members of changes to extension-related files
 
-/docs/developer_portal/extensions/ @michael-s-molina @villebro @rusackas
 /superset-core/ @michael-s-molina @villebro @geido @eschutho @rusackas @kgabryje
 /superset-extensions-cli/ @michael-s-molina @villebro @geido @eschutho @rusackas @kgabryje
 /superset/core/ @michael-s-molina @villebro @geido @eschutho @rusackas @kgabryje

.github/workflows/bashlib.sh

@@ -117,19 +117,6 @@ testdata() {
   say "::endgroup::"
 }
 
-playwright_testdata() {
-  cd "$GITHUB_WORKSPACE"
-  say "::group::Load all examples for Playwright tests"
-  # must specify PYTHONPATH to make `tests.superset_test_config` importable
-  export PYTHONPATH="$GITHUB_WORKSPACE"
-  pip install -e .
-  superset db upgrade
-  superset load_test_users
-  superset load_examples
-  superset init
-  say "::endgroup::"
-}
-
 celery-worker() {
   cd "$GITHUB_WORKSPACE"
   say "::group::Start Celery worker"

.github/workflows/bump-python-package.yml

@@ -32,7 +32,7 @@ jobs:
     steps:
 
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: true
           ref: master

.github/workflows/cancel_duplicates.yml

@@ -31,7 +31,7 @@ jobs:
 
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
         if: steps.check_queued.outputs.count >= 20
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
 
       - name: Cancel duplicate workflow runs
         if: steps.check_queued.outputs.count >= 20

.github/workflows/check-python-deps.yml

@@ -18,7 +18,7 @@ jobs:
     runs-on: ubuntu-22.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/check_db_migration_confict.yml

@@ -25,7 +25,7 @@ jobs:
       pull-requests: write
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
       - name: Check and notify
         uses: actions/github-script@v8
         with:

.github/workflows/claude.yml

@@ -71,7 +71,7 @@ jobs:
       id-token: write
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v6
+      uses: actions/checkout@v5
       with:
         fetch-depth: 1
 

.github/workflows/codeql-analysis.yml

@@ -31,7 +31,7 @@ jobs:
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
 
       - name: Check for file changes
         id: check

.github/workflows/dependency-review.yml

@@ -27,7 +27,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout Repository"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
       - name: "Dependency Review"
         uses: actions/dependency-review-action@v4
         continue-on-error: true
@@ -53,7 +53,7 @@ jobs:
     runs-on: ubuntu-22.04
     steps:
       - name: "Checkout Repository"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
 
       - name: Setup Python
         uses: ./.github/actions/setup-backend/

.github/workflows/docker.yml

@@ -42,7 +42,7 @@ jobs:
     steps:
 
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
 
@@ -117,7 +117,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
       - name: Check for file changes

.github/workflows/embedded-sdk-release.yml

@@ -28,8 +28,8 @@ jobs:
       run:
         working-directory: superset-embedded-sdk
     steps:
-      - uses: actions/checkout@v6
-      - uses: actions/setup-node@v6
+      - uses: actions/checkout@v5
+      - uses: actions/setup-node@v5
         with:
           node-version-file: './superset-embedded-sdk/.nvmrc'
           registry-url: 'https://registry.npmjs.org'

.github/workflows/embedded-sdk-test.yml

@@ -18,8 +18,8 @@ jobs:
       run:
         working-directory: superset-embedded-sdk
     steps:
-      - uses: actions/checkout@v6
-      - uses: actions/setup-node@v6
+      - uses: actions/checkout@v5
+      - uses: actions/setup-node@v5
         with:
           node-version-file: './superset-embedded-sdk/.nvmrc'
           registry-url: 'https://registry.npmjs.org'

.github/workflows/ephemeral-env.yml

@@ -160,7 +160,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ needs.ephemeral-env-label.outputs.sha }} : ${{steps.get-sha.outputs.sha}} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           ref: ${{ needs.ephemeral-env-label.outputs.sha }}
           persist-credentials: false
@@ -220,7 +220,7 @@ jobs:
       pull-requests: write
 
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v5
         with:
           persist-credentials: false
 

.github/workflows/generate-FOSSA-report.yml

@@ -27,7 +27,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/github-action-validator.yml

@@ -14,10 +14,10 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: Checkout Repository
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
 
       - name: Set up Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version: '20'
 

.github/workflows/issue_creation.yml

@@ -17,7 +17,7 @@ jobs:
     steps:
 
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
 

.github/workflows/latest-release-tag.yml

@@ -12,7 +12,7 @@ jobs:
 
     steps:
     - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-      uses: actions/checkout@v6
+      uses: actions/checkout@v5
       with:
         persist-credentials: false
         submodules: recursive

.github/workflows/license-check.yml

@@ -15,7 +15,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/pr-lint.yml

@@ -16,7 +16,7 @@ jobs:
       pull-requests: write
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/pre-commit.yml

@@ -21,7 +21,7 @@ jobs:
         python-version: ["current", "previous", "next"]
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
@@ -39,7 +39,7 @@ jobs:
           echo "HOMEBREW_REPOSITORY=$HOMEBREW_REPOSITORY" >>"${GITHUB_ENV}"
           brew install norwoodj/tap/helm-docs
       - name: Setup Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version: '20'
 
@@ -54,7 +54,7 @@ jobs:
           yarn install --immutable
 
       - name: Cache pre-commit environments
-        uses: actions/cache@v5
+        uses: actions/cache@v4
         with:
           path: ~/.cache/pre-commit
           key: pre-commit-v2-${{ runner.os }}-py${{ matrix.python-version }}-${{ hashFiles('.pre-commit-config.yaml') }}
@@ -71,9 +71,7 @@ jobs:
           GIT_DIFF_EXIT_CODE=$?
           if [ "${PRE_COMMIT_EXIT_CODE}" -ne 0 ] || [ "${GIT_DIFF_EXIT_CODE}" -ne 0 ]; then
             if [ "${PRE_COMMIT_EXIT_CODE}" -ne 0 ]; then
-              echo "❌ Pre-commit check failed (exit code: ${PRE_COMMIT_EXIT_CODE})."
-              echo "🔍 Modified files:"
-              git diff --name-only
+              echo "❌ Pre-commit check failed (exit code: ${EXIT_CODE})."
             else
               echo "❌ Git working directory is dirty."
               echo "📌 This likely means that pre-commit made changes that were not committed."

.github/workflows/prefer-typescript.yml

@@ -27,7 +27,7 @@ jobs:
       pull-requests: write
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/release.yml

@@ -26,7 +26,7 @@ jobs:
     name: Bump version and publish package(s)
     runs-on: ubuntu-24.04
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v5
         with:
           # pulls all commits (needed for lerna / semantic release to correctly version)
           fetch-depth: 0
@@ -42,13 +42,13 @@ jobs:
 
       - name: Install Node.js
         if: env.HAS_TAGS
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
 
       - name: Cache npm
         if: env.HAS_TAGS
-        uses: actions/cache@v5
+        uses: actions/cache@v4
         with:
           path: ~/.npm # npm cache files are stored in `~/.npm` on Linux/macOS
           key: ${{ runner.OS }}-node-${{ hashFiles('**/package-lock.json') }}
@@ -62,7 +62,7 @@ jobs:
         run: echo "dir=$(npm config get cache)" >> $GITHUB_OUTPUT
       - name: Cache npm
         if: env.HAS_TAGS
-        uses: actions/cache@v5
+        uses: actions/cache@v4
         id: npm-cache # use this to check for `cache-hit` (`steps.npm-cache.outputs.cache-hit != 'true'`)
         with:
           path: ${{ steps.npm-cache-dir-path.outputs.dir }}

.github/workflows/showtime-cleanup.yml

@@ -7,6 +7,12 @@ on:
 
   # Manual trigger for testing
   workflow_dispatch:
+    inputs:
+      max_age_hours:
+        description: 'Maximum age in hours before cleanup'
+        required: false
+        default: '48'
+        type: string
 
 # Common environment variables
 env:
@@ -32,5 +38,13 @@ jobs:
 
       - name: Cleanup expired environments
         run: |
-          echo "Cleaning up environments respecting TTL labels"
-          python -m showtime cleanup --respect-ttl
+          MAX_AGE="${{ github.event.inputs.max_age_hours || '48' }}"
+
+          # Validate max_age is numeric
+          if [[ ! "$MAX_AGE" =~ ^[0-9]+$ ]]; then
+            echo "❌ Invalid max_age_hours format: $MAX_AGE (must be numeric)"
+            exit 1
+          fi
+
+          echo "Cleaning up environments older than ${MAX_AGE}h"
+          python -m showtime cleanup --older-than "${MAX_AGE}h"

.github/workflows/showtime-trigger.yml

@@ -147,7 +147,7 @@ jobs:
 
       - name: Checkout PR code (only if build needed)
         if: steps.auth.outputs.authorized == 'true' && steps.check.outputs.build_needed == 'true'
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           ref: ${{ steps.check.outputs.target_sha }}
           persist-credentials: false

.github/workflows/superset-app-cli.yml

@@ -37,7 +37,7 @@ jobs:
           - 16379:6379
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/superset-applitool-cypress.yml

@@ -51,7 +51,7 @@ jobs:
           - 16379:6379
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
@@ -63,7 +63,7 @@ jobs:
         with:
           run: testdata
       - name: Setup Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install npm dependencies

.github/workflows/superset-applitools-storybook.yml

@@ -30,13 +30,13 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
           ref: master
       - name: Set up Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install eyes-storybook dependencies

.github/workflows/superset-docs-deploy.yml

@@ -31,12 +31,12 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
       - name: Set up Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './docs/.nvmrc'
       - name: Setup Python

.github/workflows/superset-docs-verify.yml

@@ -18,10 +18,10 @@ jobs:
     name: Link Checking
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v5
       # Do not bump this linkinator-action version without opening
       # an ASF Infra ticket to allow the new version first!
-      - uses: JustinBeckwith/linkinator-action@af984b9f30f63e796ae2ea5be5e07cb587f1bbd9  # v2.3
+      - uses: JustinBeckwith/linkinator-action@3d5ba091319fa7b0ac14703761eebb7d100e6f6d  # v1.11.0
         continue-on-error: true # This will make the job advisory (non-blocking, no red X)
         with:
           paths: "**/*.md, **/*.mdx"
@@ -58,12 +58,12 @@ jobs:
         working-directory: docs
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
       - name: Set up Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './docs/.nvmrc'
       - name: yarn install

.github/workflows/superset-e2e.yml

@@ -69,21 +69,21 @@ jobs:
       # Conditional checkout based on context
       - name: Checkout for push or pull_request event
         if: github.event_name == 'push' || github.event_name == 'pull_request'
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
           ref: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || github.sha }}
       - name: Checkout using ref (workflow_dispatch)
         if: github.event_name == 'workflow_dispatch' && github.event.inputs.ref != ''
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           ref: ${{ github.event.inputs.ref }}
           submodules: recursive
       - name: Checkout using PR ID (workflow_dispatch)
         if: github.event_name == 'workflow_dispatch' && github.event.inputs.pr_id != ''
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           ref: refs/pull/${{ github.event.inputs.pr_id }}/merge
@@ -109,7 +109,7 @@ jobs:
           run: testdata
       - name: Setup Node.js
         if: steps.check.outputs.python || steps.check.outputs.frontend
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install npm dependencies
@@ -146,7 +146,7 @@ jobs:
           SAFE_APP_ROOT=${APP_ROOT//\//_}
           echo "safe_app_root=$SAFE_APP_ROOT" >> $GITHUB_OUTPUT
       - name: Upload Artifacts
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v4
         if: failure()
         with:
           path: ${{ github.workspace }}/superset-frontend/cypress-base/cypress/screenshots
@@ -186,21 +186,21 @@ jobs:
       # Conditional checkout based on context (same as Cypress workflow)
       - name: Checkout for push or pull_request event
         if: github.event_name == 'push' || github.event_name == 'pull_request'
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
           ref: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || github.sha }}
       - name: Checkout using ref (workflow_dispatch)
         if: github.event_name == 'workflow_dispatch' && github.event.inputs.ref != ''
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           ref: ${{ github.event.inputs.ref }}
           submodules: recursive
       - name: Checkout using PR ID (workflow_dispatch)
         if: github.event_name == 'workflow_dispatch' && github.event.inputs.pr_id != ''
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           ref: refs/pull/${{ github.event.inputs.pr_id }}/merge
@@ -223,10 +223,10 @@ jobs:
         if: steps.check.outputs.python || steps.check.outputs.frontend
         uses: ./.github/actions/cached-dependencies
         with:
-          run: playwright_testdata
+          run: testdata
       - name: Setup Node.js
         if: steps.check.outputs.python || steps.check.outputs.frontend
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install npm dependencies
@@ -259,7 +259,7 @@ jobs:
           SAFE_APP_ROOT=${APP_ROOT//\//_}
           echo "safe_app_root=$SAFE_APP_ROOT" >> $GITHUB_OUTPUT
       - name: Upload Playwright Artifacts
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v4
         if: failure()
         with:
           path: |

.github/workflows/superset-extensions-cli.yml

@@ -24,7 +24,7 @@ jobs:
         working-directory: superset-extensions-cli
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
@@ -58,7 +58,7 @@ jobs:
 
       - name: Upload HTML coverage report
         if: steps.check.outputs.superset-extensions-cli
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v4
         with:
           name: superset-extensions-cli-coverage-html
           path: htmlcov/

.github/workflows/superset-frontend.yml

@@ -23,7 +23,7 @@ jobs:
       should-run: ${{ steps.check.outputs.frontend }}
     steps:
       - name: Checkout Code
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           fetch-depth: 0
@@ -58,7 +58,7 @@ jobs:
 
       - name: Upload Docker Image Artifact
         if: steps.check.outputs.frontend
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v4
         with:
           name: docker-image
           path: docker-image.tar.gz
@@ -73,7 +73,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: Download Docker Image Artifact
-        uses: actions/download-artifact@v7
+        uses: actions/download-artifact@v5
         with:
           name: docker-image
 
@@ -90,7 +90,7 @@ jobs:
           "npm run test -- --coverage --shard=${{ matrix.shard }}/8 --coverageReporters=json-summary"
 
       - name: Upload Coverage Artifact
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v4
         with:
           name: coverage-artifacts-${{ matrix.shard }}
           path: superset-frontend/coverage
@@ -101,7 +101,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: Download Coverage Artifacts
-        uses: actions/download-artifact@v7
+        uses: actions/download-artifact@v5
         with:
           pattern: coverage-artifacts-*
           path: coverage/
@@ -127,7 +127,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: Download Docker Image Artifact
-        uses: actions/download-artifact@v7
+        uses: actions/download-artifact@v5
         with:
           name: docker-image
 
@@ -151,7 +151,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: Download Docker Image Artifact
-        uses: actions/download-artifact@v7
+        uses: actions/download-artifact@v5
         with:
           name: docker-image
 
@@ -167,21 +167,3 @@ jobs:
         run: |
           docker run --rm $TAG bash -c \
           "npm run plugins:build-storybook"
-
-  test-storybook:
-    needs: frontend-build
-    if: needs.frontend-build.outputs.should-run == 'true'
-    runs-on: ubuntu-24.04
-    steps:
-      - name: Download Docker Image Artifact
-        uses: actions/download-artifact@v6
-        with:
-          name: docker-image
-
-      - name: Load Docker Image
-        run: docker load < docker-image.tar.gz
-
-      - name: Build Storybook and Run Tests
-        run: |
-          docker run --rm $TAG bash -c \
-          "npm run build-storybook && npx playwright install-deps && npx playwright install chromium && npm run test-storybook:ci"

.github/workflows/superset-helm-lint.yml

@@ -16,7 +16,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/superset-helm-release.yml

@@ -29,7 +29,7 @@ jobs:
 
     steps:
       - name: Checkout code
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           ref: ${{ inputs.ref || github.ref_name }}
           persist-credentials: true

.github/workflows/superset-playwright.yml

@@ -60,21 +60,21 @@ jobs:
       # Conditional checkout based on context (same as Cypress workflow)
       - name: Checkout for push or pull_request event
         if: github.event_name == 'push' || github.event_name == 'pull_request'
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
           ref: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || github.sha }}
       - name: Checkout using ref (workflow_dispatch)
         if: github.event_name == 'workflow_dispatch' && github.event.inputs.ref != ''
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           ref: ${{ github.event.inputs.ref }}
           submodules: recursive
       - name: Checkout using PR ID (workflow_dispatch)
         if: github.event_name == 'workflow_dispatch' && github.event.inputs.pr_id != ''
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           ref: refs/pull/${{ github.event.inputs.pr_id }}/merge
@@ -97,10 +97,10 @@ jobs:
         if: steps.check.outputs.python || steps.check.outputs.frontend
         uses: ./.github/actions/cached-dependencies
         with:
-          run: playwright_testdata
+          run: testdata
       - name: Setup Node.js
         if: steps.check.outputs.python || steps.check.outputs.frontend
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install npm dependencies
@@ -133,7 +133,7 @@ jobs:
           SAFE_APP_ROOT=${APP_ROOT//\//_}
           echo "safe_app_root=$SAFE_APP_ROOT" >> $GITHUB_OUTPUT
       - name: Upload Playwright Artifacts
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v4
         if: failure()
         with:
           path: |

.github/workflows/superset-python-integrationtest.yml

@@ -41,7 +41,7 @@ jobs:
           - 16379:6379
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
@@ -99,7 +99,7 @@ jobs:
           - 16379:6379
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
@@ -152,7 +152,7 @@ jobs:
           - 16379:6379
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/superset-python-presto-hive.yml

@@ -48,7 +48,7 @@ jobs:
           - 16379:6379
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
@@ -108,7 +108,7 @@ jobs:
           - 16379:6379
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/superset-python-unittest.yml

@@ -24,7 +24,7 @@ jobs:
       PYTHONPATH: ${{ github.workspace }}
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/superset-translations.yml

@@ -18,7 +18,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive
@@ -31,7 +31,7 @@ jobs:
 
       - name: Setup Node.js
         if: steps.check.outputs.frontend
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file:  './superset-frontend/.nvmrc'
       - name: Install dependencies
@@ -49,7 +49,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
           submodules: recursive

.github/workflows/superset-websocket.yml

@@ -21,7 +21,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
       - name: Install dependencies

.github/workflows/supersetbot.yml

@@ -38,7 +38,7 @@ jobs:
             });
 
       - name: "Checkout ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           persist-credentials: false
 

.github/workflows/tag-release.yml

@@ -47,7 +47,7 @@ jobs:
     steps:
 
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           fetch-depth: 0
 
@@ -60,7 +60,7 @@ jobs:
           build: "true"
 
       - name: Use Node.js 20
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version: 20
 
@@ -107,12 +107,12 @@ jobs:
     steps:
 
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
         with:
           fetch-depth: 0
 
       - name: Use Node.js 20
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version: 20
 

.github/workflows/tech-debt.yml

@@ -27,10 +27,10 @@ jobs:
     name: Generate Reports
     steps:
       - name: Checkout Repository
-        uses: actions/checkout@v6
+        uses: actions/checkout@v5
 
       - name: Set up Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
 

.gitignore

@@ -33,7 +33,6 @@ cover
 .env
 .envrc
 .idea
-.roo
 .mypy_cache
 .python-version
 .tox
@@ -138,4 +137,3 @@ PROJECT.md
 .claude_rc*
 .env.local
 oxc-custom-build/
-*.code-workspace

.pre-commit-config.yaml

@@ -106,19 +106,12 @@ repos:
         files: helm
         verbose: false
         args: ["--log-level", "error"]
-  # Using local hooks ensures ruff version matches requirements/development.txt
-  - repo: local
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.9.7
     hooks:
       - id: ruff-format
-        name: ruff-format
-        entry: ruff format
-        language: system
-        types: [python]
       - id: ruff
-        name: ruff
-        entry: ruff check --fix --show-fixes
-        language: system
-        types: [python]
+        args: [--fix]
   - repo: local
     hooks:
       - id: pylint

.pylintrc

@@ -53,7 +53,7 @@ extension-pkg-whitelist=pyarrow
 
 [MESSAGES CONTROL]
 disable=all
-enable=json-import,disallowed-sql-import,consider-using-transaction
+enable=disallowed-json-import,disallowed-sql-import,consider-using-transaction
 
 
 [REPORTS]

Dockerfile

@@ -18,7 +18,7 @@
 ######################################################################
 # Node stage to deal with static asset construction
 ######################################################################
-ARG PY_VER=3.11.14-slim-trixie
+ARG PY_VER=3.11.13-slim-trixie
 
 # If BUILDPLATFORM is null, set it to 'amd64' (or leave as is otherwise).
 ARG BUILDPLATFORM=${BUILDPLATFORM:-amd64}

README.md

@@ -23,12 +23,8 @@ under the License.
 [![Latest Release on Github](https://img.shields.io/github/v/release/apache/superset?sort=semver)](https://github.com/apache/superset/releases/latest)
 [![Build Status](https://github.com/apache/superset/actions/workflows/superset-python-unittest.yml/badge.svg)](https://github.com/apache/superset/actions)
 [![PyPI version](https://badge.fury.io/py/apache_superset.svg)](https://badge.fury.io/py/apache_superset)
+[![Coverage Status](https://codecov.io/github/apache/superset/coverage.svg?branch=master)](https://codecov.io/github/apache/superset)
 [![PyPI](https://img.shields.io/pypi/pyversions/apache_superset.svg?maxAge=2592000)](https://pypi.python.org/pypi/apache_superset)
-[![GitHub Stars](https://img.shields.io/github/stars/apache/superset?style=social)](https://github.com/apache/superset/stargazers)
-[![Contributors](https://img.shields.io/github/contributors/apache/superset)](https://github.com/apache/superset/graphs/contributors)
-[![Last Commit](https://img.shields.io/github/last-commit/apache/superset)](https://github.com/apache/superset/commits/master)
-[![Open Issues](https://img.shields.io/github/issues/apache/superset)](https://github.com/apache/superset/issues)
-[![Open PRs](https://img.shields.io/github/issues-pr/apache/superset)](https://github.com/apache/superset/pulls)
 [![Get on Slack](https://img.shields.io/badge/slack-join-orange.svg)](http://bit.ly/join-superset-slack)
 [![Documentation](https://img.shields.io/badge/docs-apache.org-blue.svg)](https://superset.apache.org)
 

RESOURCES/FEATURE_FLAGS.md

@@ -68,7 +68,7 @@ These features flags are **safe for production**. They have been tested and will
 
 ### Flags retained for runtime configuration
 
-Currently some of our feature flags act as dynamic configurations that can change
+Currently some of our feature flags act as dynamic configurations that can changed
 on the fly. This acts in contradiction with the typical ephemeral feature flag use case,
 where the flag is used to mature a feature, and eventually deprecated once the feature is
 solid. Eventually we'll likely refactor these under a more formal "dynamic configurations" managed

UPDATING.md

@@ -23,108 +23,6 @@ This file documents any backwards-incompatible changes in Superset and
 assists people when migrating to a new version.
 
 ## Next
-
-### MCP Service
-
-The MCP (Model Context Protocol) service enables AI assistants and automation tools to interact programmatically with Superset.
-
-#### New Features
-- MCP service infrastructure with FastMCP framework
-- Tools for dashboards, charts, datasets, SQL Lab, and instance metadata
-- Optional dependency: install with `pip install apache-superset[fastmcp]`
-- Runs as separate process from Superset web server
-- JWT-based authentication for production deployments
-
-#### New Configuration Options
-
-**Development** (single-user, local testing):
-```python
-# superset_config.py
-MCP_DEV_USERNAME = "admin"  # User for MCP authentication
-MCP_SERVICE_HOST = "localhost"
-MCP_SERVICE_PORT = 5008
-```
-
-**Production** (JWT-based, multi-user):
-```python
-# superset_config.py
-MCP_AUTH_ENABLED = True
-MCP_JWT_ISSUER = "https://your-auth-provider.com"
-MCP_JWT_AUDIENCE = "superset-mcp"
-MCP_JWT_ALGORITHM = "RS256"  # or "HS256" for shared secrets
-
-# Option 1: Use JWKS endpoint (recommended for RS256)
-MCP_JWKS_URI = "https://auth.example.com/.well-known/jwks.json"
-
-# Option 2: Use static public key (RS256)
-MCP_JWT_PUBLIC_KEY = "-----BEGIN PUBLIC KEY-----..."
-
-# Option 3: Use shared secret (HS256)
-MCP_JWT_ALGORITHM = "HS256"
-MCP_JWT_SECRET = "your-shared-secret-key"
-
-# Optional overrides
-MCP_SERVICE_HOST = "0.0.0.0"
-MCP_SERVICE_PORT = 5008
-MCP_SESSION_CONFIG = {
-    "SESSION_COOKIE_SECURE": True,
-    "SESSION_COOKIE_HTTPONLY": True,
-    "SESSION_COOKIE_SAMESITE": "Strict",
-}
-```
-
-#### Running the MCP Service
-
-```bash
-# Development
-superset mcp run --port 5008 --debug
-
-# Production
-superset mcp run --port 5008
-
-# With factory config
-superset mcp run --port 5008 --use-factory-config
-```
-
-#### Deployment Considerations
-
-The MCP service runs as a **separate process** from the Superset web server.
-
-**Important**:
-- Requires same Python environment and configuration as Superset
-- Shares database connections with main Superset app
-- Can be scaled independently from web server
-- Requires `fastmcp` package (optional dependency)
-
-**Installation**:
-```bash
-# Install with MCP support
-pip install apache-superset[fastmcp]
-
-# Or add to requirements.txt
-apache-superset[fastmcp]>=X.Y.Z
-```
-
-**Process Management**:
-Use systemd, supervisord, or Kubernetes to manage the MCP service process.
-See `superset/mcp_service/PRODUCTION.md` for deployment guides.
-
-**Security**:
-- Development: Uses `MCP_DEV_USERNAME` for single-user access
-- Production: **MUST** configure JWT authentication
-- See `superset/mcp_service/SECURITY.md` for details
-
-#### Documentation
-
-- Architecture: `superset/mcp_service/ARCHITECTURE.md`
-- Security: `superset/mcp_service/SECURITY.md`
-- Production: `superset/mcp_service/PRODUCTION.md`
-- Developer Guide: `superset/mcp_service/CLAUDE.md`
-- Quick Start: `superset/mcp_service/README.md`
-
----
-
-- [35621](https://github.com/apache/superset/pull/35621): The default hash algorithm has changed from MD5 to SHA-256 for improved security and FedRAMP compliance. This affects cache keys for thumbnails, dashboard digests, chart digests, and filter option names. Existing cached data will be invalidated upon upgrade. To opt out of this change and maintain backward compatibility, set `HASH_ALGORITHM = "md5"` in your `superset_config.py`.
 - [33055](https://github.com/apache/superset/pull/33055): Upgrades Flask-AppBuilder to 5.0.0. The AUTH_OID authentication type has been deprecated and is no longer available as an option in Flask-AppBuilder. OpenID (OID) is considered a deprecated authentication protocol - if you are using AUTH_OID, you will need to migrate to an alternative authentication method such as OAuth, LDAP, or database authentication before upgrading.
 - [35062](https://github.com/apache/superset/pull/35062): Changed the function signature of `setupExtensions` to `setupCodeOverrides` with options as arguments.
 - [34871](https://github.com/apache/superset/pull/34871): Fixed Jest test hanging issue from Ant Design v5 upgrade. MessageChannel is now mocked in test environment to prevent rc-overflow from causing Jest to hang. Test environment only - no production impact.
@@ -147,31 +45,6 @@ Note: Pillow is now a required dependency (previously optional) to support image
 - [32432](https://github.com/apache/superset/pull/31260) Moves the List Roles FAB view to the frontend and requires `FAB_ADD_SECURITY_API` to be enabled in the configuration and `superset init` to be executed.
 - [34319](https://github.com/apache/superset/pull/34319) Drill to Detail and Drill By is now supported in Embedded mode, and also with the `DASHBOARD_RBAC` FF. If you don't want to expose these features in Embedded / `DASHBOARD_RBAC`, make sure the roles used for Embedded / `DASHBOARD_RBAC`don't have the required permissions to perform D2D actions.
 
-### Breaking Changes
-
-#### CUSTOM_FONT_URLS removed
-
-The `CUSTOM_FONT_URLS` configuration option has been removed. Use the new per-theme `fontUrls` token in `THEME_DEFAULT` or database-managed themes instead.
-
-**Before (5.x):**
-```python
-CUSTOM_FONT_URLS = [
-    "https://fonts.example.com/myfont.css",
-]
-```
-
-**After (6.0):**
-```python
-THEME_DEFAULT = {
-    "token": {
-        "fontUrls": [
-            "https://fonts.example.com/myfont.css",
-        ],
-        # ... other tokens
-    }
-}
-```
-
 ## 5.0.0
 
 - [31976](https://github.com/apache/superset/pull/31976) Removed the `DISABLE_LEGACY_DATASOURCE_EDITOR` feature flag. The previous value of the feature flag was `True` and now the feature is permanently removed.

docker/docker-bootstrap.sh

@@ -80,7 +80,7 @@ case "${1}" in
     ;;
   app)
     echo "Starting web app (using development server)..."
-    flask run -p $PORT --reload --debugger --without-threads --host=0.0.0.0 --exclude-patterns "*/node_modules/*:*/.venv/*:*/build/*:*/__pycache__/*"
+    flask run -p $PORT --reload --debugger --without-threads --host=0.0.0.0
     ;;
   app-gunicorn)
     echo "Starting web app..."

docker/pythonpath_dev/superset_config_docker_light.py

@@ -19,7 +19,6 @@
 
 # Import all settings from the main config first
 from flask_caching.backends.filesystemcache import FileSystemCache
-
 from superset_config import *  # noqa: F403
 
 # Override caching to use simple in-memory cache instead of Redis

docs/.gitignore

@@ -23,6 +23,3 @@ docs/.zshrc
 
 # Gets copied from the root of the project at build time (yarn start / yarn build)
 docs/intro.md
-
-# Generated badge images (downloaded at build time by remark-localize-badges plugin)
-static/badges/

docs/developer_portal/extensions/architecture.md

@@ -248,6 +248,6 @@ This architecture provides several key benefits:
 
 Now that you understand the architecture, explore:
 
+- **[Extension Project Structure](./extension-project-structure)** - How to organize your extension code
+- **[Frontend Contribution Types](./frontend-contribution-types)** - What kinds of extensions you can build
 - **[Quick Start](./quick-start)** - Build your first extension
-- **[Contribution Types](./contribution-types)** - What kinds of extensions you can build
-- **[Development](./development)** - Project structure, APIs, and development workflow

docs/developer_portal/extensions/components/alert.mdx

@@ -1,131 +0,0 @@
----
-title: Alert
-sidebar_label: Alert
----
-
-<!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
--->
-
-import { StoryWithControls } from '../../../src/components/StorybookWrapper';
-import { Alert } from '@apache-superset/core/ui';
-
-# Alert
-
-Alert component for displaying important messages to users. Wraps Ant Design Alert with sensible defaults and improved accessibility.
-
-## Live Example
-
-<StoryWithControls
-  component={Alert}
-  props={{
-  closable: true,
-  type: 'info',
-  message: 'This is a sample alert message.',
-  description: 'Sample description for additional context.',
-  showIcon: true
-}}
-  controls={[
-  {
-    name: 'type',
-    label: 'Type',
-    type: 'select',
-    options: [
-      'info',
-      'error',
-      'warning',
-      'success'
-    ]
-  },
-  {
-    name: 'closable',
-    label: 'Closable',
-    type: 'boolean'
-  },
-  {
-    name: 'showIcon',
-    label: 'Show Icon',
-    type: 'boolean'
-  },
-  {
-    name: 'message',
-    label: 'Message',
-    type: 'text'
-  },
-  {
-    name: 'description',
-    label: 'Description',
-    type: 'text'
-  }
-]}
-/>
-
-## Try It
-
-Edit the code below to experiment with the component:
-
-```tsx live
-function Demo() {
-  return (
-    <Alert
-      closable
-      type="info"
-      message="This is a sample alert message."
-      description="Sample description for additional context."
-      showIcon
-    />
-  );
-}
-```
-
-## Props
-
-| Prop | Type | Default | Description |
-|------|------|---------|-------------|
-| `closable` | `boolean` | `true` | Whether the Alert can be closed with a close button. |
-| `type` | `string` | `"info"` | Type of the alert (e.g., info, error, warning, success). |
-| `message` | `string` | `"This is a sample alert message."` | Message |
-| `description` | `string` | `"Sample description for additional context."` | Description |
-| `showIcon` | `boolean` | `true` | Whether to display an icon in the Alert. |
-
-## Usage in Extensions
-
-This component is available in the `@apache-superset/core/ui` package, which is automatically available to Superset extensions.
-
-```tsx
-import { Alert } from '@apache-superset/core/ui';
-
-function MyExtension() {
-  return (
-    <Alert
-      closable
-      type="info"
-      message="This is a sample alert message."
-    />
-  );
-}
-```
-
-## Source Links
-
-- [Story file](https://github.com/apache/superset/blob/master/superset-frontend/packages/superset-core/src/ui/components/Alert/Alert.stories.tsx)
-- [Component source](https://github.com/apache/superset/blob/master/superset-frontend/packages/superset-core/src/ui/components/Alert/index.tsx)
-
----
-
-*This page was auto-generated from the component's Storybook story.*

docs/developer_portal/extensions/components/index.mdx

@@ -1,93 +0,0 @@
----
-title: Extension Components
-sidebar_label: Overview
-sidebar_position: 1
----
-
-<!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
--->
-
-# Extension Components
-
-These UI components are available to Superset extension developers through the `@apache-superset/core/ui` package. They provide a consistent look and feel with the rest of Superset and are designed to be used in extension panels, views, and other UI elements.
-
-## Available Components
-
-- [Alert](./alert)
-
-## Usage
-
-All components are exported from the `@apache-superset/core/ui` package:
-
-```tsx
-import { Alert } from '@apache-superset/core/ui';
-
-export function MyExtensionPanel() {
-  return (
-    <Alert type="info">
-      Welcome to my extension!
-    </Alert>
-  );
-}
-```
-
-## Adding New Components
-
-Components in `@apache-superset/core/ui` are automatically documented here. To add a new extension component:
-
-1. Add the component to `superset-frontend/packages/superset-core/src/ui/components/`
-2. Export it from `superset-frontend/packages/superset-core/src/ui/components/index.ts`
-3. Create a Storybook story with an `Interactive` export:
-
-```tsx
-export default {
-  title: 'Extension Components/MyComponent',
-  component: MyComponent,
-  parameters: {
-    docs: {
-      description: {
-        component: 'Description of the component...',
-      },
-    },
-  },
-};
-
-export const InteractiveMyComponent = (args) => <MyComponent {...args} />;
-
-InteractiveMyComponent.args = {
-  variant: 'primary',
-  disabled: false,
-};
-
-InteractiveMyComponent.argTypes = {
-  variant: {
-    control: { type: 'select' },
-    options: ['primary', 'secondary'],
-  },
-  disabled: {
-    control: { type: 'boolean' },
-  },
-};
-```
-
-4. Run `yarn start` in `docs/` - the page generates automatically!
-
-## Interactive Documentation
-
-For interactive examples with controls, visit the [Storybook](/storybook/?path=/docs/extension-components--docs).

docs/developer_portal/extensions/contribution-types.md

@@ -1,130 +0,0 @@
----
-title: Contribution Types
-sidebar_position: 4
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Contribution Types
-
-To facilitate the development of extensions, we define a set of well-defined contribution types that extensions can implement. These contribution types serve as the building blocks for extensions, allowing them to interact with the host application and provide new functionality.
-
-## Frontend
-
-Frontend contribution types allow extensions to extend Superset's user interface with new views, commands, and menu items.
-
-### Views
-
-Extensions can add new views or panels to the host application, such as custom SQL Lab panels, dashboards, or other UI components. Each view is registered with a unique ID and can be activated or deactivated as needed. Contribution areas are uniquely identified (e.g., `sqllab.panels` for SQL Lab panels), enabling seamless integration into specific parts of the application.
-
-``` json
-"frontend": {
-  "contributions": {
-    "views": {
-      "sqllab.panels": [
-        {
-          "id": "my_extension.main",
-          "name": "My Panel Name"
-        }
-      ]
-    }
-  }
-}
-```
-
-### Commands
-
-Extensions can define custom commands that can be executed within the host application, such as context-aware actions or menu options. Each command can specify properties like a unique command identifier, an icon, a title, and a description. These commands can be invoked by users through menus, keyboard shortcuts, or other UI elements, enabling extensions to add rich, interactive functionality to Superset.
-
-``` json
-"frontend": {
-  "contributions": {
-    "commands": [
-      {
-        "command": "my_extension.copy_query",
-        "icon": "CopyOutlined",
-        "title": "Copy Query",
-        "description": "Copy the current query to clipboard"
-      }
-    ]
-  }
-}
-```
-
-### Menus
-
-Extensions can contribute new menu items or context menus to the host application, providing users with additional actions and options. Each menu item can specify properties such as the target view, the command to execute, its placement (primary, secondary, or context), and conditions for when it should be displayed. Menu contribution areas are uniquely identified (e.g., `sqllab.editor` for the SQL Lab editor), allowing extensions to seamlessly integrate their functionality into specific menus and workflows within Superset.
-
-``` json
-"frontend": {
-  "contributions": {
-    "menus": {
-      "sqllab.editor": {
-        "primary": [
-          {
-            "view": "builtin.editor",
-            "command": "my_extension.copy_query"
-          }
-        ],
-        "secondary": [
-          {
-            "view": "builtin.editor",
-            "command": "my_extension.prettify"
-          }
-        ],
-        "context": [
-          {
-            "view": "builtin.editor",
-            "command": "my_extension.clear"
-          }
-        ]
-      }
-    }
-  }
-}
-```
-
-## Backend
-
-Backend contribution types allow extensions to extend Superset's server-side capabilities with new API endpoints, MCP tools, and MCP prompts.
-
-### REST API Endpoints
-
-Extensions can register custom REST API endpoints under the `/api/v1/extensions/` namespace. This dedicated namespace prevents conflicts with built-in endpoints and provides a clear separation between core and extension functionality.
-
-``` json
-"backend": {
-  "entryPoints": ["my_extension.entrypoint"],
-  "files": ["backend/src/my_extension/**/*.py"]
-}
-```
-
-The entry point module registers the API with Superset:
-
-``` python
-from superset_core.api.rest_api import add_extension_api
-from .api import MyExtensionAPI
-
-add_extension_api(MyExtensionAPI)
-```
-
-### MCP Tools and Prompts
-
-Extensions can contribute Model Context Protocol (MCP) tools and prompts that AI agents can discover and use. See [MCP Integration](./mcp) for detailed documentation.

docs/developer_portal/extensions/deploying-extension.md

@@ -1,6 +1,6 @@
 ---
-title: Deployment
-sidebar_position: 6
+title: Deploying an Extension
+sidebar_position: 8
 ---
 
 <!--
@@ -22,7 +22,7 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-# Deployment
+# Deploying an Extension
 
 Once an extension has been developed, the deployment process involves packaging and uploading it to the host application.
 
@@ -33,17 +33,13 @@ Packaging is handled by the `superset-extensions bundle` command, which:
 3. Generates a `manifest.json` with build-time metadata, including the contents of `extension.json` and references to built assets.
 4. Packages everything into a `.supx` file (a zip archive with a specific structure required by Superset).
 
-To deploy an extension, place the `.supx` file in the extensions directory configured via `EXTENSIONS_PATH` in your `superset_config.py`:
+Uploading is accomplished through Superset's REST API at `/api/v1/extensions/import/`. The endpoint accepts the `.supx` file as form data and processes it by:
 
-``` python
-EXTENSIONS_PATH = "/path/to/extensions"
-```
+1. Extracting and validating the extension metadata and manifest.
+2. Storing extension assets in the metadata database for dynamic loading.
+3. Registering the extension in the metadata database, including its name, version, author, and capabilities.
+4. Automatically activating the extension, making it immediately available for use and management via the Superset UI or API.
 
-During application startup, Superset automatically discovers and loads all `.supx` files from this directory:
+This API-driven approach enables automated deployment workflows and simplifies extension management for administrators. Extensions can be uploaded through the Swagger UI, programmatically via scripts, or through the management interface:
 
-1. Scans the configured directory for `.supx` files.
-2. Validates each file is a properly formatted zip archive.
-3. Extracts and validates the extension manifest and metadata.
-4. Loads the extension, making it available for use.
-
-This file-based approach simplifies deployment in containerized environments and enables version control of extensions alongside infrastructure configuration.
+https://github.com/user-attachments/assets/98b16cdd-8ec5-4812-9d5e-9915badd8f0d

docs/developer_portal/extensions/development-mode.md

@@ -0,0 +1,48 @@
+---
+title: Development Mode
+sidebar_position: 10
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Development Mode
+
+Development mode accelerates extension development by letting developers see changes in Superset quickly, without the need for repeated packaging and uploading. To enable development mode, set the `LOCAL_EXTENSIONS` configuration in your `superset_config.py`:
+
+``` python
+LOCAL_EXTENSIONS = [
+    "/path/to/your/extension1",
+    "/path/to/your/extension2",
+]
+```
+
+This instructs Superset to load and serve extensions directly from disk, so you can iterate quickly. Running `superset-extensions dev` watches for file changes and rebuilds assets automatically, while the Webpack development server (started separately with `npm run dev-server`) serves updated files as soon as they're modified. This enables immediate feedback for React components, styles, and other frontend code. Changes to backend files are also detected automatically and immediately synced, ensuring that both frontend and backend updates are reflected in your development environment.
+
+Example output when running in development mode:
+
+```
+superset-extensions dev
+
+⚙️  Building frontend assets…
+✅ Frontend rebuilt
+✅ Backend files synced
+✅ Manifest updated
+👀 Watching for changes in: /dataset_references/frontend, /dataset_references/backend
+```

docs/developer_portal/extensions/development.md

@@ -1,309 +0,0 @@
----
-title: Development
-sidebar_position: 5
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Development
-
-This guide covers everything you need to know about developing extensions for Superset, from project structure to development workflow.
-
-## Project Structure
-
-The [apache-superset-extensions-cli](https://github.com/apache/superset/tree/master/superset-extensions-cli) package provides a command-line interface (CLI) that streamlines the extension development workflow. It offers the following commands:
-
-```
-superset-extensions init: Generates the initial folder structure and scaffolds a new extension project.
-
-superset-extensions build: Builds extension assets.
-
-superset-extensions bundle: Packages the extension into a .supx file.
-
-superset-extensions dev: Automatically rebuilds the extension as files change.
-```
-
-When creating a new extension with `superset-extensions init <extension-name>`, the CLI generates a standardized folder structure:
-
-```
-dataset_references/
-├── extension.json
-├── frontend/
-│   ├── src/
-│   ├── webpack.config.js
-│   ├── tsconfig.json
-│   └── package.json
-├── backend/
-│   ├── src/
-│        └── dataset_references/
-│   ├── tests/
-│   ├── pyproject.toml
-│   └── requirements.txt
-├── dist/
-│   ├── manifest.json
-│   ├── frontend
-│        └── dist/
-│             ├── remoteEntry.d7a9225d042e4ccb6354.js
-│             └── 900.038b20cdff6d49cfa8d9.js
-│   └── backend
-│        └── dataset_references/
-│             ├── __init__.py
-│             ├── api.py
-│             └── entrypoint.py
-├── dataset_references-1.0.0.supx
-└── README.md
-```
-
-The `extension.json` file serves as the declared metadata for the extension, containing the extension's name, version, author, description, and a list of capabilities. This file is essential for the host application to understand how to load and manage the extension.
-
-The `frontend` directory contains the source code for the frontend components of the extension, including React components, styles, and assets. The `webpack.config.js` file is used to configure Webpack for building the frontend code, while the `tsconfig.json` file defines the TypeScript configuration for the project. The `package.json` file specifies the dependencies and scripts for building and testing the frontend code.
-
-The `backend` directory contains the source code for the backend components of the extension, including Python modules, tests, and configuration files. The `pyproject.toml` file is used to define the Python package and its dependencies, while the `requirements.txt` file lists the required Python packages for the extension. The `src` folder contains the functional backend source files, `tests` directory contains unit tests for the backend code, ensuring that the extension behaves as expected and meets the defined requirements.
-
-The `dist` directory is built when running the `build` or `dev` command, and contains the files that will be included in the bundle. The `manifest.json` file contains critical metadata about the extension, including the majority of the contents of the `extension.json` file, but also other build-time information, like the name of the built Webpack Module Federation remote entry file. The files in the `dist` directory will be zipped into the final `.supx` file. Although this file is technically a zip archive, the `.supx` extension makes it clear that it is a Superset extension package and follows a specific file layout. This packaged file can be distributed and installed in Superset instances.
-
-The `README.md` file provides documentation and instructions for using the extension, including how to install, configure, and use its functionality.
-
-## Extension Metadata
-
-The `extension.json` file contains all metadata necessary for the host application to understand and manage the extension:
-
-```json
-{
-  "name": "dataset_references",
-  "version": "1.0.0",
-  "frontend": {
-    "contributions": {
-      "views": {
-        "sqllab.panels": [
-          {
-            "id": "dataset_references.main",
-            "name": "Dataset references"
-          }
-        ]
-      }
-    },
-    "moduleFederation": {
-      "exposes": ["./index"]
-    }
-  },
-  "backend": {
-    "entryPoints": ["dataset_references.entrypoint"],
-    "files": ["backend/src/dataset_references/**/*.py"]
-  }
-}
-```
-
-The `contributions` section declares how the extension extends Superset's functionality through views, commands, menus, and other contribution types. The `backend` section specifies entry points and files to include in the bundle.
-
-## Interacting with the Host
-
-Extensions interact with Superset through well-defined, versioned APIs provided by the `@apache-superset/core` (frontend) and `apache-superset-core` (backend) packages. These APIs are designed to be stable, discoverable, and consistent for both built-in and external extensions.
-
-**Note**: The `superset_core.api` module provides abstract classes that are replaced with concrete implementations via dependency injection when Superset initializes. This allows extensions to use the same interfaces as the host application.
-
-### Frontend APIs
-
-The frontend extension APIs (via `@apache-superset/core`) are organized into logical namespaces such as `authentication`, `commands`, `extensions`, `sqlLab`, and others. Each namespace groups related functionality, making it easy for extension authors to discover and use the APIs relevant to their needs. For example, the `sqlLab` namespace provides events and methods specific to SQL Lab, allowing extensions to react to user actions and interact with the SQL Lab environment:
-
-```typescript
-export const getCurrentTab: () => Tab | undefined;
-
-export const getDatabases: () => Database[];
-
-export const getTabs: () => Tab[];
-
-export const onDidChangeEditorContent: Event<string>;
-
-export const onDidClosePanel: Event<Panel>;
-
-export const onDidChangeActivePanel: Event<Panel>;
-
-export const onDidChangeTabTitle: Event<string>;
-
-export const onDidQueryRun: Event<Editor>;
-
-export const onDidQueryStop: Event<Editor>;
-```
-
-The following code demonstrates more examples of the existing frontend APIs:
-
-```typescript
-import { core, commands, sqlLab, authentication, Button } from '@apache-superset/core';
-import MyPanel from './MyPanel';
-
-export function activate(context) {
-  // Register a new panel (view) in SQL Lab and use shared UI components in your extension's React code
-  const panelDisposable = core.registerView('my_extension.panel', <MyPanel><Button/></MyPanel>);
-
-  // Register a custom command
-  const commandDisposable = commands.registerCommand('my_extension.copy_query', {
-    title: 'Copy Query',
-    execute: () => {
-      // Command logic here
-    },
-  });
-
-  // Listen for query run events in SQL Lab
-  const eventDisposable = sqlLab.onDidQueryRun(editor => {
-    // Handle query execution event
-  });
-
-  // Access a CSRF token for secure API requests
-  authentication.getCSRFToken().then(token => {
-    // Use token as needed
-  });
-
-  // Add all disposables for automatic cleanup on deactivation
-  context.subscriptions.push(panelDisposable, commandDisposable, eventDisposable);
-}
-```
-
-### Backend APIs
-
-Backend APIs (via `apache-superset-core`) follow a similar pattern, providing access to Superset's models, sessions, and query capabilities. Extensions can register REST API endpoints, access the metadata database, and interact with Superset's core functionality.
-
-Extension endpoints are registered under a dedicated `/extensions` namespace to avoid conflicting with built-in endpoints and also because they don't share the same version constraints. By grouping all extension endpoints under `/extensions`, Superset establishes a clear boundary between core and extension functionality, making it easier to manage, document, and secure both types of APIs.
-
-```python
-from superset_core.api.models import Database, get_session
-from superset_core.api.daos import DatabaseDAO
-from superset_core.api.rest_api import add_extension_api
-from .api import DatasetReferencesAPI
-
-# Register a new extension REST API
-add_extension_api(DatasetReferencesAPI)
-
-# Fetch Superset entities via the DAO to apply base filters that filter out entities
-# that the user doesn't have access to
-databases = DatabaseDAO.find_all()
-
-# ..or apply simple filters on top of base filters
-databases = DatabaseDAO.filter_by(uuid=database.uuid)
-if not databases:
-    raise Exception("Database not found")
-
-return databases[0]
-
-# Perform complex queries using SQLAlchemy Query, also filtering out
-# inaccessible entities
-session = get_session()
-databases_query = session.query(Database).filter(
-    Database.database_name.ilike("%abc%")
-)
-return DatabaseDAO.query(databases_query)
-```
-
-In the future, we plan to expand the backend APIs to support configuring security models, database engines, SQL Alchemy dialects, etc.
-
-## Development Mode
-
-Development mode accelerates extension development by letting developers see changes in Superset quickly, without the need for repeated packaging and uploading. To enable development mode, set the `LOCAL_EXTENSIONS` configuration in your `superset_config.py`:
-
-```python
-LOCAL_EXTENSIONS = [
-    "/path/to/your/extension1",
-    "/path/to/your/extension2",
-]
-```
-
-This instructs Superset to load and serve extensions directly from disk, so you can iterate quickly. Running `superset-extensions dev` watches for file changes and rebuilds assets automatically, while the Webpack development server (started separately with `npm run dev-server`) serves updated files as soon as they're modified. This enables immediate feedback for React components, styles, and other frontend code. Changes to backend files are also detected automatically and immediately synced, ensuring that both frontend and backend updates are reflected in your development environment.
-
-Example output when running in development mode:
-
-```
-superset-extensions dev
-
-⚙️  Building frontend assets…
-✅ Frontend rebuilt
-✅ Backend files synced
-✅ Manifest updated
-👀 Watching for changes in: /dataset_references/frontend, /dataset_references/backend
-```
-
-## Contributing Extension-Compatible Components
-
-Components in `@apache-superset/core` are automatically documented in the Developer Portal. Simply add a component to the package and it will appear in the extension documentation.
-
-### Requirements
-
-1. **Location**: The component must be in `superset-frontend/packages/superset-core/src/ui/components/`
-2. **Exported**: The component must be exported from the package's `index.ts`
-3. **Story**: The component must have a Storybook story
-
-### Creating a Story for Your Component
-
-Create a story file with an `Interactive` export that defines args and argTypes:
-
-```typescript
-// MyComponent.stories.tsx
-import { MyComponent } from '.';
-
-export default {
-  title: 'Extension Components/MyComponent',
-  component: MyComponent,
-  parameters: {
-    docs: {
-      description: {
-        component: 'A brief description of what this component does.',
-      },
-    },
-  },
-};
-
-// Define an interactive story with args
-export const InteractiveMyComponent = (args) => <MyComponent {...args} />;
-
-InteractiveMyComponent.args = {
-  variant: 'primary',
-  disabled: false,
-};
-
-InteractiveMyComponent.argTypes = {
-  variant: {
-    control: { type: 'select' },
-    options: ['primary', 'secondary', 'danger'],
-  },
-  disabled: {
-    control: { type: 'boolean' },
-  },
-};
-```
-
-### How Documentation is Generated
-
-When the docs site is built (`yarn start` or `yarn build` in the `docs/` directory):
-
-1. The `generate-extension-components` script scans all stories in `superset-core`
-2. For each story, it generates an MDX page with:
-   - Component description
-   - **Live interactive example** with controls extracted from `argTypes`
-   - **Editable code playground** for experimentation
-   - Props table from story `args`
-   - Usage code snippet
-   - Links to source files
-3. Pages appear automatically in **Developer Portal → Extensions → Components**
-
-### Best Practices
-
-- **Use descriptive titles**: The title path determines the component's location in docs (e.g., `Extension Components/Alert`)
-- **Define argTypes**: These become interactive controls in the documentation
-- **Provide default args**: These populate the initial state of the live example
-- **Write clear descriptions**: Help extension developers understand when to use each component

docs/developer_portal/extensions/extension-metadata.md

@@ -0,0 +1,55 @@
+---
+title: Extension Metadata
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Extension Metadata
+
+The `extension.json` file contains all metadata necessary for the host application to understand and manage the extension:
+
+``` json
+{
+  "name": "dataset_references",
+  "version": "1.0.0",
+  "frontend": {
+    "contributions": {
+      "views": {
+        "sqllab.panels": [
+          {
+            "id": "dataset_references.main",
+            "name": "Dataset references"
+          }
+        ]
+      }
+    },
+    "moduleFederation": {
+      "exposes": ["./index"]
+    }
+  },
+  "backend": {
+    "entryPoints": ["dataset_references.entrypoint"],
+    "files": ["backend/src/dataset_references/**/*.py"]
+  },
+}
+```
+
+The `contributions` section declares how the extension extends Superset's functionality through views, commands, menus, and other contribution types. The `backend` section specifies entry points and files to include in the bundle.

docs/developer_portal/extensions/extension-points/sqllab.md

@@ -1,209 +0,0 @@
----
-title: SQL Lab
-sidebar_position: 1
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# SQL Lab Extension Points
-
-SQL Lab provides 5 extension points where extensions can contribute custom UI components. Each area serves a specific purpose and can be customized to add new functionality.
-
-## Layout Overview
-
-```
-┌──────────┬─────────────────────────────────────────┬─────────────┐
-│          │                                         │             │
-│          │                                         │             │
-│          │                Editor                   │             │
-│          │                                         │             │
-│   Left   │                                         │    Right    │
-│  Sidebar ├─────────────────────────────────────────┤   Sidebar   │
-│          │                                         │             │
-│          │                Panels                   │             │
-│          │                                         │             │
-│          │                                         │             │
-│          │                                         │             │
-├──────────┴─────────────────────────────────────────┴─────────────┤
-│                          Status Bar                              │
-└──────────────────────────────────────────────────────────────────┘
-```
-
-| Extension Point   | ID                    | Description                                                |
-| ----------------- | --------------------- | ---------------------------------------------------------- |
-| **Left Sidebar**  | `sqllab.leftSidebar`  | Navigation and browsing (database explorer, saved queries) |
-| **Editor**        | `sqllab.editor`       | SQL query editor workspace                                 |
-| **Right Sidebar** | `sqllab.rightSidebar` | Contextual tools (AI assistants, query analysis)           |
-| **Panels**        | `sqllab.panels`       | Results and related views (visualizations, data profiling) |
-| **Status Bar**    | `sqllab.statusBar`    | Connection status and query metrics                        |
-
-## Area Customizations
-
-Each extension point area supports three types of action customizations:
-
-```
-┌───────────────────────────────────────────────────────────────┐
-│  Area Title                         [Button] [Button]   [•••] │
-├───────────────────────────────────────────────────────────────┤
-│                                                               │
-│                                                               │
-│                          Area Content                         │
-│                                                               │
-│                  (right-click for context menu)               │
-│                                                               │
-│                                                               │
-└───────────────────────────────────────────────────────────────┘
-```
-
-| Action Type           | Location          | Use Case                                              |
-| --------------------- | ----------------- | ----------------------------------------------------- |
-| **Primary Actions**   | Top-right buttons | Frequently used actions (e.g., run, refresh, add new) |
-| **Secondary Actions** | 3-dot menu (•••)  | Less common actions (e.g., export, settings)          |
-| **Context Actions**   | Right-click menu  | Context-sensitive actions on content                  |
-
-## Examples
-
-### Adding a Panel
-
-This example adds a "Data Profiler" panel to SQL Lab:
-
-```json
-{
-  "name": "data_profiler",
-  "version": "1.0.0",
-  "frontend": {
-    "contributions": {
-      "views": {
-        "sqllab.panels": [
-          {
-            "id": "data_profiler.main",
-            "name": "Data Profiler"
-          }
-        ]
-      }
-    }
-  }
-}
-```
-
-```typescript
-import { core } from '@apache-superset/core';
-import DataProfilerPanel from './DataProfilerPanel';
-
-export function activate(context) {
-  // Register the panel view with the ID declared in extension.json
-  const disposable = core.registerView('data_profiler.main', <DataProfilerPanel />);
-  context.subscriptions.push(disposable);
-}
-```
-
-### Adding Actions to the Editor
-
-This example adds primary, secondary, and context actions to the editor:
-
-```json
-{
-  "name": "query_tools",
-  "version": "1.0.0",
-  "frontend": {
-    "contributions": {
-      "commands": [
-        {
-          "command": "query_tools.format",
-          "title": "Format Query",
-          "icon": "FormatPainterOutlined"
-        },
-        {
-          "command": "query_tools.explain",
-          "title": "Explain Query"
-        },
-        {
-          "command": "query_tools.copy_as_cte",
-          "title": "Copy as CTE"
-        }
-      ],
-      "menus": {
-        "sqllab.editor": {
-          "primary": [
-            {
-              "view": "builtin.editor",
-              "command": "query_tools.format"
-            }
-          ],
-          "secondary": [
-            {
-              "view": "builtin.editor",
-              "command": "query_tools.explain"
-            }
-          ],
-          "context": [
-            {
-              "view": "builtin.editor",
-              "command": "query_tools.copy_as_cte"
-            }
-          ]
-        }
-      }
-    }
-  }
-}
-```
-
-```typescript
-import { commands, sqlLab } from '@apache-superset/core';
-
-export function activate(context) {
-  // Register the commands declared in extension.json
-  const formatCommand = commands.registerCommand('query_tools.format', {
-    execute: () => {
-      const tab = sqlLab.getCurrentTab();
-      if (tab?.editor) {
-        // Format the SQL query
-      }
-    },
-  });
-
-  const explainCommand = commands.registerCommand('query_tools.explain', {
-    execute: () => {
-      const tab = sqlLab.getCurrentTab();
-      if (tab?.editor) {
-        // Show query explanation
-      }
-    },
-  });
-
-  const copyAsCteCommand = commands.registerCommand('query_tools.copy_as_cte', {
-    execute: () => {
-      const tab = sqlLab.getCurrentTab();
-      if (tab?.editor) {
-        // Copy selected text as CTE
-      }
-    },
-  });
-
-  context.subscriptions.push(formatCommand, explainCommand, copyAsCteCommand);
-}
-```
-
-## Next Steps
-
-- **[Contribution Types](../contribution-types)** - Learn about other contribution types (commands, menus)
-- **[Development](../development)** - Set up your development environment
-- **[Quick Start](../quick-start)** - Build a complete extension

docs/developer_portal/extensions/extension-project-structure.md

@@ -0,0 +1,78 @@
+---
+title: Extension Project Structure
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Extension Project Structure
+
+The `apache-superset-extensions-cli` package provides a command-line interface (CLI) that streamlines the extension development workflow. It offers the following commands:
+
+```
+superset-extensions init: Generates the initial folder structure and scaffolds a new extension project.
+
+superset-extensions build: Builds extension assets.
+
+superset-extensions bundle: Packages the extension into a .supx file.
+
+superset-extensions dev: Automatically rebuilds the extension as files change.
+```
+
+When creating a new extension with `superset-extensions init <extension-name>`, the CLI generates a standardized folder structure:
+
+```
+dataset_references/
+├── extension.json
+├── frontend/
+│   ├── src/
+│   ├── webpack.config.js
+│   ├── tsconfig.json
+│   └── package.json
+├── backend/
+│   ├── src/
+│        └── dataset_references/
+│   ├── tests/
+│   ├── pyproject.toml
+│   └── requirements.txt
+├── dist/
+│   ├── manifest.json
+│   ├── frontend
+│        └── dist/
+│             ├── remoteEntry.d7a9225d042e4ccb6354.js
+│             └── 900.038b20cdff6d49cfa8d9.js
+│   └── backend
+│        └── dataset_references/
+│             ├── __init__.py
+│             ├── api.py
+│             └── entrypoint.py
+├── dataset_references-1.0.0.supx
+└── README.md
+```
+
+The `extension.json` file serves as the declared metadata for the extension, containing the extension's name, version, author, description, and a list of capabilities. This file is essential for the host application to understand how to load and manage the extension.
+
+The `frontend` directory contains the source code for the frontend components of the extension, including React components, styles, and assets. The `webpack.config.js` file is used to configure Webpack for building the frontend code, while the `tsconfig.json` file defines the TypeScript configuration for the project. The `package.json` file specifies the dependencies and scripts for building and testing the frontend code.
+
+The `backend` directory contains the source code for the backend components of the extension, including Python modules, tests, and configuration files. The `pyproject.toml` file is used to define the Python package and its dependencies, while the r`equirements.txt` file lists the required Python packages for the extension. The `src` folder contains the functional backend source files, `tests` directory contains unit tests for the backend code, ensuring that the extension behaves as expected and meets the defined requirements.
+
+The `dist` directory is built when running the `build` or `dev` command, and contains the files that will be included in the bundle. The `manifest.json` file contains critical metadata about the extension, including the majority of the contents of the `extension.json` file, but also other build-time information, like the name of the built Webpack Module Federation remote entry file. The files in the `dist` directory will be zipped into the final `.supx` file. Although this file is technically a zip archive, the `.supx` extension makes it clear that it is a Superset extension package and follows a specific file layout. This packaged file can be distributed and installed in Superset instances.
+
+The `README.md` file provides documentation and instructions for using the extension, including how to install, configure, and use its functionality.

docs/developer_portal/extensions/frontend-contribution-types.md

@@ -0,0 +1,90 @@
+---
+title: Frontend Contribution Types
+sidebar_position: 5
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Frontend Contribution Types
+
+To facilitate the development of extensions, we will define a set of well-defined contribution types that extensions can implement. These contribution types will serve as the building blocks for extensions, allowing them to interact with the host application and provide new functionality. The initial set of contribution types will include:
+
+## Views
+
+Extensions can add new views or panels to the host application, such as custom SQL Lab panels, dashboards, or other UI components. Each view is registered with a unique ID and can be activated or deactivated as needed. Contribution areas are uniquely identified (e.g., `sqllab.panels` for SQL Lab panels), enabling seamless integration into specific parts of the application.
+
+``` json
+"views": {
+  "sqllab.panels": [
+    {
+      "id": "dataset_references.main",
+      "name": "Table references"
+    }
+  ]
+},
+```
+
+## Commands
+
+Extensions can define custom commands that can be executed within the host application, such as context-aware actions or menu options. Each command can specify properties like a unique command identifier, an icon, a title, and a description. These commands can be invoked by users through menus, keyboard shortcuts, or other UI elements, enabling extensions to add rich, interactive functionality to Superset.
+
+``` json
+"commands": [
+  {
+    "command": "extension1.copy_query",
+    "icon": "CopyOutlined",
+    "title": "Copy Query",
+    "description": "Copy the current query to clipboard"
+  },
+]
+```
+
+## Menus
+
+Extensions can contribute new menu items or context menus to the host application, providing users with additional actions and options. Each menu item can specify properties such as the target view, the command to execute, its placement (primary, secondary, or context), and conditions for when it should be displayed. Menu contribution areas are uniquely identified (e.g., `sqllab.editor` for the SQL Lab editor), allowing extensions to seamlessly integrate their functionality into specific menus and workflows within Superset.
+
+``` json
+"menus": {
+  "sqllab.editor": {
+    "primary": [
+      {
+        "view": "builtin.editor",
+        "command": "extension1.copy_query"
+      }
+    ],
+    "secondary": [
+      {
+        "view": "builtin.editor",
+        "command": "extension1.prettify"
+      }
+    ],
+    "context": [
+      {
+        "view": "builtin.editor",
+        "command": "extension1.clear"
+      },
+      {
+        "view": "builtin.editor",
+     "command": "extension1.refresh"
+      }
+    ]
+  },
+}
+```

docs/developer_portal/extensions/interacting-with-host.md

@@ -0,0 +1,120 @@
+---
+title: Interacting with the Host
+sidebar_position: 6
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Interacting with the Host
+
+Extensions interact with Superset through well-defined, versioned APIs provided by the `@apache-superset/core` (frontend) and `apache-superset-core` (backend) packages. These APIs are designed to be stable, discoverable, and consistent for both built-in and external extensions.
+
+**Frontend APIs** (via `@apache-superset/core)`:
+
+The frontend extension APIs in Superset are organized into logical namespaces such as `authentication`, `commands`, `extensions`, `sqlLab`, and others. Each namespace groups related functionality, making it easy for extension authors to discover and use the APIs relevant to their needs. For example, the `sqlLab` namespace provides events and methods specific to SQL Lab, allowing extensions to react to user actions and interact with the SQL Lab environment:
+
+``` typescript
+export const getCurrentTab: () => Tab | undefined;
+
+export const getDatabases: () => Database[];
+
+export const getTabs: () => Tab[];
+
+export const onDidChangeEditorContent: Event<string>;
+
+export const onDidClosePanel: Event<Panel>;
+
+export const onDidChangeActivePanel: Event<Panel>;
+
+export const onDidChangeTabTitle: Event<string>;
+
+export const onDidQueryRun: Event<Editor>;
+
+export const onDidQueryStop: Event<Editor>;
+```
+
+The following code demonstrates more examples of the existing frontend APIs:
+
+``` typescript
+import { core, commands, sqlLab, authentication, Button } from '@apache-superset/core';
+import MyPanel from './MyPanel';
+
+export function activate(context) {
+  // Register a new panel (view) in SQL Lab and use shared UI components in your extension's React code
+  const panelDisposable = core.registerView('my_extension.panel', <MyPanel><Button/></MyPanel>);
+
+  // Register a custom command
+  const commandDisposable = commands.registerCommand('my_extension.copy_query', {
+    title: 'Copy Query',
+    execute: () => {
+      // Command logic here
+    },
+  });
+
+  // Listen for query run events in SQL Lab
+  const eventDisposable = sqlLab.onDidQueryRun(editor => {
+    // Handle query execution event
+  });
+
+  // Access a CSRF token for secure API requests
+  authentication.getCSRFToken().then(token => {
+    // Use token as needed
+  });
+
+  // Add all disposables for automatic cleanup on deactivation
+  context.subscriptions.push(panelDisposable, commandDisposable, eventDisposable);
+}
+```
+
+**Backend APIs** (via `apache-superset-core`):
+
+Backend APIs follow a similar pattern, providing access to Superset's models, sessions, and query capabilities. Extensions can register REST API endpoints, access the metadata database, and interact with Superset's core functionality.
+
+Extension endpoints are registered under a dedicated `/extensions` namespace to avoid conflicting with built-in endpoints and also because they don't share the same version constraints. By grouping all extension endpoints under `/extensions`, Superset establishes a clear boundary between core and extension functionality, making it easier to manage, document, and secure both types of APIs.
+
+``` python
+from superset_core.api import rest_api, models, query
+from .api import DatasetReferencesAPI
+
+# Register a new extension REST API
+rest_api.add_extension_api(DatasetReferencesAPI)
+
+# Access Superset models with simple queries that filter out entities that
+# the user doesn't have access to
+databases = models.get_databases(id=database_id)
+if not databases:
+    return self.response_404()
+
+database = databases[0]
+
+# Perform complex queries using SQLAlchemy BaseQuery, also filtering
+# out inaccessible entities
+session = models.get_session()
+db_model = models.get_database_model())
+database_query = session.query(db_model.database_name.ilike("%abc%")
+databases_containing_abc = models.get_databases(query)
+
+# Bypass security model for highly custom use cases
+session = models.get_session()
+db_model = models.get_database_model())
+all_databases_containg_abc = session.query(db_model.database_name.ilike("%abc%").all()
+```
+
+In the future, we plan to expand the backend APIs to support configuring security models, database engines, SQL Alchemy dialects, etc.

docs/developer_portal/extensions/mcp.md

@@ -1,459 +0,0 @@
----
-title: MCP Integration
-hide_title: true
-sidebar_position: 7
-version: 1
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# MCP Integration
-
-Model Context Protocol (MCP) integration allows extensions to register custom AI agent capabilities that integrate seamlessly with Superset's MCP service. Extensions can provide both **tools** (executable functions) and **prompts** (interactive guidance) that AI agents can discover and use.
-
-## What is MCP?
-
-MCP enables extensions to extend Superset's AI capabilities in two ways:
-
-### MCP Tools
-Tools are Python functions that AI agents can call to perform specific tasks. They provide executable functionality that extends Superset's capabilities.
-
-**Examples of MCP tools:**
-- Data processing and transformation functions
-- Custom analytics calculations
-- Integration with external APIs
-- Specialized report generation
-- Business-specific operations
-
-### MCP Prompts
-Prompts provide interactive guidance and context to AI agents. They help agents understand how to better assist users with specific workflows or domain knowledge.
-
-**Examples of MCP prompts:**
-- Step-by-step workflow guidance
-- Domain-specific context and knowledge
-- Interactive troubleshooting assistance
-- Template generation helpers
-- Best practices recommendations
-
-## Getting Started
-
-## MCP Tools
-
-### Basic Tool Registration
-
-The simplest way to create an MCP tool is using the `@tool` decorator:
-
-```python
-from superset_core.mcp import tool
-
-@tool
-def hello_world() -> dict:
-    """A simple greeting tool."""
-    return {"message": "Hello from my extension!"}
-```
-
-This creates a tool that AI agents can call by name. The tool name defaults to the function name.
-
-### Decorator Parameters
-
-The `@tool` decorator accepts several optional parameters:
-
-**Parameter details:**
-- **`name`**: Tool identifier (AI agents use this to call your tool)
-- **`description`**: Explains what the tool does (helps AI agents decide when to use it)
-- **`tags`**: Categories for organization and discovery
-- **`protect`**: Whether the tool requires user authentication (defaults to `True`)
-
-### Naming Your Tools
-
-For extensions, include your extension ID in tool names to avoid conflicts:
-
-## Complete Example
-
-Here's a more comprehensive example showing best practices:
-
-```python
-# backend/mcp_tools.py
-import random
-from datetime import datetime, timezone
-from pydantic import BaseModel, Field
-from superset_core.mcp import tool
-
-class RandomNumberRequest(BaseModel):
-    """Request schema for random number generation."""
-
-    min_value: int = Field(
-        description="Minimum value (inclusive) for random number generation",
-        ge=-2147483648,
-        le=2147483647
-    )
-    max_value: int = Field(
-        description="Maximum value (inclusive) for random number generation",
-        ge=-2147483648,
-        le=2147483647
-    )
-
-@tool(
-    name="example_extension.random_number",
-    tags=["extension", "utility", "random", "generator"]
-)
-def random_number_generator(request: RandomNumberRequest) -> dict:
-    """
-    Generate a random integer between specified bounds.
-
-    This tool validates input ranges and provides detailed error messages
-    for invalid requests.
-    """
-
-    # Validate business logic (Pydantic handles type/range validation)
-    if request.min_value > request.max_value:
-        return {
-            "status": "error",
-            "error": f"min_value ({request.min_value}) cannot be greater than max_value ({request.max_value})",
-            "timestamp": datetime.now(timezone.utc).isoformat()
-        }
-
-    # Generate random number
-    result = random.randint(request.min_value, request.max_value)
-
-    return {
-        "status": "success",
-        "random_number": result,
-        "min_value": request.min_value,
-        "max_value": request.max_value,
-        "range_size": request.max_value - request.min_value + 1,
-        "timestamp": datetime.now(timezone.utc).isoformat()
-    }
-```
-
-## Best Practices
-
-### Response Format
-
-Use consistent response structures:
-
-```python
-# Success response
-{
-    "status": "success",
-    "result": "your_data_here",
-    "timestamp": "2024-01-01T00:00:00Z"
-}
-
-# Error response
-{
-    "status": "error",
-    "error": "Clear error message",
-    "timestamp": "2024-01-01T00:00:00Z"
-}
-```
-
-### Documentation
-
-Write clear descriptions and docstrings:
-
-```python
-@tool(
-    name="my_extension.process_data",
-    description="Process customer data and generate insights. Requires valid customer ID and date range.",
-    tags=["analytics", "customer", "reporting"]
-)
-def process_data(customer_id: int, start_date: str, end_date: str) -> dict:
-    """
-    Process customer data for the specified date range.
-
-    This tool analyzes customer behavior patterns and generates
-    actionable insights for business decision-making.
-
-    Args:
-        customer_id: Unique customer identifier
-        start_date: Analysis start date (YYYY-MM-DD format)
-        end_date: Analysis end date (YYYY-MM-DD format)
-
-    Returns:
-        Dictionary containing analysis results and recommendations
-    """
-    # Implementation here
-    pass
-```
-
-### Tool Naming
-
-- **Extension tools**: Use prefixed names like `my_extension.tool_name`
-- **Descriptive names**: `calculate_tax_amount` vs `calculate`
-- **Consistent naming**: Follow patterns within your extension
-
-## How AI Agents Use Your Tools
-
-Once registered, AI agents can discover and use your tools automatically:
-
-```
-User: "Generate a random number between 1 and 100"
-Agent: I'll use the random number generator tool.
-→ Calls: example_extension.random_number(min_value=1, max_value=100)
-← Returns: {"status": "success", "random_number": 42, ...}
-Agent: I generated the number 42 for you.
-```
-
-The AI agent sees your tool's:
-- **Name**: How to call it
-- **Description**: What it does and when to use it
-- **Parameters**: What inputs it expects (from Pydantic schema)
-- **Tags**: Categories for discovery
-
-## Troubleshooting
-
-### Tool Not Available to AI Agents
-
-1. **Check extension registration**: Verify your tool module is listed in extension entrypoints
-2. **Verify decorator**: Ensure `@tool` is correctly applied
-3. **Extension loading**: Confirm your extension is installed and enabled
-
-### Input Validation Errors
-
-1. **Pydantic models**: Ensure field types match expected inputs
-2. **Field constraints**: Check min/max values and string lengths are reasonable
-3. **Required fields**: Verify which parameters are required vs optional
-
-### Runtime Issues
-
-1. **Error handling**: Add try/catch blocks with clear error messages
-2. **Response format**: Use consistent status/error/timestamp structure
-3. **Testing**: Test your tools with various input scenarios
-
-### Development Tips
-
-1. **Start simple**: Begin with basic tools, add complexity gradually
-2. **Test locally**: Use MCP clients (like Claude Desktop) to test your tools
-3. **Clear descriptions**: Write tool descriptions as if explaining to a new user
-4. **Meaningful tags**: Use tags that help categorize and discover tools
-5. **Error messages**: Provide specific, actionable error messages
-
-## MCP Prompts
-
-### Basic Prompt Registration
-
-Create interactive prompts using the `@prompt` decorator:
-
-```python
-from superset_core.mcp import prompt
-from fastmcp import Context
-
-@prompt("my_extension.workflow_guide")
-async def workflow_guide(ctx: Context) -> str:
-    """Interactive guide for data analysis workflows."""
-    return """
-    # Data Analysis Workflow Guide
-
-    Here's a step-by-step approach to effective data analysis in Superset:
-
-    ## 1. Data Discovery
-    - Start by exploring your datasets using the dataset browser
-    - Check data quality and identify key metrics
-    - Look for patterns and relationships in your data
-
-    ## 2. Chart Creation
-    - Choose appropriate visualizations for your data types
-    - Apply filters to focus on relevant subsets
-    - Configure proper aggregations and groupings
-
-    ## 3. Dashboard Assembly
-    - Combine related charts into coherent dashboards
-    - Use filters and parameters for interactivity
-    - Add markdown components for context and explanations
-
-    Would you like guidance on any specific step?
-    """
-```
-
-### Advanced Prompt Examples
-
-#### Domain-Specific Context
-
-```python
-@prompt(
-    "sales_extension.sales_analysis_guide",
-    title="Sales Analysis Guide",
-    description="Specialized guidance for sales data analysis workflows"
-)
-async def sales_analysis_guide(ctx: Context) -> str:
-    """Provides sales-specific analysis guidance and best practices."""
-    return """
-    # Sales Data Analysis Best Practices
-
-    ## Key Metrics to Track
-    - **Revenue Growth**: Month-over-month and year-over-year trends
-    - **Conversion Rates**: Lead-to-opportunity-to-close ratios
-    - **Customer Lifetime Value**: Total value per customer segment
-    - **Sales Cycle Length**: Time from lead to close by product/region
-
-    ## Recommended Chart Types
-    - **Time Series**: Revenue trends, seasonal patterns
-    - **Funnel Charts**: Conversion analysis across sales stages
-    - **Geographic Maps**: Regional performance comparison
-    - **Cohort Analysis**: Customer retention and growth patterns
-
-    ## Common Pitfalls to Avoid
-    - Don't mix different time granularities without proper context
-    - Always normalize for business days when comparing periods
-    - Consider external factors (holidays, market events) in analysis
-    - Segment by relevant dimensions (product, region, channel)
-
-    ## Next Steps
-    1. Identify your primary sales KPIs
-    2. Create baseline trend charts for each metric
-    3. Build comparative views across segments
-    4. Set up automated alerts for significant changes
-    """
-```
-
-#### Interactive Troubleshooting
-
-```python
-@prompt("support_extension.troubleshoot_charts")
-async def troubleshoot_charts(ctx: Context) -> str:
-    """Interactive troubleshooting assistant for chart issues."""
-    return """
-    # Chart Troubleshooting Assistant
-
-    Let's diagnose your chart issue step by step:
-
-    ## Common Issues and Solutions
-
-    ### 🚫 No Data Showing
-    **Possible causes:**
-    - Filters are too restrictive
-    - Date range doesn't match your data
-    - Database connection issues
-    - Missing permissions
-
-    **Check:** Try removing all filters and expanding the date range first.
-
-    ### 📊 Unexpected Aggregation Results
-    **Possible causes:**
-    - Incorrect grouping dimensions
-    - Wrong aggregation function (SUM vs COUNT vs AVG)
-    - Data quality issues (duplicates, nulls)
-    - Time zone mismatches
-
-    **Check:** Verify your GROUP BY columns and aggregation logic.
-
-    ### 🐌 Slow Performance
-    **Possible causes:**
-    - Large dataset without proper indexing
-    - Complex joins or calculations
-    - Missing query optimizations
-    - Resource constraints
-
-    **Check:** Simplify the query and add appropriate filters first.
-
-    ## Debug Steps
-    1. **Start Simple**: Create a basic count query first
-    2. **Add Gradually**: Introduce complexity step by step
-    3. **Check SQL**: Review the generated SQL for issues
-    4. **Test Data**: Verify with a small sample first
-
-    What specific issue are you experiencing?
-    """
-```
-
-### Prompt Best Practices
-
-#### Content Structure
-- **Use clear headings** and sections for easy navigation
-- **Provide actionable steps** rather than just theory
-- **Include examples** relevant to the user's domain
-- **Offer next steps** to continue the workflow
-
-#### Interactive Design
-- **Ask questions** to engage the user
-- **Provide options** for different scenarios
-- **Reference specific Superset features** by name
-- **Link to related tools** when appropriate
-
-#### Context Awareness
-```python
-@prompt("analytics_extension.context_aware_guide")
-async def context_aware_guide(ctx: Context) -> str:
-    """Provides guidance based on current user context."""
-    # Access user information if available
-    user_info = getattr(ctx, 'user', None)
-
-    guidance = """# Personalized Analytics Guide\n\n"""
-
-    if user_info:
-        guidance += f"Welcome back! Here's guidance tailored for your role:\n\n"
-
-    guidance += """
-    ## Getting Started
-    Based on your previous activity, here are recommended next steps:
-
-    1. **Review Recent Dashboards**: Check your most-used dashboards for updates
-    2. **Explore New Data**: Look for recently added datasets in your domain
-    3. **Share Insights**: Consider sharing successful analyses with your team
-
-    ## Advanced Techniques
-    - Set up automated alerts for key metrics
-    - Create parameterized dashboards for different audiences
-    - Use SQL Lab for complex custom analyses
-    """
-
-    return guidance
-```
-
-## Combining Tools and Prompts
-
-Extensions can provide both tools and prompts that work together:
-
-```python
-# Tool for data processing
-@tool("analytics_extension.calculate_metrics")
-def calculate_metrics(data: dict) -> dict:
-    """Calculate advanced analytics metrics."""
-    # Implementation here
-    pass
-
-# Prompt that guides users to the tool
-@prompt("analytics_extension.metrics_guide")
-async def metrics_guide(ctx: Context) -> str:
-    """Guide users through advanced metrics calculation."""
-    return """
-    # Advanced Metrics Calculation
-
-    Use the `calculate_metrics` tool to compute specialized analytics:
-
-    ## Available Metrics
-    - Customer Lifetime Value (CLV)
-    - Cohort Retention Rates
-    - Statistical Significance Tests
-    - Predictive Trend Analysis
-
-    ## Usage
-    Call the tool with your dataset to get detailed calculations
-    and recommendations for visualization approaches.
-
-    Would you like to calculate metrics for your current dataset?
-    """
-```
-
-## Next Steps
-
-- **[Development](./development)** - Project structure, APIs, and dev workflow
-- **[Security](./security)** - Security best practices for extensions

docs/developer_portal/extensions/overview.md

@@ -24,30 +24,53 @@ under the License.
 
 # Overview
 
-Apache Superset's extension system enables organizations to build custom features without modifying the core codebase. Inspired by the [VS Code extension model](https://code.visualstudio.com/api), this architecture addresses a long-standing challenge: teams previously had to fork Superset or make invasive modifications to add capabilities like query optimizers, custom panels, or specialized integrations—resulting in maintenance overhead and codebase fragmentation.
-
-The extension system introduces a modular, plugin-based architecture where both built-in features and external extensions use the same well-defined APIs. This "lean core" approach ensures that any capability available to Superset's internal features is equally accessible to community-developed extensions, fostering a vibrant ecosystem while reducing the maintenance burden on core contributors.
+Apache Superset's extension system allows developers to enhance and customize Superset's functionality through a modular, plugin-based architecture. Extensions can add new visualization types, custom UI components, data processing capabilities, and integration points.
 
 ## What are Superset Extensions?
 
-Superset extensions are self-contained `.supx` packages that extend the platform's capabilities through standardized contribution points. Each extension can include both frontend (React/TypeScript) and backend (Python) components, bundled together and loaded dynamically at runtime using Webpack Module Federation.
+Superset extensions are self-contained packages that extend the core platform's capabilities. They follow a standardized architecture that ensures compatibility, security, and maintainability while providing powerful customization options.
+
+## Extension Architecture
+
+- **[Architecture](./architecture)** - Architectural principles and high-level system overview
+- **[Extension Project Structure](./extension-project-structure)** - Standard project layout and organization
+- **[Extension Metadata](./extension-metadata)** - Configuration and manifest structure
+
+## Development Guide
+
+- **[Frontend Contribution Types](./frontend-contribution-types)** - Types of UI contributions available
+- **[Interacting with Host](./interacting-with-host)** - Communication patterns with Superset core
+- **[Development Mode](./development-mode)** - Tools and workflows for extension development
+
+For information about runtime loading and dependency management, see the [Dynamic Module Loading](./architecture#dynamic-module-loading) section in the Architecture page.
+
+## Deployment & Management
+
+- **[Deploying Extension](./deploying-extension)** - Packaging and distribution strategies
+- **[Security Implications](./security-implications)** - Security considerations and best practices
+
+## Hands-on Examples
+
+- **[Quick Start](./quick-start)** - Complete Hello World extension walkthrough
 
 ## Extension Capabilities
 
 Extensions can provide:
 
-- **Custom UI Components**: New panels, views, and interactive elements
-- **Commands and Menus**: Custom actions accessible via menus and keyboard shortcuts
-- **REST API Endpoints**: Backend services under the `/api/v1/extensions/` namespace
-- **MCP Tools and Prompts**: AI agent capabilities for enhanced user assistance
+- **Custom Visualizations**: New chart types and data visualization components
+- **UI Enhancements**: Custom dashboards, panels, and interactive elements  
+- **Data Connectors**: Integration with external data sources and APIs
+- **Workflow Automation**: Custom actions and batch processing capabilities
+- **Authentication Providers**: SSO and custom authentication mechanisms
+- **Theme Customization**: Custom styling and branding options
 
-## Next Steps
+## Getting Started
 
-- **[Quick Start](./quick-start)** - Build your first extension with a complete walkthrough
-- **[Architecture](./architecture)** - Design principles and system overview
-- **[Contribution Types](./contribution-types)** - Available extension points
-- **[Development](./development)** - Project structure, APIs, and development workflow
-- **[Deployment](./deployment)** - Packaging and deploying extensions
-- **[MCP Integration](./mcp)** - Adding AI agent capabilities using extensions
-- **[Security](./security)** - Security considerations and best practices
-- **[Community Extensions](./registry)** - Browse extensions shared by the community
+1. **Learn the Architecture**: Start with [Architecture](./architecture) to understand the design philosophy
+2. **Set up Development**: Follow the [Development Mode](./development-mode) guide to configure your environment
+3. **Build Your First Extension**: Complete the [Quick Start](./quick-start) tutorial
+4. **Deploy and Share**: Use the [Deploying Extension](./deploying-extension) guide to package your extension
+
+## Extension Ecosystem
+
+The extension system is designed to foster a vibrant ecosystem of community-contributed functionality. By following the established patterns and guidelines, developers can create extensions that seamlessly integrate with Superset while maintaining the platform's reliability and performance standards.

docs/developer_portal/extensions/quick-start.md

@@ -128,7 +128,7 @@ The CLI generated a basic `backend/src/hello_world/entrypoint.py`. We'll create
 ```python
 from flask import Response
 from flask_appbuilder.api import expose, protect, safe
-from superset_core.api.rest_api import RestApi
+from superset_core.api.types.rest_api import RestApi
 
 
 class HelloWorldAPI(RestApi):
@@ -191,125 +191,7 @@ This registers your API with Superset when the extension loads.
 
 ## Step 5: Create Frontend Component
 
-The CLI generates the frontend configuration files. Below are the key configurations that enable Module Federation integration with Superset.
-
-**`frontend/package.json`**
-
-The `@apache-superset/core` package must be listed in both `peerDependencies` (to declare runtime compatibility) and `devDependencies` (to provide TypeScript types during build):
-
-```json
-{
-  "name": "hello_world",
-  "version": "0.1.0",
-  "private": true,
-  "license": "Apache-2.0",
-  "scripts": {
-    "start": "webpack serve --mode development",
-    "build": "webpack --stats-error-details --mode production"
-  },
-  "peerDependencies": {
-    "@apache-superset/core": "^x.x.x",
-    "react": "^x.x.x",
-    "react-dom": "^x.x.x"
-  },
-  "devDependencies": {
-    "@apache-superset/core": "^x.x.x",
-    "@types/react": "^x.x.x",
-    "ts-loader": "^x.x.x",
-    "typescript": "^x.x.x",
-    "webpack": "^5.x.x",
-    "webpack-cli": "^x.x.x",
-    "webpack-dev-server": "^x.x.x"
-  }
-}
-```
-
-**`frontend/webpack.config.js`**
-
-The webpack configuration requires specific settings for Module Federation. Key settings include `externalsType: "window"` and `externals` to map `@apache-superset/core` to `window.superset` at runtime, `import: false` for shared modules to use the host's React instead of bundling a separate copy, and `remoteEntry.[contenthash].js` for cache busting:
-
-```javascript
-const path = require("path");
-const { ModuleFederationPlugin } = require("webpack").container;
-const packageConfig = require("./package.json");
-
-module.exports = (env, argv) => {
-  const isProd = argv.mode === "production";
-
-  return {
-    entry: isProd ? {} : "./src/index.tsx",
-    mode: isProd ? "production" : "development",
-    devServer: {
-      port: 3001,
-      headers: {
-        "Access-Control-Allow-Origin": "*",
-      },
-    },
-    output: {
-      filename: isProd ? undefined : "[name].[contenthash].js",
-      chunkFilename: "[name].[contenthash].js",
-      clean: true,
-      path: path.resolve(__dirname, "dist"),
-      publicPath: `/api/v1/extensions/${packageConfig.name}/`,
-    },
-    resolve: {
-      extensions: [".ts", ".tsx", ".js", ".jsx"],
-    },
-    // Map @apache-superset/core imports to window.superset at runtime
-    externalsType: "window",
-    externals: {
-      "@apache-superset/core": "superset",
-    },
-    module: {
-      rules: [
-        {
-          test: /\.tsx?$/,
-          use: "ts-loader",
-          exclude: /node_modules/,
-        },
-      ],
-    },
-    plugins: [
-      new ModuleFederationPlugin({
-        name: packageConfig.name,
-        filename: "remoteEntry.[contenthash].js",
-        exposes: {
-          "./index": "./src/index.tsx",
-        },
-        shared: {
-          react: {
-            singleton: true,
-            requiredVersion: packageConfig.peerDependencies.react,
-            import: false, // Use host's React, don't bundle
-          },
-          "react-dom": {
-            singleton: true,
-            requiredVersion: packageConfig.peerDependencies["react-dom"],
-            import: false,
-          },
-        },
-      }),
-    ],
-  };
-};
-```
-
-**`frontend/tsconfig.json`**
-
-```json
-{
-  "compilerOptions": {
-    "baseUrl": ".",
-    "moduleResolution": "node",
-    "jsx": "react",
-    "strict": true,
-    "esModuleInterop": true,
-    "skipLibCheck": true,
-    "forceConsistentCasingInFileNames": true
-  },
-  "include": ["src"]
-}
-```
+The CLI generated boilerplate files. The webpack config and package.json are already properly configured with Module Federation.
 
 **Create `frontend/src/HelloWorldPanel.tsx`**
 
@@ -455,7 +337,7 @@ Add the following to your `superset_config.py`:
 ```python
 # Enable extensions feature
 FEATURE_FLAGS = {
-    "ENABLE_EXTENSIONS": True,
+    "EXTENSIONS": True,
 }
 
 # Set the directory where extensions are stored
@@ -506,9 +388,10 @@ Here's what happens when your extension loads:
 
 Now that you have a working extension, explore:
 
-- **[Development](./development)** - Project structure, APIs, and development workflow
-- **[Contribution Types](./contribution-types)** - Other contribution points beyond panels
-- **[Deployment](./deployment)** - Packaging and deploying your extension
-- **[Security](./security)** - Security best practices for extensions
+- **[Development Mode](./development-mode)** - Faster iteration with local development and watch mode
+- **[Extension Project Structure](./extension-project-structure)** - Best practices for organizing larger extensions
+- **[Frontend Contribution Types](./frontend-contribution-types)** - Other UI contribution points beyond panels
+- **[Interacting with Host](./interacting-with-host)** - Advanced APIs for interacting with Superset
+- **[Security Implications](./security-implications)** - Security best practices for extensions
 
 For a complete real-world example, examine the query insights extension in the Superset codebase.

docs/developer_portal/extensions/registry.md

@@ -1,47 +0,0 @@
----
-title: Community Extensions
-sidebar_position: 9
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Community Extensions
-
-This page serves as a registry of community-created Superset extensions. These extensions are developed and maintained by community members and are not officially supported or vetted by the Apache Superset project. **Before installing any community extension, administrators are responsible for evaluating the extension's source code for security vulnerabilities, performance impact, UI/UX quality, and compatibility with their Superset deployment.**
-
-## Extensions
-
-| Name                                                                                                      | Description                                                                                                                                                                                                                                         | Author            | Preview                                                                                                                                                 |
-| --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [Extensions API Explorer](https://github.com/michael-s-molina/superset-extensions/tree/main/api_explorer) | A SQL Lab panel that demonstrates the Extensions API by providing an interactive explorer for testing commands like getTabs, getCurrentTab, and getDatabases. Useful for extension developers to understand and experiment with the available APIs. | Michael S. Molina | <a href="/img/extensions/api_explorer.png" target="_blank"><img src="/img/extensions/api_explorer.png" alt="Extensions API Explorer" width="120" /></a> |
-| [SQL Query Flow Visualizer](https://github.com/msyavuz/superset-sql-visualizer) | A SQL Lab panel that transforms SQL queries into interactive flow diagrams, helping developers and analysts understand query execution paths and data relationships.| Mehmet Salih Yavuz | <a href="/img/extensions/sql_flow_visualizer.png" target="_blank"><img src="/img/extensions/sql_flow_visualizer.png" alt="SQL Flow Visualizer" width="120" /></a> |
-## How to Add Your Extension
-
-To add your extension to this registry, submit a pull request to the [Apache Superset repository](https://github.com/apache/superset) with the following changes:
-
-1. Add a row to the **Extensions** table above using this format:
-
-```markdown
-| [Your Extension](https://github.com/your-username/your-repo) | A brief description of your extension. | Your Name | <a href="/img/extensions/your-screenshot.png" target="_blank"><img src="/img/extensions/your-screenshot.png" alt="Your Extension" width="120" /></a> |
-```
-
-2. Add a screenshot to `docs/static/img/extensions/` (recommended size: 800x450px, PNG or JPG format)
-
-3. Submit your PR with a title like "docs: Add [Extension Name] to community extensions registry"

docs/developer_portal/extensions/security-implications.md

@@ -1,6 +1,6 @@
 ---
-title: Security
-sidebar_position: 8
+title: Security Implications and Responsibilities
+sidebar_position: 12
 ---
 
 <!--
@@ -22,14 +22,12 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-# Security
+# Security Implications and Responsibilities
 
 By default, extensions are disabled and must be explicitly enabled by setting the `ENABLE_EXTENSIONS` feature flag. Built-in extensions are included as part of the Superset codebase and are held to the same security standards and review processes as the rest of the application.
 
 For external extensions, administrators are responsible for evaluating and verifying the security of any extensions they choose to install, just as they would when installing third-party NPM or PyPI packages. At this stage, all extensions run in the same context as the host application, without additional sandboxing. This means that external extensions can impact the security and performance of a Superset environment in the same way as any other installed dependency.
 
-We plan to introduce an optional sandboxed execution model for extensions in the future (as part of an additional SIP). Until then, administrators should exercise caution and follow best practices when selecting and deploying third-party extensions. A directory of community extensions is available in the [Community Extensions](./registry) page. Note that these extensions are not vetted by the Apache Superset project—administrators must evaluate each extension before installation.
+We plan to introduce an optional sandboxed execution model for extensions in the future (as part of an additional SIP). Until then, administrators should exercise caution and follow best practices when selecting and deploying third-party extensions. A directory of known Superset extensions may be maintained in a means similar to [this page](https://github.com/apache/superset/wiki/Superset-Third%E2%80%90Party-Plugins-Directory) on the wiki. We also discussed the possibility of introducing a shared registry for vetted extensions but decided to leave it out of the initial scope of the project. We might introduce a registry at a later stage depending on the evolution of extensions created by the community.
 
-**Any performance or security vulnerabilities introduced by external extensions should be reported directly to the extension author, not as Superset vulnerabilities.**
-
-Any security concerns regarding built-in extensions (included in Superset's monorepo) should be reported to the Superset Security mailing list for triage and resolution by maintainers.
+Any performance or security vulnerabilities introduced by external extensions should be reported directly to the extension author, not as Superset vulnerabilities. Any security concerns regarding built-in extensions (included in Superset's monorepo) should be reported to the Superset Security mailing list for triage and resolution by maintainers.

docs/developer_portal/guidelines/backend-style-guidelines.md

@@ -1,6 +1,6 @@
 ---
-title: Overview
-sidebar_position: 1
+title: Backend Style Guidelines
+sidebar_position: 3
 ---
 
 <!--
@@ -26,22 +26,22 @@ under the License.
 
 This is a list of statements that describe how we do backend development in Superset. While they might not be 100% true for all files in the repo, they represent the gold standard we strive towards for backend quality and style.
 
-- We use a monolithic Python/Flask/Flask-AppBuilder backend, with small single-responsibility satellite services where necessary.
-- Files are generally organized by feature or object type. Within each domain, we can have api controllers, models, schemas, commands, and data access objects (DAO).
-  - See: [Proposal for Improving Superset's Python Code Organization](https://github.com/apache/superset/issues/9077)
-- API controllers use Marshmallow Schemas to serialize/deserialize data.
-- Authentication and authorization are controlled by the [security manager](https://github.com/apache/superset/blob/master/superset/security/manager).
-- We use Pytest for unit and integration tests. These live in the `tests` directory.
-- We add tests for every new piece of functionality added to the backend.
-- We use pytest fixtures to share setup between tests.
-- We use SQLAlchemy to access both Superset's application database, and users' analytics databases.
-- We make changes backwards compatible whenever possible.
-  - If a change cannot be made backwards compatible, it goes into a major release.
-  - See: [Proposal For Semantic Versioning](https://github.com/apache/superset/issues/12566)
-- We use Swagger for API documentation, with docs written inline on the API endpoint code.
-- We prefer thin ORM models, putting shared functionality in other utilities.
-- Several linters/checkers are used to maintain consistent code style and type safety: pylint, mypy, black, isort.
-- `__init__.py` files are kept empty to avoid implicit dependencies.
+* We use a monolithic Python/Flask/Flask-AppBuilder backend, with small single-responsibility satellite services where necessary.
+* Files are generally organized by feature or object type. Within each domain, we can have api controllers, models, schemas, commands, and data access objects (dao).
+    * See: [Proposal for Improving Superset's Python Code Organization](https://github.com/apache/superset/issues/9077)
+* API controllers use Marshmallow Schemas to serialize/deserialize data.
+* Authentication and authorization are controlled by the [security manager](https://github.com/apache/superset/blob/master/superset/security/manager).
+* We use Pytest for unit and integration tests. These live in the `tests` directory.
+* We add tests for every new piece of functionality added to the backend.
+* We use pytest fixtures to share setup between tests.
+* We use sqlalchemy to access both Superset's application database, and users' analytics databases.
+* We make changes backwards compatible whenever possible.
+    * If a change cannot be made backwards compatible, it goes into a major release.
+    * See: [Proposal For Semantic Versioning](https://github.com/apache/superset/issues/12566)
+* We use Swagger for API documentation, with docs written inline on the API endpoint code.
+* We prefer thin ORM models, putting shared functionality in other utilities.
+* Several linters/checkers are used to maintain consistent code style and type safety: pylint, pypy, black, isort.
+* `__init__.py` files are kept empty to avoid implicit dependencies.
 
 ## Code Organization
 

docs/developer_portal/guidelines/backend/dao-style-guidelines.md

@@ -1,6 +1,6 @@
 ---
 title: DAO Style Guidelines and Best Practices
-sidebar_position: 2
+sidebar_position: 1
 ---
 
 <!--
@@ -26,29 +26,19 @@ under the License.
 
 A Data Access Object (DAO) is a pattern that provides an abstract interface to the SQLAlchemy Object Relational Mapper (ORM). The DAOs are critical as they form the building block of the application which are wrapped by the associated commands and RESTful API endpoints.
 
-There are numerous inconsistencies and violations of the DRY principal within the codebase as it relates to DAOs and ORMs—unnecessary commits, non-ACID transactions, etc.—which makes the code unnecessarily complex and convoluted. Addressing the underlying issues with the DAOs _should_ help simplify the downstream operations and improve the developer experience.
+Currently there are numerous inconsistencies and violation of the DRY principal within the codebase as it relates to DAOs and ORMs—unnecessary commits, non-ACID transactions, etc.—which makes the code unnecessarily complex and convoluted. Addressing the underlying issues with the DAOs _should_ help simplify the downstream operations and improve the developer experience.
 
 To ensure consistency the following rules should be adhered to:
 
-## Core Rules
+1. All database operations (including testing) should be defined within a DAO, i.e., there should not be any explicit `db.session.add`, `db.session.merge`, etc. calls outside of a DAO.
 
-1. **All database operations (including testing) should be defined within a DAO**, i.e., there should not be any explicit `db.session.add`, `db.session.merge`, etc. calls outside of a DAO.
+2. A DAO should use `create`, `update`, `delete`, `upsert` terms—typical database operations which ensure consistency with commands—rather than action based terms like `save`, `saveas`, `override`, etc.
 
-2. **A DAO should use `create`, `update`, `delete`, `upsert` terms**—typical database operations which ensure consistency with commands—rather than action based terms like `save`, `saveas`, `override`, etc.
+3. Sessions should be managed via a [context manager](https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#begin-once) which auto-commits on success and rolls back on failure, i.e., there should be no explicit `db.session.commit` or `db.session.rollback` calls within the DAO.
 
-3. **Sessions should be managed via a [context manager](https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#begin-once)** which auto-commits on success and rolls back on failure, i.e., there should be no explicit `db.session.commit` or `db.session.rollback` calls within the DAO.
+4. There should be a single atomic transaction representing the entirety of the operation, i.e., when creating a dataset with associated columns and metrics either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back. SQLAlchemy supports [nested transactions](https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#nested-transaction) via the `begin_nested` method which can be nested—inline with how DAOs are invoked.
 
-4. **There should be a single atomic transaction representing the entirety of the operation**, i.e., when creating a dataset with associated columns and metrics either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back. SQLAlchemy supports [nested transactions](https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#nested-transaction) via the `begin_nested` method which can be nested—inline with how DAOs are invoked.
-
-5. **The database layer should adopt a "shift left" mentality** i.e., uniqueness/foreign key constraints, relationships, cascades, etc. should all be defined in the database layer rather than being enforced in the application layer.
-
-6. **Exception-based validation**: Ask for forgiveness rather than permission. Try to perform the operation and rely on database constraints to verify that the model is acceptable, rather than pre-validating conditions.
-
-7. **Bulk operations**: Provide bulk `create`, `update`, and `delete` methods where applicable for performance optimization.
-
-8. **Sparse updates**: Updates should only modify explicitly defined attributes.
-
-9. **Test transactions**: Tests should leverage nested transactions which should be rolled back on teardown, rather than deleting objects.
+5. The database layer should adopt a "shift left" mentality i.e., uniqueness/foreign key constraints, relationships, cascades, etc. should all be defined in the database layer rather than being enforced in the application layer.
 
 ## DAO Implementation Examples
 

docs/developer_portal/guidelines/design-guidelines.md

@@ -30,23 +30,21 @@ This is an area to host resources and documentation supporting the evolution and
 
 ### Sentence case
 
-Use sentence-case capitalization for everything in the UI (except these exceptions below).
+Use sentence-case capitalization for everything in the UI (except these **).
 
 Sentence case is predominantly lowercase. Capitalize only the initial character of the first word, and other words that require capitalization, like:
 
-- **Proper nouns.** Objects in the product _are not_ considered proper nouns e.g. dashboards, charts, saved queries etc. Proprietary feature names eg. SQL Lab, Preset Manager _are_ considered proper nouns
-- **Acronyms** (e.g. CSS, HTML)
-- When referring to **UI labels that are themselves capitalized** from sentence case (e.g. page titles - Dashboards page, Charts page, Saved queries page, etc.)
-- User input that is reflected in the UI. E.g. a user-named a dashboard tab
+* **Proper nouns.** Objects in the product _are not_ considered proper nouns e.g. dashboards, charts, saved queries etc. Proprietary feature names eg. SQL Lab, Preset Manager _are_ considered proper nouns
+* **Acronyms** (e.g. CSS, HTML)
+* When referring to **UI labels that are themselves capitalized** from sentence case (e.g. page titles - Dashboards page, Charts page, Saved queries page, etc.)
+* User input that is reflected in the UI. E.g. a user-named a dashboard tab
 
-**Sentence case vs. Title case:**
-- Title case: "A Dog Takes a Walk in Paris"
-- Sentence case: "A dog takes a walk in Paris"
+**Sentence case vs. Title case:** Title case: "A Dog Takes a Walk in Paris" Sentence case: "A dog takes a walk in Paris"
 
 **Why sentence case?**
 
-- It's generally accepted as the quickest to read
-- It's the easiest form to distinguish between common and proper nouns
+* It's generally accepted as the quickest to read
+* It's the easiest form to distinguish between common and proper nouns
 
 ### How to refer to UI elements
 
@@ -54,38 +52,21 @@ When writing about a UI element, use the same capitalization as used in the UI.
 
 For example, if an input field is labeled "Name" then you refer to this as the "Name input field". Similarly, if a button has the label "Save" in it, then it is correct to refer to the "Save button".
 
-Where a product page is titled "Settings", you refer to this in writing as follows:
-"Edit your personal information on the Settings page".
+Where a product page is titled "Settings", you refer to this in writing as follows: "Edit your personal information on the Settings page".
 
 Often a product page will have the same title as the objects it contains. In this case, refer to the page as it appears in the UI, and the objects as common nouns:
 
-- Upload a dashboard on the Dashboards page
-- Go to Dashboards
-- View dashboard
-- View all dashboards
-- Upload CSS templates on the CSS templates page
-- Queries that you save will appear on the Saved queries page
-- Create custom queries in SQL Lab then create dashboards
+* Upload a dashboard on the Dashboards page
+* Go to Dashboards
+* View dashboard
+* View all dashboards
+* Upload CSS templates on the CSS templates page
+* Queries that you save will appear on the Saved queries page
+* Create custom queries in SQL Lab then create dashboards
 
-### Exceptions to sentence case
+### **Exceptions to sentence case:**
 
-1. **Acronyms and abbreviations.**
-   Examples: URL, CSV, XML, CSS, SQL, SSH, URI, NaN, CRON, CC, BCC
-
-2. **Proper nouns and brand names.**
-   Examples: Apache, Superset, AntD JavaScript, GeoJSON, Slack, Google Sheets, SQLAlchemy
-
-3. **Technical terms derived from proper nouns.**
-   Examples: Jinja, Gaussian, European (as in European time zone)
-
-4. **Key names.** Capitalize button labels and UI elements as they appear in the product UI.
-   Examples: Shift (as in the keyboard button), Enter key
-
-5. **Named queries or specific labeled items.**
-   Examples: Query A, Query B
-
-6. **Database names.** Always capitalize names of database engines and connectors.
-   Examples: Presto, Trino, Drill, Hive, Google Sheets
+1. Acronyms and abbreviations. Examples: URL, CSV, XML
 
 ## Button Design Guidelines
 
@@ -117,32 +98,6 @@ Primary buttons have a fourth style: dropdown.
 | Tertiary | For less prominent actions; can be used in isolation or paired with a primary button |
 | Destructive | For actions that could have destructive effects on the user's data |
 
-### Format
-
-#### Anatomy
-
-Button text is centered using the Label style. Icons appear left of text when combined. If no text label exists, an icon must indicate the button's function.
-
-#### Button size
-
-- Default dimensions: 160px width × 32px height
-- Text: 11px, Inter Medium, all caps
-- Corners: 4px border radius
-- Minimum padding: 8px around text
-- Width can decrease if space is limited, but maintain minimum padding
-
-#### Button groups
-
-- Group related buttons to establish visual hierarchy
-- Avoid overwhelming users with too many actions
-- Limit calls to action; use tertiary/ghost buttons for layouts with 3+ actions
-- Maintain consistent styles within groups when possible
-- Space buttons 8px apart vertically or horizontally
-
-#### Content guidelines
-
-Button labels should be clear and predictable. Use the "\{verb\} + \{noun\}" format, except for common actions like "Done," "Close," "Cancel," "Add," or "Delete." This formula provides necessary context and aids translation, though compact UIs or localization needs may warrant exceptions.
-
 ## Error Message Design Guidelines
 
 ### Definition
@@ -173,10 +128,10 @@ In all cases, encountering errors increases user friction and frustration while
 
 Select one pattern per error (e.g. do not implement an inline and banner pattern for the same error).
 
-| When the error... | Use... |
-|------------------|--------|
-| Is directly related to a UI control | Inline error |
-| Is not directly related to a UI control | Banner error |
+When the error... | Use...
+---------------- | ------
+Is directly related to a UI control | Inline error
+Is not directly related to a UI control | Banner error
 
 #### Inline
 
@@ -191,45 +146,3 @@ Use the `LabeledErrorBoundInput` component for this error pattern.
 ##### Implementation details
 
 - Where and when relevant, scroll the screen to the UI control with the error
-- When multiple inline errors are present, scroll to the topmost error
-
-#### Banner
-
-Banner errors are used when the source of the error is not directly related to a UI control (text input, selector, etc.) such as a technical failure or a loading problem.
-
-##### Anatomy
-
-Use the `ErrorAlert` component for this error pattern.
-
-1. **Headline** (optional): 1-2 word summary of the error
-2. **Message**: What went wrong and what users should do next
-3. **Expand option** (optional): "See more"/"See less"
-4. **Details** (optional): Additional helpful context
-5. **Modal** (optional): For spatial constraints using `ToastType.DANGER`
-
-##### Implementation details
-
-- Place the banner near the content area most relevant to the error
-- For chart errors in Explore, use the chart area
-- For modal errors, use the modal footer
-- For app-wide errors, use the top of the screen
-
-### Content guidelines
-
-Effective error messages communicate:
-
-1. What went wrong
-2. What users should do next
-
-Error messages should be:
-
-- Clear and accurate, leaving no room for misinterpretation
-- Short and concise
-- Understandable to non-technical users
-- Non-blaming and avoiding negative language
-
-**Example:**
-
-❌ "Cannot delete a datasource that has slices attached to it."
-
-✅ "Please delete all charts using this dataset before deleting the dataset."

docs/developer_portal/guidelines/frontend-style-guidelines.md

@@ -1,6 +1,6 @@
 ---
-title: Overview
-sidebar_position: 1
+title: Frontend Style Guidelines
+sidebar_position: 2
 ---
 
 <!--
@@ -26,25 +26,19 @@ under the License.
 
 This is a list of statements that describe how we do frontend development in Superset. While they might not be 100% true for all files in the repo, they represent the gold standard we strive towards for frontend quality and style.
 
-- We develop using TypeScript.
-  - See: [SIP-36](https://github.com/apache/superset/issues/9101)
-- We use React for building components, and Redux to manage app/global state.
-  - See: [Component Style Guidelines and Best Practices](./frontend/component-style-guidelines)
-- We prefer functional components to class components and use hooks for local component state.
-- We use [Ant Design](https://ant.design/) components from our component library whenever possible, only building our own custom components when it's required.
-  - See: [SIP-48](https://github.com/apache/superset/issues/11283)
-- We use [@emotion](https://emotion.sh/docs/introduction) to provide styling for our components, co-locating styling within component files.
-  - See: [SIP-37](https://github.com/apache/superset/issues/9145)
-  - See: [Emotion Styling Guidelines and Best Practices](./frontend/emotion-styling-guidelines)
-- We use Jest for unit tests, React Testing Library for component tests, and Cypress for end-to-end tests.
-  - See: [SIP-56](https://github.com/apache/superset/issues/11830)
-  - See: [Testing Guidelines and Best Practices](../testing/testing-guidelines)
-- We add tests for every new component or file added to the frontend.
-- We organize our repo so similar files live near each other, and tests are co-located with the files they test.
-  - See: [SIP-61](https://github.com/apache/superset/issues/12098)
-- We prefer small, easily testable files and components.
-- We use ESLint and Prettier to automatically fix lint errors and format the code.
-  - We do not debate code formatting style in PRs, instead relying on automated tooling to enforce it.
-  - If there's not a linting rule, we don't have a rule!
-- We use [React Storybook](https://storybook.js.org/) and [Applitools](https://applitools.com/) to help preview/test and stabilize our components
-  - A public Storybook with components from the `master` branch is available [here](https://apache-superset.github.io/superset-ui/?path=/story/*)
+*   We develop using TypeScript.
+*   We use React for building components, and Redux to manage app/global state.
+    *   See: [Component Style Guidelines and Best Practices](./frontend/component-style-guidelines)
+*   We prefer functional components to class components and use hooks for local component state.
+*   We use [Ant Design](https://ant.design/) components from our component library whenever possible, only building our own custom components when it's required.
+*   We use [@emotion](https://emotion.sh/docs/introduction) to provide styling for our components, co-locating styling within component files.
+    *   See: [Emotion Styling Guidelines and Best Practices](./frontend/emotion-styling-guidelines)
+*   We use Jest for unit tests, React Testing Library for component tests, and Cypress for end-to-end tests.
+    *   See: [Testing Guidelines and Best Practices](./frontend/testing-guidelines)
+*   We add tests for every new component or file added to the frontend.
+*   We organize our repo so similar files live near each other, and tests are co-located with the files they test.
+*   We prefer small, easily testable files and components.
+*   We use ESLint and Prettier to automatically fix lint errors and format the code.
+    *   We do not debate code formatting style in PRs, instead relying on automated tooling to enforce it.
+    *   If there's not a linting rule, we don't have a rule!
+*   We use [React Storybook](https://storybook.js.org/) and [Applitools](https://applitools.com/) to help preview/test and stabilize our components

docs/developer_portal/guidelines/frontend/component-style-guidelines.md

@@ -1,6 +1,6 @@
 ---
 title: Component Style Guidelines and Best Practices
-sidebar_position: 2
+sidebar_position: 1
 ---
 
 <!--
@@ -35,7 +35,7 @@ This guide is intended primarily for reusable components. Whenever possible, all
 - All components should be made to be reusable whenever possible
 - All components should follow the structure and best practices as detailed below
 
-### Directory and component structure
+## Directory and component structure
 
 ```
 superset-frontend/src/components
@@ -51,142 +51,208 @@ superset-frontend/src/components
 
 **Component directory name:** Use `PascalCase` for the component directory name
 
-**Storybook:** Components should come with a storybook file whenever applicable, with the following naming convention `\{ComponentName\}.stories.tsx`. More details about Storybook below
+**Storybook:** Components should come with a storybook file whenever applicable, with the following naming convention `{ComponentName}.stories.tsx`. More details about Storybook below
 
-**Unit and end-to-end tests:** All components should come with unit tests using Jest and React Testing Library. The file name should follow this naming convention `\{ComponentName\}.test.tsx`. Read the [Testing Guidelines and Best Practices](../../testing/testing-guidelines) for more details
+**Unit and end-to-end tests:** All components should come with unit tests using Jest and React Testing Library. The file name should follow this naming convention `{ComponentName}.test.tsx.` Read the [Testing Guidelines and Best Practices](./testing-guidelines) for more details about tests
 
-**Reference naming:** Use `PascalCase` for React components and `camelCase` for component instances
+## Component Development Best Practices
 
-**BAD:**
-```jsx
-import mainNav from './MainNav';
-```
+### Use TypeScript
 
-**GOOD:**
-```jsx
-import MainNav from './MainNav';
-```
-
-**BAD:**
-```jsx
-const NavItem = <MainNav />;
-```
-
-**GOOD:**
-```jsx
-const navItem = <MainNav />;
-```
-
-**Component naming:** Use the file name as the component name
-
-**BAD:**
-```jsx
-import MainNav from './MainNav/index';
-```
-
-**GOOD:**
-```jsx
-import MainNav from './MainNav';
-```
-
-**Props naming:** Do not use DOM related props for different purposes
-
-**BAD:**
-```jsx
-<MainNav style="big" />
-```
-
-**GOOD:**
-```jsx
-<MainNav variant="big" />
-```
-
-**Importing dependencies:** Only import what you need
-
-**BAD:**
-```jsx
-import * as React from "react";
-```
-
-**GOOD:**
-```jsx
-import React, { useState } from "react";
-```
-
-**Default VS named exports:** As recommended by [TypeScript](https://www.typescriptlang.org/docs/handbook/modules.html), "If a module's primary purpose is to house one specific export, then you should consider exporting it as a default export. This makes both importing and actually using the import a little easier". If you're exporting multiple objects, use named exports instead.
-
-_As a default export_
-```jsx
-import MainNav from './MainNav';
-```
-
-_As a named export_
-```jsx
-import { MainNav, SecondaryNav } from './Navbars';
-```
-
-**ARIA roles:** Always make sure you are writing accessible components by using the official [ARIA roles](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques)
-
-## Use TypeScript
-
-All components should be written in TypeScript and their extensions should be `.ts` or `.tsx`
-
-### type vs interface
-
-Validate all props with the correct types. This replaces the need for a run-time validation as provided by the prop-types library.
+All new components should be written in TypeScript. This helps catch errors early and provides better development experience with IDE support.
 
 ```tsx
-type HeadingProps = {
-  param: string;
+interface ComponentProps {
+  title: string;
+  isVisible?: boolean;
+  onClose?: () => void;
 }
 
-export default function Heading({ children }: HeadingProps) {
-  return <h2>{children}</h2>
+export const MyComponent: React.FC<ComponentProps> = ({
+  title,
+  isVisible = true,
+  onClose
+}) => {
+  // Component implementation
+};
+```
+
+### Prefer Functional Components
+
+Use functional components with hooks instead of class components:
+
+```tsx
+// ✅ Good - Functional component with hooks
+export const MyComponent: React.FC<Props> = ({ data }) => {
+  const [loading, setLoading] = useState(false);
+
+  useEffect(() => {
+    // Effect logic
+  }, []);
+
+  return <div>{/* Component JSX */}</div>;
+};
+
+// ❌ Avoid - Class component
+class MyComponent extends React.Component {
+  // Class implementation
 }
 ```
 
-Use `type` for your component props and state. Use `interface` when you want to enable _declaration merging_.
+### Follow Ant Design Patterns
 
-### Define default values for non-required props
-
-In order to improve the readability of your code and reduce assumptions, always add default values for non required props, when applicable, for example:
+Extend Ant Design components rather than building from scratch:
 
 ```tsx
-const applyDiscount = (price: number, discount = 0.05) => price * (1 - discount);
+import { Button } from 'antd';
+import styled from '@emotion/styled';
+
+const StyledButton = styled(Button)`
+  // Custom styling using emotion
+`;
 ```
 
-## Functional components and Hooks
+### Reusability and Props Design
 
-We prefer functional components and the usage of hooks over class components.
-
-### useState
-
-Always explicitly declare the type unless the type can easily be assumed by the declaration.
+Design components with reusability in mind:
 
 ```tsx
-const [customer, setCustomer] = useState<ICustomer | null>(null);
+interface ButtonProps {
+  variant?: 'primary' | 'secondary' | 'tertiary';
+  size?: 'small' | 'medium' | 'large';
+  loading?: boolean;
+  disabled?: boolean;
+  children: React.ReactNode;
+  onClick?: () => void;
+}
+
+export const CustomButton: React.FC<ButtonProps> = ({
+  variant = 'primary',
+  size = 'medium',
+  ...props
+}) => {
+  // Implementation
+};
 ```
 
-### useReducer
+## Testing Components
 
-Always prefer `useReducer` over `useState` when your state has complex logics.
+Every component should include comprehensive tests:
 
-### useMemo and useCallback
+```tsx
+// MyComponent.test.tsx
+import { render, screen, fireEvent } from '@testing-library/react';
+import { MyComponent } from './MyComponent';
 
-Always memoize when your components take functions or complex objects as props to avoid unnecessary rerenders.
+test('renders component with title', () => {
+  render(<MyComponent title="Test Title" />);
+  expect(screen.getByText('Test Title')).toBeInTheDocument();
+});
 
-### Custom hooks
+test('calls onClose when close button is clicked', () => {
+  const mockOnClose = jest.fn();
+  render(<MyComponent title="Test" onClose={mockOnClose} />);
 
-All custom hooks should be located in the directory `/src/hooks`. Before creating a new custom hook, make sure that is not available in the existing custom hooks.
+  fireEvent.click(screen.getByRole('button', { name: /close/i }));
+  expect(mockOnClose).toHaveBeenCalledTimes(1);
+});
+```
 
-## Storybook
+## Storybook Stories
 
-Each component should come with its dedicated storybook file.
+Create stories for visual testing and documentation:
 
-**One component per story:** Each storybook file should only contain one component unless substantially different variants are required
+```tsx
+// MyComponent.stories.tsx
+import type { Meta, StoryObj } from '@storybook/react';
+import { MyComponent } from './MyComponent';
 
-**Component variants:** If the component behavior is substantially different when certain props are used, it is best to separate the story into different types. See the `superset-frontend/src/components/Select/Select.stories.tsx` as an example.
+const meta: Meta<typeof MyComponent> = {
+  title: 'Components/MyComponent',
+  component: MyComponent,
+  parameters: {
+    layout: 'centered',
+  },
+  tags: ['autodocs'],
+};
 
-**Isolated state:** The storybook should show how the component works in an isolated state and with as few dependencies as possible
+export default meta;
+type Story = StoryObj<typeof meta>;
 
-**Use args:** It should be possible to test the component with every variant of the available props. We recommend using [args](https://storybook.js.org/docs/react/writing-stories/args)
+export const Default: Story = {
+  args: {
+    title: 'Default Component',
+    isVisible: true,
+  },
+};
+
+export const Hidden: Story = {
+  args: {
+    title: 'Hidden Component',
+    isVisible: false,
+  },
+};
+```
+
+## Performance Considerations
+
+### Use React.memo for Expensive Components
+
+```tsx
+import React, { memo } from 'react';
+
+export const ExpensiveComponent = memo<Props>(({ data }) => {
+  // Expensive rendering logic
+  return <div>{/* Component content */}</div>;
+});
+```
+
+### Optimize Re-renders
+
+Use `useCallback` and `useMemo` appropriately:
+
+```tsx
+export const OptimizedComponent: React.FC<Props> = ({ items, onSelect }) => {
+  const expensiveValue = useMemo(() => {
+    return items.reduce((acc, item) => acc + item.value, 0);
+  }, [items]);
+
+  const handleSelect = useCallback((id: string) => {
+    onSelect(id);
+  }, [onSelect]);
+
+  return <div>{/* Component content */}</div>;
+};
+```
+
+## Accessibility
+
+Ensure components are accessible:
+
+```tsx
+export const AccessibleButton: React.FC<Props> = ({ children, onClick }) => {
+  return (
+    <button
+      type="button"
+      aria-label="Descriptive label"
+      onClick={onClick}
+    >
+      {children}
+    </button>
+  );
+};
+```
+
+## Error Boundaries
+
+For components that might fail, consider error boundaries:
+
+```tsx
+export const SafeComponent: React.FC<Props> = ({ children }) => {
+  return (
+    <ErrorBoundary fallback={<div>Something went wrong</div>}>
+      {children}
+    </ErrorBoundary>
+  );
+};
+```

docs/developer_portal/guidelines/frontend/emotion-styling-guidelines.md

@@ -1,6 +1,6 @@
 ---
 title: Emotion Styling Guidelines and Best Practices
-sidebar_position: 3
+sidebar_position: 2
 ---
 
 <!--
@@ -33,245 +33,314 @@ under the License.
 - **DO** use `css` when you want to amend/merge sets of styles compositionally
 - **DO** use `css` when you're making a small, or single-use set of styles for a component
 - **DO** move your style definitions from direct usage in the `css` prop to an external variable when they get long
-- **DO** prefer tagged template literals (`css={css`...`}`) over style objects wherever possible for maximum style portability/consistency (note: typescript support may be diminished, but IDE plugins like [this](https://marketplace.visualstudio.com/items?itemName=jpoissonnier.vscode-styled-components) make life easy)
-- **DO** use `useTheme` to get theme variables. `withTheme` should be only used for wrapping legacy Class-based components.
+- **DO** prefer tagged template literals (`css={css\`...\`}`) over style objects wherever possible for maximum style portability/consistency
+- **DO** use `useTheme` to get theme variables
 
 ### DON'T do these things:
 
 - **DON'T** use `styled` for small, single-use style tweaks that would be easier to read/review if they were inline
-- **DON'T** export incomplete AntD components (make sure all their compound components are exported)
-
-## Emotion Tips and Strategies
-
-The first thing to consider when adding styles to an element is how much you think a style might be reusable in other areas of Superset. Always err on the side of reusability here. Nobody wants to chase styling inconsistencies, or try to debug little endless overrides scattered around the codebase. The more we can consolidate, the less will have to be figured out by those who follow. Reduce, reuse, recycle.
+- **DON'T** export incomplete Ant Design components
 
 ## When to use `css` or `styled`
 
-In short, either works for just about any use case! And you'll see them used somewhat interchangeably in the existing codebase. But we need a way to weigh it when we encounter the choice, so here's one way to think about it:
+### Use `css` for:
 
-A good use of `styled` syntax if you want to re-use a styled component. In other words, if you wanted to export flavors of a component for use, like so:
+1. **Small, single-use styles**
+```tsx
+import { css } from '@emotion/react';
 
-```jsx
-const StatusThing = styled.div`
-  padding: 10px;
-  border-radius: 10px;
+const MyComponent = () => (
+  <div
+    css={css`
+      margin: 8px;
+      padding: 16px;
+    `}
+  >
+    Content
+  </div>
+);
+```
+
+2. **Composing styles**
+```tsx
+const baseStyles = css`
+  padding: 16px;
+  border-radius: 4px;
 `;
 
-export const InfoThing = styled(StatusThing)`
-  background: blue;
-  &::before {
-    content: "ℹ️";
-  }
+const primaryStyles = css`
+  ${baseStyles}
+  background-color: blue;
+  color: white;
 `;
 
-export const WarningThing = styled(StatusThing)`
-  background: orange;
-  &::before {
-    content: "⚠️";
-  }
+const secondaryStyles = css`
+  ${baseStyles}
+  background-color: gray;
+  color: black;
 `;
+```
 
-export const TerribleThing = styled(StatusThing)`
-  background: red;
-  &::before {
-    content: "🔥";
+3. **Conditional styling**
+```tsx
+const MyComponent = ({ isActive }: { isActive: boolean }) => (
+  <div
+    css={[
+      baseStyles,
+      isActive && activeStyles,
+    ]}
+  >
+    Content
+  </div>
+);
+```
+
+### Use `styled` for:
+
+1. **Reusable components**
+```tsx
+import styled from '@emotion/styled';
+
+const StyledButton = styled.button`
+  padding: 12px 24px;
+  border: none;
+  border-radius: 4px;
+  background-color: ${({ theme }) => theme.colors.primary};
+  color: white;
+
+  &:hover {
+    background-color: ${({ theme }) => theme.colors.primaryDark};
   }
 `;
 ```
 
-You can also use `styled` when you're building a bigger component, and just want to have some custom bits for internal use in your JSX. For example:
+2. **Components with complex nested selectors**
+```tsx
+const StyledCard = styled.div`
+  padding: 16px;
+  border: 1px solid ${({ theme }) => theme.colors.border};
 
-```jsx
-const SeparatorOnlyUsedInThisComponent = styled.hr`
-  height: 12px;
-  border: 0;
-  box-shadow: inset 0 12px 12px -12px rgba(0, 0, 0, 0.5);
+  .card-header {
+    font-weight: bold;
+    margin-bottom: 8px;
+  }
+
+  .card-content {
+    color: ${({ theme }) => theme.colors.text};
+
+    p {
+      margin-bottom: 12px;
+    }
+  }
 `;
-
-function SuperComplicatedComponent(props) {
-  return (
-    <>
-      Daily standup for {user.name}!
-      <SeparatorOnlyUsedInThisComponent />
-      <h2>Yesterday:</h2>
-      // spit out a list of accomplishments
-      <SeparatorOnlyUsedInThisComponent />
-      <h2>Today:</h2>
-      // spit out a list of plans
-      <SeparatorOnlyUsedInThisComponent />
-      <h2>Tomorrow:</h2>
-      // spit out a list of goals
-    </>
-  );
-}
 ```
 
-The `css` prop, in reality, shares all the same styling capabilities as `styled` but it does have some particular use cases that jump out as sensible. For example, if you just want to style one element in your component, you could add the styles inline like so:
+3. **Extending Ant Design components**
+```tsx
+import { Button } from 'antd';
+import styled from '@emotion/styled';
 
-```jsx
-function SomeFanciness(props) {
-  return (
-    <>
-      Here's an awesome report card for {user.name}!
-      <div
-        css={css`
-          box-shadow: 5px 5px 10px #ccc;
-          border-radius: 10px;
-        `}
-      >
-        <h2>Yesterday:</h2>
-        // ...some stuff
-        <h2>Today:</h2>
-        // ...some stuff
-        <h2>Tomorrow:</h2>
-        // ...some stuff
-      </div>
-    </>
-  );
-}
+const CustomButton = styled(Button)`
+  border-radius: 8px;
+  font-weight: 600;
+
+  &.ant-btn-primary {
+    background: linear-gradient(45deg, #1890ff, #722ed1);
+  }
+`;
 ```
 
-You can also define the styles as a variable, external to your JSX. This is handy if the styles get long and you just want it out of the way. This is also handy if you want to apply the same styles to disparate element types, kind of like you might use a CSS class on varied elements. Here's a trumped up example:
+## Using Theme Variables
 
-```jsx
-function FakeGlobalNav(props) {
-  const menuItemStyles = css`
-    display: block;
-    border-bottom: 1px solid cadetblue;
-    font-family: "Comic Sans", cursive;
-  `;
+Always use theme variables for consistent styling:
+
+```tsx
+import { useTheme } from '@emotion/react';
+
+const MyComponent = () => {
+  const theme = useTheme();
 
   return (
-    <Nav>
-      <a css={menuItemStyles} href="#">One link</a>
-      <Link css={menuItemStyles} to={url}>Another link</Link>
-      <div css={menuItemStyles} onClick={() => alert('clicked')}>Another link</div>
-    </Nav>
-  );
-}
-```
-
-## CSS tips and tricks
-
-### `css` lets you write actual CSS
-
-By default the `css` prop uses the object syntax with JS style definitions, like so:
-
-```jsx
-<div css={{
-  borderRadius: 10,
-  marginTop: 10,
-  backgroundColor: '#00FF00'
-}}>Howdy</div>
-```
-
-But you can use the `css` interpolator as well to get away from icky JS styling syntax. Doesn't this look cleaner?
-
-```jsx
-<div css={css`
-  border-radius: 10px;
-  margin-top: 10px;
-  background-color: #00FF00;
-`}>Howdy</div>
-```
-
-You might say "whatever… I can read and write JS syntax just fine." Well, that's great. But… let's say you're migrating in some of our legacy LESS styles… now it's copy/paste! Or if you want to migrate to or from `styled` syntax… also copy/paste!
-
-### You can combine `css` definitions with array syntax
-
-You can use multiple groupings of styles with the `css` interpolator, and combine/override them in array syntax, like so:
-
-```jsx
-function AnotherSillyExample(props) {
-  const shadowedCard = css`
-    box-shadow: 2px 2px 4px #999;
-    padding: 4px;
-  `;
-  const infoCard = css`
-    background-color: #33f;
-    border-radius: 4px;
-  `;
-  const overrideInfoCard = css`
-    background-color: #f33;
-  `;
-  return (
-    <div className="App">
-      Combining two classes:
-      <div css={[shadowedCard, infoCard]}>Hello</div>
-      Combining again, but now with overrides:
-      <div css={[shadowedCard, infoCard, overrideInfoCard]}>Hello</div>
+    <div
+      css={css`
+        background-color: ${theme.colors.grayscale.light5};
+        color: ${theme.colors.grayscale.dark2};
+        padding: ${theme.gridUnit * 4}px;
+        border-radius: ${theme.borderRadius}px;
+      `}
+    >
+      Content
     </div>
   );
+};
+```
+
+## Common Patterns
+
+### Responsive Design
+```tsx
+const ResponsiveContainer = styled.div`
+  display: flex;
+  flex-direction: column;
+
+  ${({ theme }) => theme.breakpoints.up('md')} {
+    flex-direction: row;
+  }
+`;
+```
+
+### Animation
+```tsx
+const FadeInComponent = styled.div`
+  opacity: 0;
+  transition: opacity 0.3s ease-in-out;
+
+  &.visible {
+    opacity: 1;
+  }
+`;
+```
+
+### Conditional Props
+```tsx
+interface StyledDivProps {
+  isHighlighted?: boolean;
+  size?: 'small' | 'medium' | 'large';
 }
-```
 
-### Style variations with props
+const StyledDiv = styled.div<StyledDivProps>`
+  padding: 16px;
+  background-color: ${({ isHighlighted, theme }) =>
+    isHighlighted ? theme.colors.primary : theme.colors.grayscale.light5};
 
-You can give any component a custom prop, and reference that prop in your component styles, effectively using the prop to turn on a "flavor" of that component.
-
-For example, let's make a styled component that acts as a card. Of course, this could be done with any AntD component, or any component at all. But we'll do this with a humble `div` to illustrate the point:
-
-```jsx
-const SuperCard = styled.div`
-  ${({ theme, cutout }) => `
-    padding: ${theme.gridUnit * 2}px;
-    border-radius: ${theme.borderRadius}px;
-    box-shadow: 10px 5px 10px #ccc ${cutout && 'inset'};
-    border: 1px solid ${cutout ? 'transparent' : theme.colors.secondary.light3};
-  `}
+  ${({ size }) => {
+    switch (size) {
+      case 'small':
+        return css`font-size: 12px;`;
+      case 'large':
+        return css`font-size: 18px;`;
+      default:
+        return css`font-size: 14px;`;
+    }
+  }}
 `;
 ```
 
-Then just use the component as `<SuperCard>Some content</SuperCard>` or with the (potentially dynamic) prop: `<SuperCard cutout>Some content</SuperCard>`
+## Best Practices
 
-## Styled component tips
+### 1. Use Semantic CSS Properties
+```tsx
+// ✅ Good - semantic property names
+const Header = styled.h1`
+  font-size: ${({ theme }) => theme.typography.sizes.xl};
+  margin-bottom: ${({ theme }) => theme.gridUnit * 4}px;
+`;
 
-### No need to use `theme` the hard way
+// ❌ Avoid - magic numbers
+const Header = styled.h1`
+  font-size: 24px;
+  margin-bottom: 16px;
+`;
+```
 
-It's very tempting (and commonly done) to use the `theme` prop inline in the template literal like so:
+### 2. Group Related Styles
+```tsx
+// ✅ Good - grouped styles
+const Card = styled.div`
+  /* Layout */
+  display: flex;
+  flex-direction: column;
+  padding: ${({ theme }) => theme.gridUnit * 4}px;
 
-```jsx
-const SomeStyledThing = styled.div`
-  padding: ${({ theme }) => theme.gridUnit * 2}px;
+  /* Appearance */
+  background-color: ${({ theme }) => theme.colors.grayscale.light5};
+  border: 1px solid ${({ theme }) => theme.colors.grayscale.light2};
   border-radius: ${({ theme }) => theme.borderRadius}px;
-  border: 1px solid ${({ theme }) => theme.colors.secondary.light3};
+
+  /* Typography */
+  font-family: ${({ theme }) => theme.typography.families.sansSerif};
+  color: ${({ theme }) => theme.colors.grayscale.dark2};
 `;
 ```
 
-Instead, you can make things a little easier to read/type by writing it like so:
+### 3. Extract Complex Styles
+```tsx
+// ✅ Good - extract complex styles to variables
+const complexGradient = css`
+  background: linear-gradient(
+    135deg,
+    ${({ theme }) => theme.colors.primary} 0%,
+    ${({ theme }) => theme.colors.secondary} 100%
+  );
+`;
 
-```jsx
-const SomeStyledThing = styled.div`
-  ${({ theme }) => `
-    padding: ${theme.gridUnit * 2}px;
-    border-radius: ${theme.borderRadius}px;
-    border: 1px solid ${theme.colors.secondary.light3};
-  `}
+const GradientButton = styled.button`
+  ${complexGradient}
+  padding: 12px 24px;
+  border: none;
+  color: white;
 `;
 ```
 
-## Extend an AntD component with custom styling
+### 4. Avoid Deep Nesting
+```tsx
+// ✅ Good - shallow nesting
+const Navigation = styled.nav`
+  .nav-item {
+    padding: 8px 16px;
+  }
 
-As mentioned, you want to keep your styling as close to the root of your component system as possible, to minimize repetitive styling/overrides, and err on the side of reusability. In some cases, that means you'll want to globally tweak one of our core components to match our design system. In Superset, that's Ant Design (AntD).
-
-AntD uses a cool trick called compound components. For example, the `Menu` component also lets you use `Menu.Item`, `Menu.SubMenu`, `Menu.ItemGroup`, and `Menu.Divider`.
-
-### The `Object.assign` trick
-
-Let's say you want to override an AntD component called `Foo`, and have `Foo.Bar` display some custom CSS for the `Bar` compound component. You can do it effectively like so:
-
-```jsx
-import {
-  Foo as AntdFoo,
-} from 'antd';
-
-export const StyledBar = styled(AntdFoo.Bar)`
-  border-radius: ${({ theme }) => theme.borderRadius}px;
+  .nav-link {
+    color: ${({ theme }) => theme.colors.text};
+    text-decoration: none;
+  }
 `;
 
-export const Foo = Object.assign(AntdFoo, {
-  Bar: StyledBar,
+// ❌ Avoid - deep nesting
+const Navigation = styled.nav`
+  ul {
+    li {
+      a {
+        span {
+          color: blue; /* Too nested */
+        }
+      }
+    }
+  }
+`;
+```
+
+## Performance Tips
+
+### 1. Avoid Inline Functions in CSS
+```tsx
+// ✅ Good - external function
+const getBackgroundColor = (isActive: boolean, theme: any) =>
+  isActive ? theme.colors.primary : theme.colors.secondary;
+
+const Button = styled.button<{ isActive: boolean }>`
+  background-color: ${({ isActive, theme }) => getBackgroundColor(isActive, theme)};
+`;
+
+// ❌ Avoid - inline function (creates new function on each render)
+const Button = styled.button<{ isActive: boolean }>`
+  background-color: ${({ isActive, theme }) =>
+    isActive ? theme.colors.primary : theme.colors.secondary};
+`;
+```
+
+### 2. Use CSS Objects for Dynamic Styles
+```tsx
+// For highly dynamic styles, consider CSS objects
+const dynamicStyles = (props: Props) => ({
+  backgroundColor: props.color,
+  fontSize: `${props.size}px`,
+  // ... other dynamic properties
 });
-```
 
-You can then import this customized `Foo` and use `Foo.Bar` as expected. You should probably save your creation in `src/components` for maximum reusability, and add a Storybook entry so future engineers can view your creation, and designers can better understand how it fits the Superset Design System.
+const DynamicComponent = (props: Props) => (
+  <div css={dynamicStyles(props)}>
+    Content
+  </div>
+);
+```

docs/developer_portal/guidelines/frontend/testing-guidelines.md

@@ -0,0 +1,297 @@
+---
+title: Testing Guidelines and Best Practices
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Testing Guidelines and Best Practices
+
+We feel that tests are an important part of a feature and not an additional or optional effort. That's why we colocate test files with functionality and sometimes write tests upfront to help validate requirements and shape the API of our components. Every new component or file added should have an associated test file with the `.test` extension.
+
+We use Jest, React Testing Library (RTL), and Cypress to write our unit, integration, and end-to-end tests. For each type, we have a set of best practices/tips described below:
+
+## Jest
+
+### Write simple, standalone tests
+
+The importance of simplicity is often overlooked in test cases. Clear, dumb code should always be preferred over complex ones. The test cases should be pretty much standalone and should not involve any external logic if not absolutely necessary. That's because you want the corpus of the tests to be easy to read and understandable at first sight.
+
+### Avoid nesting when you're testing
+
+Avoid the use of `describe` blocks in favor of inlined tests. If your tests start to grow and you feel the need to group tests, prefer to break them into multiple test files. Check this awesome [article](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing) written by [Kent C. Dodds](https://kentcdodds.com/) about this topic.
+
+### No warnings!
+
+Your tests shouldn't trigger warnings. This is really common when testing async functionality. It's really difficult to read test results when we have a bunch of warnings.
+
+## React Testing Library (RTL)
+
+### Keep accessibility in mind when writing your tests
+
+One of the most important points of RTL is accessibility and this is also a very important point for us. We should try our best to follow the RTL [Priority](https://testing-library.com/docs/queries/about/#priority) when querying for elements in our tests. `getByTestId` is not viewable by the user and should only be used when the element isn't accessible in any other way.
+
+### Don't use `act` unnecessarily
+
+`render` and `fireEvent` are already wrapped in `act`, so wrapping them in `act` again is a common mistake. Some solutions to the warnings related to async testing can be found in the RTL docs.
+
+## Example Test Structure
+
+```tsx
+// MyComponent.test.tsx
+import { render, screen, fireEvent, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import { MyComponent } from './MyComponent';
+
+// ✅ Good - Simple, standalone test
+test('renders loading state initially', () => {
+  render(<MyComponent />);
+  expect(screen.getByText('Loading...')).toBeInTheDocument();
+});
+
+// ✅ Good - Tests user interaction
+test('calls onSubmit when form is submitted', async () => {
+  const user = userEvent.setup();
+  const mockOnSubmit = jest.fn();
+
+  render(<MyComponent onSubmit={mockOnSubmit} />);
+
+  await user.type(screen.getByLabelText('Username'), 'testuser');
+  await user.click(screen.getByRole('button', { name: 'Submit' }));
+
+  expect(mockOnSubmit).toHaveBeenCalledWith({ username: 'testuser' });
+});
+
+// ✅ Good - Tests async behavior
+test('displays error message when API call fails', async () => {
+  const mockFetch = jest.fn().mockRejectedValue(new Error('API Error'));
+  global.fetch = mockFetch;
+
+  render(<MyComponent />);
+
+  await waitFor(() => {
+    expect(screen.getByText('Error: API Error')).toBeInTheDocument();
+  });
+});
+```
+
+## Testing Best Practices
+
+### Use appropriate queries in priority order
+
+1. **Accessible to everyone**: `getByRole`, `getByLabelText`, `getByPlaceholderText`, `getByText`
+2. **Semantic queries**: `getByAltText`, `getByTitle`
+3. **Test IDs**: `getByTestId` (last resort)
+
+```tsx
+// ✅ Good - using accessible queries
+test('user can submit form', () => {
+  render(<LoginForm />);
+
+  const usernameInput = screen.getByLabelText('Username');
+  const passwordInput = screen.getByLabelText('Password');
+  const submitButton = screen.getByRole('button', { name: 'Log in' });
+
+  // Test implementation
+});
+
+// ❌ Avoid - using test IDs when better options exist
+test('user can submit form', () => {
+  render(<LoginForm />);
+
+  const usernameInput = screen.getByTestId('username-input');
+  const passwordInput = screen.getByTestId('password-input');
+  const submitButton = screen.getByTestId('submit-button');
+
+  // Test implementation
+});
+```
+
+### Test behavior, not implementation details
+
+```tsx
+// ✅ Good - tests what the user experiences
+test('shows success message after successful form submission', async () => {
+  render(<ContactForm />);
+
+  await userEvent.type(screen.getByLabelText('Email'), 'test@example.com');
+  await userEvent.click(screen.getByRole('button', { name: 'Submit' }));
+
+  await waitFor(() => {
+    expect(screen.getByText('Message sent successfully!')).toBeInTheDocument();
+  });
+});
+
+// ❌ Avoid - testing implementation details
+test('calls setState when form is submitted', () => {
+  const component = shallow(<ContactForm />);
+  const instance = component.instance();
+  const spy = jest.spyOn(instance, 'setState');
+
+  instance.handleSubmit();
+  expect(spy).toHaveBeenCalled();
+});
+```
+
+### Mock external dependencies appropriately
+
+```tsx
+// Mock API calls
+jest.mock('../api/userService', () => ({
+  getUser: jest.fn(),
+  createUser: jest.fn(),
+}));
+
+// Mock components that aren't relevant to the test
+jest.mock('../Chart/Chart', () => {
+  return function MockChart() {
+    return <div data-testid="mock-chart">Chart Component</div>;
+  };
+});
+```
+
+## Async Testing Patterns
+
+### Testing async operations
+
+```tsx
+test('loads and displays user data', async () => {
+  const mockUser = { id: 1, name: 'John Doe' };
+  const mockGetUser = jest.fn().mockResolvedValue(mockUser);
+
+  render(<UserProfile getUserData={mockGetUser} />);
+
+  // Wait for the async operation to complete
+  await waitFor(() => {
+    expect(screen.getByText('John Doe')).toBeInTheDocument();
+  });
+
+  expect(mockGetUser).toHaveBeenCalledTimes(1);
+});
+```
+
+### Testing loading states
+
+```tsx
+test('shows loading spinner while fetching data', async () => {
+  const mockGetUser = jest.fn().mockImplementation(
+    () => new Promise(resolve => setTimeout(resolve, 100))
+  );
+
+  render(<UserProfile getUserData={mockGetUser} />);
+
+  expect(screen.getByText('Loading...')).toBeInTheDocument();
+
+  await waitFor(() => {
+    expect(screen.queryByText('Loading...')).not.toBeInTheDocument();
+  });
+});
+```
+
+## Component-Specific Testing
+
+### Testing form components
+
+```tsx
+test('validates required fields', async () => {
+  render(<RegistrationForm />);
+
+  const submitButton = screen.getByRole('button', { name: 'Register' });
+  await userEvent.click(submitButton);
+
+  expect(screen.getByText('Username is required')).toBeInTheDocument();
+  expect(screen.getByText('Email is required')).toBeInTheDocument();
+});
+```
+
+### Testing modals and overlays
+
+```tsx
+test('opens and closes modal', async () => {
+  render(<ModalContainer />);
+
+  const openButton = screen.getByRole('button', { name: 'Open Modal' });
+  await userEvent.click(openButton);
+
+  expect(screen.getByRole('dialog')).toBeInTheDocument();
+
+  const closeButton = screen.getByRole('button', { name: 'Close' });
+  await userEvent.click(closeButton);
+
+  expect(screen.queryByRole('dialog')).not.toBeInTheDocument();
+});
+```
+
+### Testing with context providers
+
+```tsx
+const renderWithTheme = (component: React.ReactElement) => {
+  return render(
+    <ThemeProvider theme={mockTheme}>
+      {component}
+    </ThemeProvider>
+  );
+};
+
+test('applies theme colors correctly', () => {
+  renderWithTheme(<ThemedButton />);
+
+  const button = screen.getByRole('button');
+  expect(button).toHaveStyle({
+    backgroundColor: mockTheme.colors.primary,
+  });
+});
+```
+
+## Performance Testing
+
+### Testing with large datasets
+
+```tsx
+test('handles large lists efficiently', () => {
+  const largeDataset = Array.from({ length: 10000 }, (_, i) => ({
+    id: i,
+    name: `Item ${i}`,
+  }));
+
+  const { container } = render(<VirtualizedList items={largeDataset} />);
+
+  // Should only render visible items
+  const renderedItems = container.querySelectorAll('[data-testid="list-item"]');
+  expect(renderedItems.length).toBeLessThan(100);
+});
+```
+
+## Testing Accessibility
+
+```tsx
+test('is accessible to screen readers', () => {
+  render(<AccessibleForm />);
+
+  const form = screen.getByRole('form');
+  const inputs = screen.getAllByRole('textbox');
+
+  inputs.forEach(input => {
+    expect(input).toHaveAttribute('aria-label');
+  });
+
+  expect(form).toHaveAttribute('aria-describedby');
+});
+```

docs/developer_portal/sidebars.js

@@ -36,20 +36,13 @@ module.exports = {
         'extensions/overview',
         'extensions/quick-start',
         'extensions/architecture',
-        'extensions/contribution-types',
-        {
-          type: 'category',
-          label: 'Extension Points',
-          collapsed: true,
-          items: [
-            'extensions/extension-points/sqllab',
-          ],
-        },
-        'extensions/development',
-        'extensions/deployment',
-        'extensions/mcp',
-        'extensions/security',
-        'extensions/registry',
+        'extensions/extension-project-structure',
+        'extensions/extension-metadata',
+        'extensions/frontend-contribution-types',
+        'extensions/interacting-with-host',
+        'extensions/deploying-extension',
+        'extensions/development-mode',
+        'extensions/security-implications',
       ],
     },
     {

docs/developer_portal/testing/testing-guidelines.md

@@ -1,129 +0,0 @@
----
-title: Testing Guidelines and Best Practices
-sidebar_position: 1
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Testing Guidelines and Best Practices
-
-We feel that tests are an important part of a feature and not an additional or optional effort. That's why we colocate test files with functionality and sometimes write tests upfront to help validate requirements and shape the API of our components. Every new component or file added should have an associated test file with the `.test` extension.
-
-We use Jest, React Testing Library (RTL), and Cypress to write our unit, integration, and end-to-end tests. For each type, we have a set of best practices/tips described below:
-
-## Jest
-
-### Write simple, standalone tests
-
-The importance of simplicity is often overlooked in test cases. Clear, dumb code should always be preferred over complex ones. The test cases should be pretty much standalone and should not involve any external logic if not absolutely necessary. That's because you want the corpus of the tests to be easy to read and understandable at first sight.
-
-### Avoid nesting when you're testing
-
-Avoid the use of `describe` blocks in favor of inlined tests. If your tests start to grow and you feel the need to group tests, prefer to break them into multiple test files. Check this awesome [article](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing) written by [Kent C. Dodds](https://kentcdodds.com/) about this topic.
-
-### No warnings!
-
-Your tests shouldn't trigger warnings. This is really common when testing async functionality. It's really difficult to read test results when we have a bunch of warnings.
-
-### Example
-
-You can find an example of a test [here](https://github.com/apache/superset/blob/e6c5bf4/superset-frontend/src/common/hooks/useChangeEffect/useChangeEffect.test.ts).
-
-## React Testing Library (RTL)
-
-### Keep accessibility in mind when writing your tests
-
-One of the most important points of RTL is accessibility and this is also a very important point for us. We should try our best to follow the RTL [Priority](https://testing-library.com/docs/queries/about/#priority) when querying for elements in our tests. `getByTestId` is not viewable by the user and should only be used when the element isn't accessible in any other way.
-
-### Don't use `act` unnecessarily
-
-`render` and `fireEvent` are already wrapped in `act`, so wrapping them in `act` again is a common mistake. Some solutions to the warnings related to `act` might be found [here](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning).
-
-### Be specific when using *ByRole
-
-By using the `name` option we can point to the items by their accessible name. For example:
-
-```jsx
-screen.getByRole('button', { name: /hello world/i })
-```
-
-Using the `name` property also avoids breaking the tests in the future if other components with the same role are added.
-
-### userEvent vs fireEvent
-
-Prefer the [user-event](https://github.com/testing-library/user-event) library, which provides a more advanced simulation of browser interactions than the built-in [fireEvent](https://testing-library.com/docs/dom-testing-library/api-events/#fireevent) method.
-
-### Usage of waitFor
-
-- [Prefer to use `find`](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#using-waitfor-to-wait-for-elements-that-can-be-queried-with-find) over `waitFor` when you're querying for elements. Even though both achieve the same objective, the `find` version is simpler and you'll get better error messages.
-- Prefer to use only [one assertion at a time](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#having-multiple-assertions-in-a-single-waitfor-callback). If you put multiple assertions inside a `waitFor` we could end up waiting for the whole block timeout before seeing a test failure even if the failure occurred at the first assertion. By putting a single assertion in there, we can improve on test execution time.
-- Do not perform [side-effects](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#performing-side-effects-in-waitfor) inside `waitFor`. The callback can be called a non-deterministic number of times and frequency (it's called both on an interval as well as when there are DOM mutations). So this means that your side-effect could run multiple times.
-
-### Example
-
-You can find an example of a test [here](https://github.com/apache/superset/blob/master/superset-frontend/src/dashboard/components/PublishedStatus/PublishedStatus.test.tsx).
-
-## Cypress
-
-### Prefer to use Cypress for e2e testing and RTL for integration testing
-
-Here it's important to make the distinction between e2e and integration testing. This [article](https://www.onpathtesting.com/blog/end-to-end-vs-integration-testing) gives an excellent definition:
-
-> End-to-end testing verifies that your software works correctly from the beginning to the end of a particular user flow. It replicates expected user behavior and various usage scenarios to ensure that your software works as whole. End-to-end testing uses a production equivalent environment and data to simulate real-world situations and may also involve the integrations your software has with external applications.
-
-> A typical software project consists of multiple software units, usually coded by different developers. Integration testing combines those software units logically and tests them as a group.
-> Essentially, integration testing verifies whether or not the individual modules or services that make up your application work well together. The purpose of this level of testing is to expose defects in the interaction between these software modules when they are integrated.
-
-Do not use Cypress when RTL can do it better and faster. Many of the Cypress tests that we have right now, fall into the integration testing category and can be ported to RTL which is much faster and gives more immediate feedback. Cypress should be used mainly for end-to-end testing, replicating the user experience, with positive and negative flows.
-
-### Isolated and standalone tests
-
-Tests should never rely on other tests to pass. This might be hard when a single user is used for testing as data will be stored in the database. At every new test, we should reset the database.
-
-### Cleaning state
-
-Cleaning the state of the application, such as resetting the DB, or in general, any state that might affect consequent tests should always be done in the `beforeEach` hook and never in the `afterEach` one as the `beforeEach` is guaranteed to run, while the test might never reach the point to run the `afterEach` hook. One example would be if you refresh Cypress in the middle of the test. At this point, you will have built up a partial state in the database, and your clean-up function will never get called. You can read more about it [here](https://docs.cypress.io/guides/references/best-practices#Using-after-or-afterEach-hooks).
-
-### Unnecessary use of `cy.wait`
-
-- Unnecessary when using `cy.request()` as it will resolve when a response is received from the server
-- Unnecessary when using `cy.visit()` as it resolves only when the page fires the load event
-- Unnecessary when using `cy.get()`. When the selector should wait for a request to happen, aliases would come in handy:
-
-```js
-cy.intercept('GET', '/users', [{ name: 'Maggy' }, { name: 'Joan' }]).as('getUsers')
-cy.get('#fetch').click()
-cy.wait('@getUsers') // <--- wait explicitly for this route to finish
-cy.get('table tr').should('have.length', 2)
-```
-
-### Accessibility and Resilience
-
-The same accessibility principles in the RTL section apply here. Use accessible selectors when querying for elements. Those principles also help to isolate selectors from eventual CSS and JS changes and improve the resilience of your tests.
-
-## References
-
-- [Avoid Nesting when you're Testing](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing)
-- [RTL - Queries](https://testing-library.com/docs/queries/about/#priority)
-- [Fix the "not wrapped in act(...)" warning](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning)
-- [Common mistakes with React Testing Library](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library)
-- [ARIA Roles](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles)
-- [Cypress - Best Practices](https://docs.cypress.io/guides/references/best-practices)
-- [End-to-end vs integration tests: what's the difference?](https://www.onpathtesting.com/blog/end-to-end-vs-integration-testing)

docs/docs/configuration/alerts-reports.mdx

@@ -294,14 +294,6 @@ Check this by attempting to `curl` the URL of a report that you see in the error
 
 In a deployment with authentication measures enabled like HTTPS and Single Sign-On, it may make sense to have the worker navigate directly to the Superset application running in the same location, avoiding the need to sign in.  For instance, you could use `WEBDRIVER_BASEURL="http://superset_app:8088"` for a docker compose deployment, and set `"force_https": False,` in your `TALISMAN_CONFIG`.
 
-### Duplicate report deliveries
-
-In some deployment configurations a scheduled report can be delivered more than once around its planned time. This typically happens when more than one process is responsible for running the alerts & reports schedule (for example, multiple schedulers or Celery beat instances). To avoid duplicate emails or notifications:
-
-- Ensure that only a **single scheduler/beat process** is configured to trigger alerts and reports for a given environment.
-- If you run **multiple Celery workers**, verify that there is still only one component responsible for scheduling the report tasks (workers should execute tasks, not schedule them independently).
-- Review your deployment/orchestration setup (for example systemd, Docker, or Kubernetes) to make sure the alerts & reports scheduler is **not started from multiple places by accident**.
-
 ## Scheduling Queries as Reports
 
 You can optionally allow your users to schedule queries directly in SQL Lab. This is done by adding

docs/docs/configuration/async-queries-celery.mdx

@@ -52,11 +52,11 @@ To start a job which schedules periodic background jobs, run the following comma
 celery --app=superset.tasks.celery_app:app beat
 ```
 
-To setup a result backend, you need to pass an instance of a derivative of `BaseCache` (`from
-flask_caching.backends.base import BaseCache`) to the RESULTS_BACKEND configuration key in your
-superset_config.py. You can use Memcached, Redis, S3 (https://pypi.python.org/pypi/s3werkzeugcache),
-memory or the file system (in a single server-type setup or for testing), or to write your own
-caching interface. Your `superset_config.py` may look something like:
+To setup a result backend, you need to pass an instance of a derivative of from
+from flask_caching.backends.base import BaseCache to the RESULTS_BACKEND configuration key in your superset_config.py. You can
+use Memcached, Redis, S3 (https://pypi.python.org/pypi/s3werkzeugcache), memory or the file system
+(in a single server-type setup or for testing), or to write your own caching interface. Your
+`superset_config.py` may look something like:
 
 ```python
 # On S3

docs/docs/configuration/databases.mdx

@@ -54,7 +54,6 @@ are compatible with Superset.
 | [Ascend.io](/docs/configuration/databases#ascendio)                       | `pip install impyla`                                                               | `ascend://{username}:{password}@{hostname}:{port}/{database}?auth_mechanism=PLAIN;use_ssl=true`                                                        |
 | [Azure MS SQL](/docs/configuration/databases#sql-server)                | `pip install pymssql`                                                              | `mssql+pymssql://UserName@presetSQL:TestPassword@presetSQL.database.windows.net:1433/TestSchema`                                                       |
 | [ClickHouse](/docs/configuration/databases#clickhouse)                  | `pip install clickhouse-connect`                                                   | `clickhousedb://{username}:{password}@{hostname}:{port}/{database}`                                                                                    |
-| [Cloudflare D1](/docs/configuration/databases#cloudflare-d1)                  | `pip install superset-engine-d1` or `pip install apache_superset[d1]`                                                  | `d1://{cloudflare_account_id}:{cloudflare_api_token}@{cloudflare_d1_database_id}`                                                                                    |
 | [CockroachDB](/docs/configuration/databases#cockroachdb)                | `pip install cockroachdb`                                                          | `cockroachdb://root@{hostname}:{port}/{database}?sslmode=disable`                                                                                      |
 | [Couchbase](/docs/configuration/databases#couchbase)                | `pip install couchbase-sqlalchemy`                                                          | `couchbase://{username}:{password}@{hostname}:{port}?truststorepath={ssl certificate path}`                                                                                      |
 | [CrateDB](/docs/configuration/databases#cratedb)                        | `pip install sqlalchemy-cratedb`                                                   | `crate://{username}:{password}@{hostname}:{port}`, often useful: `?ssl=true/false` or `?schema=testdrive`.                                             |
@@ -360,20 +359,6 @@ uses the default user without a password (and doesn't encrypt the connection):
 clickhousedb://localhost/default
 ```
 
-#### Cloudflare D1
-
-To use Cloudflare D1 with superset, install the [superset-engine-d1](https://github.com/sqlalchemy-cf-d1/superset-engine-d1) library.
-
-```
-pip install superset-engine-d1
-```
-
-The expected connection string is formatted as follows:
-
-```
-d1://{cloudflare_account_id}:{cloudflare_api_token}@{cloudflare_d1_database_id}
-```
-
 #### CockroachDB
 
 The recommended connector library for CockroachDB is

docs/docs/configuration/sql-templating.mdx

@@ -26,8 +26,8 @@ made available in the Jinja context:
 
 - `columns`: columns which to group by in the query
 - `filter`: filters applied in the query
-- `from_dttm`: start `datetime` value from the selected time range (`None` if undefined). **Note:** Only available in virtual datasets when a time range filter is applied in Explore/Chart views—not available in standalone SQL Lab queries. (deprecated beginning in version 5.0, use `get_time_filter` instead)
-- `to_dttm`: end `datetime` value from the selected time range (`None` if undefined). **Note:** Only available in virtual datasets when a time range filter is applied in Explore/Chart views—not available in standalone SQL Lab queries. (deprecated beginning in version 5.0, use `get_time_filter` instead)
+- `from_dttm`: start `datetime` value from the selected time range (`None` if undefined) (deprecated beginning in version 5.0, use `get_time_filter` instead)
+- `to_dttm`: end `datetime` value from the selected time range (`None` if undefined). (deprecated beginning in version 5.0, use `get_time_filter` instead)
 - `groupby`: columns which to group by in the query (deprecated)
 - `metrics`: aggregate expressions in the query
 - `row_limit`: row limit of the query
@@ -67,54 +67,6 @@ the time filter is not set. For many database engines, this could be replaced wi
 Note that the Jinja parameters are called within _double_ brackets in the query and with
 _single_ brackets in the logic blocks.
 
-### Understanding Context Availability
-
-Some Jinja variables like `from_dttm`, `to_dttm`, and `filter` are **only available when a chart or dashboard provides them**. They are populated from:
-
-- Time range filters applied in Explore/Chart views
-- Dashboard native filters
-- Filter components
-
-**These variables are NOT available in standalone SQL Lab queries** because there's no filter context. If you try to use `{{ from_dttm }}` directly in SQL Lab, you'll get an "undefined parameter" error.
-
-#### Testing Time-Filtered Queries in SQL Lab
-
-To test queries that use time variables in SQL Lab, you have several options:
-
-**Option 1: Use Jinja defaults (recommended)**
-
-```sql
-SELECT *
-FROM tbl
-WHERE dttm_col > '{{ from_dttm | default("2024-01-01", true) }}'
-  AND dttm_col < '{{ to_dttm | default("2024-12-31", true) }}'
-```
-
-**Option 2: Use SQL Lab Parameters**
-
-Set parameters in the SQL Lab UI (Parameters menu):
-```json
-{
-  "from_dttm": "2024-01-01",
-  "to_dttm": "2024-12-31"
-}
-```
-
-**Option 3: Use `{% set %}` for testing**
-
-```sql
-{% set from_dttm = "2024-01-01" %}
-{% set to_dttm = "2024-12-31" %}
-SELECT *
-FROM tbl
-WHERE dttm_col > '{{ from_dttm }}' AND dttm_col < '{{ to_dttm }}'
-```
-
-:::tip
-When you save a SQL Lab query as a virtual dataset and use it in a chart with time filters,
-the actual filter values will override any defaults or test values you set.
-:::
-
 To add custom functionality to the Jinja context, you need to overload the default Jinja
 context in your environment by defining the `JINJA_CONTEXT_ADDONS` in your superset configuration
 (`superset_config.py`). Objects referenced in this dictionary are made available for users to use

docs/docs/configuration/theming.mdx

@@ -110,30 +110,18 @@ To export a theme for use in configuration files or another instance:
 
 ## Custom Fonts
 
-Superset supports custom fonts through the theme configuration, allowing you to use branded or custom typefaces without rebuilding the application.
-
-### Default Fonts
-
-By default, Superset uses Inter and Fira Code fonts which are bundled with the application via `@fontsource` packages. These fonts work offline and require no external network calls.
+Superset supports custom fonts through runtime configuration, allowing you to use branded or custom typefaces without rebuilding the application.
 
 ### Configuring Custom Fonts
 
-To use custom fonts, add font URLs to your theme configuration using the `fontUrls` token:
+Add font URLs to your `superset_config.py`:
 
 ```python
-THEME_DEFAULT = {
-    "token": {
-        # Load fonts from external sources (e.g., Google Fonts, Adobe Fonts)
-        "fontUrls": [
-            "https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;600;700&display=swap",
-            "https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500&display=swap",
-        ],
-        # Reference the loaded fonts
-        "fontFamily": "Roboto, -apple-system, BlinkMacSystemFont, sans-serif",
-        "fontFamilyCode": "JetBrains Mono, Monaco, monospace",
-        # ... other theme tokens
-    }
-}
+# Load fonts from Google Fonts, Adobe Fonts, or self-hosted sources
+CUSTOM_FONT_URLS = [
+    "https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap",
+    "https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500&display=swap",
+]
 
 # Update CSP to allow font sources
 TALISMAN_CONFIG = {
@@ -144,24 +132,31 @@ TALISMAN_CONFIG = {
 }
 ```
 
+### Using Custom Fonts in Themes
+
+Once configured, reference the fonts in your theme configuration:
+
+```python
+THEME_DEFAULT = {
+    "token": {
+        "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
+        "fontFamilyCode": "JetBrains Mono, Monaco, monospace",
+        # ... other theme tokens
+    }
+}
+```
+
 Or in the CRUD interface theme JSON:
 
 ```json
 {
   "token": {
-    "fontUrls": [
-      "https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;600;700&display=swap"
-    ],
-    "fontFamily": "Roboto, -apple-system, BlinkMacSystemFont, sans-serif",
+    "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
     "fontFamilyCode": "JetBrains Mono, Monaco, monospace"
   }
 }
 ```
 
-:::note
-Font URLs are validated against a configurable allowlist. By default, fonts from `fonts.googleapis.com`, `fonts.gstatic.com`, and `use.typekit.net` are allowed. Configure `THEME_FONT_URL_ALLOWED_DOMAINS` to customize the allowed domains.
-:::
-
 ### Font Sources
 
 - **Google Fonts**: Free, CDN-hosted fonts with wide variety

docs/docs/contributing/development.mdx

@@ -934,20 +934,6 @@ npm run storybook
 
 When contributing new React components to Superset, please try to add a Story alongside the component's `jsx/tsx` file.
 
-#### Testing Stories
-
-Superset uses [@storybook/test-runner](https://storybook.js.org/docs/writing-tests/test-runner) to validate that all stories compile and render without errors. This helps catch broken stories before they're merged.
-
-```bash
-# Run against a running Storybook server (start with `npm run storybook` first)
-npm run test-storybook
-
-# Build static Storybook and test (CI-friendly, no server needed)
-npm run test-storybook:ci
-```
-
-The `test-storybook` job runs automatically in CI on every pull request, ensuring stories remain functional.
-
 ## Tips
 
 ### Adding a new datasource

docs/docs/contributing/pkg-resources-migration.md

@@ -1,101 +0,0 @@
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# pkg_resources Deprecation and Migration Guide
-
-## Background
-
-As of setuptools 81.0.0 (scheduled for removal around 2025-11-30), the `pkg_resources` API is deprecated and will be removed. This affects several packages in the Python ecosystem.
-
-## Current Status
-
-### Superset Codebase ✅
-The Superset codebase has already migrated away from `pkg_resources` to the modern `importlib.metadata` API:
-
-- `superset/db_engine_specs/__init__.py:36` - Uses `from importlib.metadata import entry_points`
-- All entry point loading uses the modern API
-
-### Production Dependencies ⚠️
-Some third-party dependencies may still use `pkg_resources`:
-
-- **`clients` package** (Preset-specific): Uses `pkg_resources` in `const.py`
-- Error path: `/usr/local/lib/python3.10/site-packages/clients/const.py:1`
-
-## Migration Path
-
-### Short-term Solution (Current)
-Pin setuptools to version 80.x to prevent breaking changes:
-
-```python
-# requirements/base.in
-setuptools<81
-```
-
-This prevents the removal of `pkg_resources` while dependent packages are updated.
-
-### Long-term Solution
-Update all dependencies to use `importlib.metadata` instead of `pkg_resources`:
-
-#### Migration Example
-**Old (deprecated):**
-```python
-import pkg_resources
-
-version = pkg_resources.get_distribution("package_name").version
-entry_points = pkg_resources.iter_entry_points("group_name")
-```
-
-**New (recommended):**
-```python
-from importlib.metadata import version, entry_points
-
-pkg_version = version("package_name")
-eps = entry_points(group="group_name")
-```
-
-## Action Items
-
-### For Preset Team
-1. **Update `clients` package** to use `importlib.metadata` instead of `pkg_resources`
-2. **Review other internal packages** for `pkg_resources` usage
-3. **Test with setuptools >= 81.0.0** once all packages are migrated
-4. **Monitor Datadog logs** for similar deprecation warnings
-
-### For Superset Maintainers
-1. ✅ Already using `importlib.metadata`
-2. Monitor third-party dependencies for updates
-3. Update setuptools pin once ecosystem is ready
-
-## Timeline
-
-- **2025-11-30**: Expected removal of `pkg_resources` from setuptools
-- **Before then**: All dependencies must migrate to `importlib.metadata`
-
-## References
-
-- [setuptools pkg_resources deprecation notice](https://setuptools.pypa.io/en/latest/pkg_resources.html)
-- [importlib.metadata documentation](https://docs.python.org/3/library/importlib.metadata.html)
-- [Migration guide](https://setuptools.pypa.io/en/latest/deprecated/pkg_resources.html)
-
-## Monitoring
-
-Track this issue in production using Datadog:
-- Warning pattern: `pkg_resources is deprecated as an API`
-- Component: `@component:app`
-- Environment: `environment:production`

docs/docusaurus.config.ts

@@ -21,7 +21,6 @@ import type { Config } from '@docusaurus/types';
 import type { Options, ThemeConfig } from '@docusaurus/preset-classic';
 import { themes } from 'prism-react-renderer';
 import remarkImportPartial from 'remark-import-partial';
-import remarkLocalizeBadges from './plugins/remark-localize-badges.mjs';
 import * as fs from 'fs';
 import * as path from 'path';
 
@@ -45,7 +44,7 @@ if (!versionsConfig.components.disabled) {
       sidebarPath: require.resolve('./sidebarComponents.js'),
       editUrl:
         'https://github.com/apache/superset/edit/master/docs/components',
-      remarkPlugins: [remarkImportPartial, remarkLocalizeBadges],
+      remarkPlugins: [remarkImportPartial],
       docItemComponent: '@theme/DocItem',
       includeCurrentVersion: versionsConfig.components.includeCurrentVersion,
       lastVersion: versionsConfig.components.lastVersion,
@@ -69,7 +68,7 @@ if (!versionsConfig.developer_portal.disabled) {
       sidebarPath: require.resolve('./sidebarTutorials.js'),
       editUrl:
         'https://github.com/apache/superset/edit/master/docs/developer_portal',
-      remarkPlugins: [remarkImportPartial, remarkLocalizeBadges],
+      remarkPlugins: [remarkImportPartial],
       docItemComponent: '@theme/DocItem',
       includeCurrentVersion: versionsConfig.developer_portal.includeCurrentVersion,
       lastVersion: versionsConfig.developer_portal.lastVersion,
@@ -165,11 +164,7 @@ const config: Config = {
   favicon: '/img/favicon.ico',
   organizationName: 'apache',
   projectName: 'superset',
-  themes: [
-    '@saucelabs/theme-github-codeblock',
-    '@docusaurus/theme-mermaid',
-    '@docusaurus/theme-live-codeblock',
-  ],
+  themes: ['@saucelabs/theme-github-codeblock', '@docusaurus/theme-mermaid'],
   plugins: [
     require.resolve('./src/webpack.extend.ts'),
     [
@@ -342,7 +337,6 @@ const config: Config = {
             }
             return `https://github.com/apache/superset/edit/master/docs/${versionDocsDirPath}/${docPath}`;
           },
-          remarkPlugins: [remarkImportPartial, remarkLocalizeBadges],
           includeCurrentVersion: versionsConfig.docs.includeCurrentVersion,
           lastVersion: versionsConfig.docs.lastVersion,  // Make 'next' the default
           onlyIncludeVersions: versionsConfig.docs.onlyIncludeVersions,
@@ -480,9 +474,6 @@ const config: Config = {
         hideable: true,
       },
     },
-    liveCodeBlock: {
-      playgroundPosition: 'bottom',
-    },
   } satisfies ThemeConfig,
   scripts: [
     // {
@@ -496,7 +487,7 @@ const config: Config = {
       'data-project-name': 'Apache Superset',
       'data-project-color': '#FFFFFF',
       'data-project-logo':
-        'https://superset.apache.org/img/superset-logo-icon-only.png',
+        'https://images.seeklogo.com/logo-png/50/2/superset-icon-logo-png_seeklogo-500354.png',
       'data-modal-override-open-id': 'ask-ai-input',
       'data-modal-override-open-class': 'search-input',
       'data-modal-disclaimer':

docs/package.json

@@ -6,17 +6,16 @@
   "scripts": {
     "docusaurus": "docusaurus",
     "_init": "cat src/intro_header.txt ../README.md > docs/intro.md",
-    "start": "yarn run _init && yarn run generate:extension-components && NODE_ENV=development docusaurus start",
+    "start": "yarn run _init && NODE_ENV=development docusaurus start",
     "stop": "pkill -f 'docusaurus start' || pkill -f 'docusaurus serve' || echo 'No docusaurus server running'",
-    "build": "yarn run _init && yarn run generate:extension-components && DEBUG=docusaurus:* docusaurus build",
+    "build": "yarn run _init && DEBUG=docusaurus:* docusaurus build",
     "swizzle": "docusaurus swizzle",
     "deploy": "docusaurus deploy",
     "clear": "docusaurus clear",
     "serve": "yarn run _init && docusaurus serve",
     "write-translations": "docusaurus write-translations",
     "write-heading-ids": "docusaurus write-heading-ids",
-    "typecheck": "yarn run generate:extension-components && tsc",
-    "generate:extension-components": "node scripts/generate-extension-components.mjs",
+    "typecheck": "tsc",
     "eslint": "eslint .",
     "version:add": "node scripts/manage-versions.mjs add",
     "version:remove": "node scripts/manage-versions.mjs remove",
@@ -32,11 +31,10 @@
     "@docusaurus/core": "3.9.2",
     "@docusaurus/plugin-client-redirects": "3.9.2",
     "@docusaurus/preset-classic": "3.9.2",
-    "@docusaurus/theme-live-codeblock": "^3.9.2",
     "@docusaurus/theme-mermaid": "^3.9.2",
-    "@emotion/core": "^11.0.0",
+    "@emotion/core": "^10.0.27",
     "@emotion/react": "^11.13.3",
-    "@emotion/styled": "^11.14.1",
+    "@emotion/styled": "^10.0.27",
     "@mdx-js/react": "^3.1.1",
     "@saucelabs/theme-github-codeblock": "^0.3.0",
     "@storybook/addon-docs": "^8.6.11",
@@ -51,11 +49,11 @@
     "@storybook/preview-api": "^8.6.11",
     "@storybook/theming": "^8.6.11",
     "@superset-ui/core": "^0.20.4",
-    "antd": "^6.1.0",
-    "caniuse-lite": "^1.0.30001760",
+    "antd": "^5.28.0",
+    "caniuse-lite": "^1.0.30001754",
     "docusaurus-plugin-less": "^2.0.2",
     "json-bigint": "^1.0.0",
-    "less": "^4.5.1",
+    "less": "^4.4.2",
     "less-loader": "^12.3.0",
     "prism-react-renderer": "^2.4.1",
     "react": "^18.3.1",
@@ -65,27 +63,26 @@
     "remark-import-partial": "^0.0.2",
     "reselect": "^5.1.1",
     "storybook": "^8.6.11",
-    "swagger-ui-react": "^5.31.0",
+    "swagger-ui-react": "^5.30.2",
     "tinycolor2": "^1.4.2",
-    "ts-loader": "^9.5.4",
-    "unist-util-visit": "^5.0.0"
+    "ts-loader": "^9.5.4"
   },
   "devDependencies": {
     "@docusaurus/module-type-aliases": "^3.9.1",
     "@docusaurus/tsconfig": "^3.9.2",
-    "@eslint/js": "^9.39.2",
+    "@eslint/js": "^9.39.0",
     "@types/react": "^19.1.8",
     "@typescript-eslint/eslint-plugin": "^8.37.0",
-    "@typescript-eslint/parser": "^8.49.0",
-    "eslint": "^9.39.2",
+    "@typescript-eslint/parser": "^8.46.0",
+    "eslint": "^9.39.0",
     "eslint-config-prettier": "^10.1.8",
     "eslint-plugin-prettier": "^5.5.3",
     "eslint-plugin-react": "^7.37.5",
     "globals": "^16.5.0",
-    "prettier": "^3.7.4",
+    "prettier": "^3.6.2",
     "typescript": "~5.9.3",
-    "typescript-eslint": "^8.49.0",
-    "webpack": "^5.103.0"
+    "typescript-eslint": "^8.46.2",
+    "webpack": "^5.102.1"
   },
   "browserslist": {
     "production": [

docs/plugins/remark-localize-badges.mjs

@@ -1,224 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- *   http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-/**
- * Remark plugin to localize badge images from shields.io and similar services.
- *
- * This plugin downloads badge SVGs at build time and serves them locally,
- * avoiding external dependencies and caching issues with dynamic badges.
- *
- * Inspired by Apache Commons' fixshields.py approach.
- */
-
-import { visit } from 'unist-util-visit';
-import * as fs from 'fs';
-import * as path from 'path';
-import * as crypto from 'crypto';
-
-// Badge domains to localize (always localize all URLs from these domains)
-const BADGE_DOMAINS = [
-  'img.shields.io',
-  'badge.fury.io',
-  'codecov.io',
-  'badgen.net',
-  'nodei.co',
-];
-
-// Patterns for badge URLs on other domains (e.g., GitHub Actions badges)
-const BADGE_PATH_PATTERNS = [
-  /github\.com\/.*\/actions\/workflows\/.*\/badge\.svg/,
-  /github\.com\/.*\/badge\.svg/,
-];
-
-// Cache for downloaded badges (persists across files in a single build)
-const badgeCache = new Map();
-
-// Track if we've already ensured the badges directory exists
-let badgesDirCreated = false;
-
-/**
- * Generate a stable filename for a badge URL
- */
-function getBadgeFilename(url) {
-  const hash = crypto.createHash('md5').update(url).digest('hex').slice(0, 12);
-  // Extract a readable name from the URL
-  const urlPath = new URL(url).pathname;
-  const readablePart = urlPath
-    .replace(/^\//, '')
-    .replace(/[^a-zA-Z0-9-]/g, '_')
-    .slice(0, 40);
-  return `${readablePart}_${hash}.svg`;
-}
-
-/**
- * Check if a URL is a badge we should localize
- */
-function isBadgeUrl(url) {
-  if (!url) return false;
-  try {
-    const parsed = new URL(url);
-    // Check if it's from a known badge domain
-    if (BADGE_DOMAINS.some((domain) => parsed.hostname.includes(domain))) {
-      return true;
-    }
-    // Check if it matches a badge path pattern
-    return BADGE_PATH_PATTERNS.some((pattern) => pattern.test(url));
-  } catch {
-    return false;
-  }
-}
-
-/**
- * Download a badge and return the local path
- */
-async function downloadBadge(url, staticDir) {
-  // Check cache first
-  if (badgeCache.has(url)) {
-    return badgeCache.get(url);
-  }
-
-  const badgesDir = path.join(staticDir, 'badges');
-
-  // Ensure badges directory exists
-  if (!badgesDirCreated) {
-    fs.mkdirSync(badgesDir, { recursive: true });
-    badgesDirCreated = true;
-  }
-
-  const filename = getBadgeFilename(url);
-  const localPath = path.join(badgesDir, filename);
-  const webPath = `/badges/${filename}`;
-
-  // Check if already downloaded in a previous build
-  if (fs.existsSync(localPath)) {
-    badgeCache.set(url, webPath);
-    return webPath;
-  }
-
-  console.log(`[remark-localize-badges] Downloading: ${url}`);
-
-  try {
-    const response = await fetch(url, {
-      headers: {
-        // Some services need a user agent
-        'User-Agent': 'Mozilla/5.0 (compatible; DocusaurusBuild/1.0)',
-        Accept: 'image/svg+xml,image/*,*/*',
-      },
-      // Follow redirects
-      redirect: 'follow',
-    });
-
-    if (!response.ok) {
-      throw new Error(`HTTP ${response.status}: ${response.statusText}`);
-    }
-
-    const contentType = response.headers.get('content-type') || '';
-    const content = await response.text();
-
-    // Validate it's actually an SVG or image
-    if (
-      !contentType.includes('svg') &&
-      !contentType.includes('image') &&
-      !content.trim().startsWith('<svg') &&
-      !content.trim().startsWith('<?xml')
-    ) {
-      throw new Error(
-        `Invalid content type: ${contentType}. Expected SVG image.`,
-      );
-    }
-
-    // Write the badge to disk
-    fs.writeFileSync(localPath, content, 'utf8');
-    console.log(`[remark-localize-badges] Saved: ${filename}`);
-
-    badgeCache.set(url, webPath);
-    return webPath;
-  } catch (error) {
-    // Fail the build on badge download failure
-    throw new Error(
-      `[remark-localize-badges] Failed to download badge: ${url}\n` +
-        `Error: ${error.message}\n` +
-        `Build cannot continue with broken badges. Please fix the badge URL or remove it.`,
-    );
-  }
-}
-
-/**
- * The remark plugin factory
- */
-export default function remarkLocalizeBadges(options = {}) {
-  // __dirname equivalent for ES modules - use import.meta.url
-  const currentDir = path.dirname(new URL(import.meta.url).pathname);
-  const docsRoot = path.resolve(currentDir, '..');
-  const staticDir = options.staticDir || path.join(docsRoot, 'static');
-
-
-  return async function transformer(tree) {
-    const promises = [];
-
-    // Find all image nodes
-    visit(tree, 'image', (node) => {
-      if (isBadgeUrl(node.url)) {
-        promises.push(
-          downloadBadge(node.url, staticDir).then((localPath) => {
-            node.url = localPath;
-          }),
-        );
-      }
-    });
-
-    // Also handle HTML img tags in raw HTML or JSX
-    visit(tree, ['html', 'jsx'], (node) => {
-      if (!node.value) return;
-
-      // Find img src attributes pointing to badge URLs
-      const imgRegex = /<img[^>]+src=["']([^"']+)["'][^>]*>/gi;
-      let match;
-
-      while ((match = imgRegex.exec(node.value)) !== null) {
-        const url = match[1];
-        if (isBadgeUrl(url)) {
-          promises.push(
-            downloadBadge(url, staticDir).then((localPath) => {
-              node.value = node.value.replace(url, localPath);
-            }),
-          );
-        }
-      }
-    });
-
-    // Also handle markdown link images: [![alt](img-url)](link-url)
-    visit(tree, 'link', (node) => {
-      if (node.children) {
-        node.children.forEach((child) => {
-          if (child.type === 'image' && isBadgeUrl(child.url)) {
-            promises.push(
-              downloadBadge(child.url, staticDir).then((localPath) => {
-                child.url = localPath;
-              }),
-            );
-          }
-        });
-      }
-    });
-
-    // Wait for all downloads to complete
-    await Promise.all(promises);
-  };
-}

docs/scripts/generate-extension-components.mjs

@@ -1,676 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- *   http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-/**
- * This script scans for Storybook stories in superset-core/src and generates
- * MDX documentation pages for the developer portal. All components in
- * superset-core are considered extension-compatible by virtue of their location.
- *
- * Usage: node scripts/generate-extension-components.mjs
- */
-
-import fs from 'fs';
-import path from 'path';
-import { fileURLToPath } from 'url';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);
-const ROOT_DIR = path.resolve(__dirname, '../..');
-const DOCS_DIR = path.resolve(__dirname, '..');
-const OUTPUT_DIR = path.join(
-  DOCS_DIR,
-  'developer_portal/extensions/components'
-);
-const TYPES_OUTPUT_DIR = path.join(DOCS_DIR, 'src/types/apache-superset-core');
-const TYPES_OUTPUT_PATH = path.join(TYPES_OUTPUT_DIR, 'index.d.ts');
-const SUPERSET_CORE_DIR = path.join(
-  ROOT_DIR,
-  'superset-frontend/packages/superset-core'
-);
-
-/**
- * Find all story files in the superset-core package
- */
-async function findStoryFiles() {
-  const files = [];
-
-  // Use fs to recursively find files since glob might not be available
-  function walkDir(dir) {
-    if (!fs.existsSync(dir)) return;
-    const entries = fs.readdirSync(dir, { withFileTypes: true });
-    for (const entry of entries) {
-      const fullPath = path.join(dir, entry.name);
-      if (entry.isDirectory()) {
-        walkDir(fullPath);
-      } else if (entry.name.endsWith('.stories.tsx')) {
-        files.push(fullPath);
-      }
-    }
-  }
-
-  walkDir(path.join(SUPERSET_CORE_DIR, 'src'));
-  return files;
-}
-
-/**
- * Parse a story file and extract metadata
- *
- * All stories in superset-core are considered extension-compatible
- * by virtue of their location - no tag needed.
- */
-function parseStoryFile(filePath) {
-  const content = fs.readFileSync(filePath, 'utf-8');
-
-  // Extract component name from title
-  const titleMatch = content.match(/title:\s*['"]([^'"]+)['"]/);
-  const title = titleMatch ? titleMatch[1] : null;
-
-  // Extract component name (last part of title path)
-  const componentName = title ? title.split('/').pop() : null;
-
-  // Extract description from parameters
-  // Handle concatenated strings like: 'part1 ' + 'part2'
-  let description = '';
-
-  // First try to find the description block
-  const descBlockMatch = content.match(
-    /description:\s*{\s*component:\s*([\s\S]*?)\s*},?\s*}/
-  );
-
-  if (descBlockMatch) {
-    const descBlock = descBlockMatch[1];
-    // Extract all string literals and concatenate them
-    const stringParts = [];
-    const stringMatches = descBlock.matchAll(/['"]([^'"]*)['"]/g);
-    for (const match of stringMatches) {
-      stringParts.push(match[1]);
-    }
-    description = stringParts.join('').trim();
-  }
-
-  // Extract package info
-  const packageMatch = content.match(/package:\s*['"]([^'"]+)['"]/);
-  const packageName = packageMatch ? packageMatch[1] : '@apache-superset/core/ui';
-
-  // Extract import path - handle double-quoted strings containing single quotes
-  // Match: importPath: "import { Alert } from '@apache-superset/core';"
-  const importMatchDouble = content.match(/importPath:\s*"([^"]+)"/);
-  const importMatchSingle = content.match(/importPath:\s*'([^']+)'/);
-  let importPath = `import { ${componentName} } from '${packageName}';`;
-  if (importMatchDouble) {
-    importPath = importMatchDouble[1];
-  } else if (importMatchSingle) {
-    importPath = importMatchSingle[1];
-  }
-
-  // Get the directory containing the story to find the component
-  const storyDir = path.dirname(filePath);
-  const componentFile = path.join(storyDir, 'index.tsx');
-  const hasComponentFile = fs.existsSync(componentFile);
-
-  // Try to extract props interface from component file (for future use)
-  if (hasComponentFile) {
-    // Read component file - props extraction reserved for future enhancement
-    // const componentContent = fs.readFileSync(componentFile, 'utf-8');
-  }
-
-  // Extract story exports (named exports that aren't the default)
-  const storyExports = [];
-  const exportMatches = content.matchAll(
-    /export\s+(?:const|function)\s+(\w+)/g
-  );
-  for (const match of exportMatches) {
-    if (match[1] !== 'default') {
-      storyExports.push(match[1]);
-    }
-  }
-
-  return {
-    filePath,
-    title,
-    componentName,
-    description,
-    packageName,
-    importPath,
-    storyExports,
-    hasComponentFile,
-    relativePath: path.relative(ROOT_DIR, filePath),
-  };
-}
-
-/**
- * Extract argTypes/args from story content for generating controls
- */
-function extractArgsAndControls(content, componentName, storyContent) {
-  // Look for InteractiveX.args pattern - handle multi-line objects
-  const argsMatch = content.match(
-    new RegExp(`Interactive${componentName}\\.args\\s*=\\s*\\{([\\s\\S]*?)\\};`, 's')
-  );
-
-  // Look for argTypes
-  const argTypesMatch = content.match(
-    new RegExp(`Interactive${componentName}\\.argTypes\\s*=\\s*\\{([\\s\\S]*?)\\};`, 's')
-  );
-
-  const args = {};
-  const controls = [];
-  const propDescriptions = {};
-
-  if (argsMatch) {
-    // Parse args - handle strings, booleans, numbers
-    // Note: Using simple regex without escape handling for security (avoids ReDoS)
-    // This is sufficient for Storybook args which rarely contain escaped quotes
-    const argsContent = argsMatch[1];
-    const argLines = argsContent.matchAll(/(\w+):\s*(['"]([^'"]*)['"']|true|false|\d+)/g);
-    for (const match of argLines) {
-      const key = match[1];
-      let value = match[2];
-      // Convert string booleans
-      if (value === 'true') value = true;
-      else if (value === 'false') value = false;
-      else if (!isNaN(Number(value))) value = Number(value);
-      else if (match[3] !== undefined) value = match[3]; // Use captured string content
-      args[key] = value;
-    }
-  }
-
-  if (argTypesMatch) {
-    const argTypesContent = argTypesMatch[1];
-
-    // Match each top-level property in argTypes
-    // Pattern: propertyName: { ... }, (with balanced braces)
-    const propPattern = /(\w+):\s*\{([^{}]*(?:\{[^{}]*\}[^{}]*)*)\}/g;
-    let propMatch;
-
-    while ((propMatch = propPattern.exec(argTypesContent)) !== null) {
-      const name = propMatch[1];
-      const propContent = propMatch[2];
-
-      // Extract description if present
-      const descMatch = propContent.match(/description:\s*['"]([^'"]+)['"]/);
-      if (descMatch) {
-        propDescriptions[name] = descMatch[1];
-      }
-
-      // Skip if it's an action (not a control)
-      if (propContent.includes('action:')) continue;
-
-      // Extract label for display
-      const label = name.charAt(0).toUpperCase() + name.slice(1).replace(/([A-Z])/g, ' $1');
-
-      // Check for select control
-      if (propContent.includes("type: 'select'") || propContent.includes('type: "select"')) {
-        // Look for options - could be inline array or variable reference
-        const inlineOptionsMatch = propContent.match(/options:\s*\[([^\]]+)\]/);
-        const varOptionsMatch = propContent.match(/options:\s*(\w+)/);
-
-        let options = [];
-        if (inlineOptionsMatch) {
-          options = [...inlineOptionsMatch[1].matchAll(/['"]([^'"]+)['"]/g)].map(m => m[1]);
-        } else if (varOptionsMatch && storyContent) {
-          // Look up the variable
-          const varName = varOptionsMatch[1];
-          const varDefMatch = storyContent.match(
-            new RegExp(`const\\s+${varName}[^=]*=\\s*\\[([^\\]]+)\\]`)
-          );
-          if (varDefMatch) {
-            options = [...varDefMatch[1].matchAll(/['"]([^'"]+)['"]/g)].map(m => m[1]);
-          }
-        }
-
-        if (options.length > 0) {
-          controls.push({ name, label, type: 'select', options });
-        }
-      }
-      // Check for boolean control
-      else if (propContent.includes("type: 'boolean'") || propContent.includes('type: "boolean"')) {
-        controls.push({ name, label, type: 'boolean' });
-      }
-      // Check for text/string control (default for props in args without explicit control)
-      else if (args[name] !== undefined && typeof args[name] === 'string') {
-        controls.push({ name, label, type: 'text' });
-      }
-    }
-  }
-
-  // Add text controls for string args that don't have explicit argTypes
-  for (const [key, value] of Object.entries(args)) {
-    if (typeof value === 'string' && !controls.find(c => c.name === key)) {
-      const label = key.charAt(0).toUpperCase() + key.slice(1).replace(/([A-Z])/g, ' $1');
-      controls.push({ name: key, label, type: 'text' });
-    }
-  }
-
-  return { args, controls, propDescriptions };
-}
-
-/**
- * Generate MDX content for a component
- */
-function generateMDX(component, storyContent) {
-  const { componentName, description, importPath, packageName, relativePath } =
-    component;
-
-  // Extract args, controls, and descriptions from the story
-  const { args, controls, propDescriptions } = extractArgsAndControls(storyContent, componentName, storyContent);
-
-  // Generate the controls array for StoryWithControls
-  const controlsJson = JSON.stringify(controls, null, 2)
-    .replace(/"(\w+)":/g, '$1:')  // Remove quotes from keys
-    .replace(/"/g, "'");  // Use single quotes for strings
-
-  // Generate default props
-  const propsJson = JSON.stringify(args, null, 2)
-    .replace(/"(\w+)":/g, '$1:')
-    .replace(/"/g, "'");
-
-  // Generate a realistic live code example from the actual args
-  const liveExampleProps = Object.entries(args)
-    .map(([key, value]) => {
-      if (typeof value === 'string') return `${key}="${value}"`;
-      if (typeof value === 'boolean') return value ? key : null;
-      return `${key}={${JSON.stringify(value)}}`;
-    })
-    .filter(Boolean)
-    .join('\n      ');
-
-  // Generate props table with descriptions from argTypes
-  const propsTable = Object.entries(args).map(([key, value]) => {
-    const type = typeof value === 'boolean' ? 'boolean' : typeof value === 'string' ? 'string' : 'any';
-    const desc = propDescriptions[key] || key.charAt(0).toUpperCase() + key.slice(1).replace(/([A-Z])/g, ' $1');
-    return `| \`${key}\` | \`${type}\` | \`${JSON.stringify(value)}\` | ${desc} |`;
-  }).join('\n');
-
-  // Generate usage example props (simplified for readability)
-  const usageExampleProps = Object.entries(args)
-    .slice(0, 3) // Show first 3 props for brevity
-    .map(([key, value]) => {
-      if (typeof value === 'string') return `${key}="${value}"`;
-      if (typeof value === 'boolean') return value ? key : `${key}={false}`;
-      return `${key}={${JSON.stringify(value)}}`;
-    })
-    .join('\n      ');
-
-  return `---
-title: ${componentName}
-sidebar_label: ${componentName}
----
-
-<!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
--->
-
-import { StoryWithControls } from '../../../src/components/StorybookWrapper';
-import { ${componentName} } from '@apache-superset/core/ui';
-
-# ${componentName}
-
-${description || `The ${componentName} component from the Superset extension API.`}
-
-## Live Example
-
-<StoryWithControls
-  component={${componentName}}
-  props={${propsJson}}
-  controls={${controlsJson}}
-/>
-
-## Try It
-
-Edit the code below to experiment with the component:
-
-\`\`\`tsx live
-function Demo() {
-  return (
-    <${componentName}
-      ${liveExampleProps}
-    />
-  );
-}
-\`\`\`
-
-## Props
-
-| Prop | Type | Default | Description |
-|------|------|---------|-------------|
-${propsTable}
-
-## Usage in Extensions
-
-This component is available in the \`${packageName}\` package, which is automatically available to Superset extensions.
-
-\`\`\`tsx
-${importPath}
-
-function MyExtension() {
-  return (
-    <${componentName}
-      ${usageExampleProps}
-    />
-  );
-}
-\`\`\`
-
-## Source Links
-
-- [Story file](https://github.com/apache/superset/blob/master/${relativePath})
-- [Component source](https://github.com/apache/superset/blob/master/${relativePath.replace(/\/[^/]+\.stories\.tsx$/, '/index.tsx')})
-
----
-
-*This page was auto-generated from the component's Storybook story.*
-`;
-}
-
-/**
- * Generate index page for extension components
- */
-function generateIndexMDX(components) {
-  const componentList = components
-    .map(c => `- [${c.componentName}](./${c.componentName.toLowerCase()})`)
-    .join('\n');
-
-  return `---
-title: Extension Components
-sidebar_label: Overview
-sidebar_position: 1
----
-
-<!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
--->
-
-# Extension Components
-
-These UI components are available to Superset extension developers through the \`@apache-superset/core/ui\` package. They provide a consistent look and feel with the rest of Superset and are designed to be used in extension panels, views, and other UI elements.
-
-## Available Components
-
-${componentList}
-
-## Usage
-
-All components are exported from the \`@apache-superset/core/ui\` package:
-
-\`\`\`tsx
-import { Alert } from '@apache-superset/core/ui';
-
-export function MyExtensionPanel() {
-  return (
-    <Alert type="info">
-      Welcome to my extension!
-    </Alert>
-  );
-}
-\`\`\`
-
-## Adding New Components
-
-Components in \`@apache-superset/core/ui\` are automatically documented here. To add a new extension component:
-
-1. Add the component to \`superset-frontend/packages/superset-core/src/ui/components/\`
-2. Export it from \`superset-frontend/packages/superset-core/src/ui/components/index.ts\`
-3. Create a Storybook story with an \`Interactive\` export:
-
-\`\`\`tsx
-export default {
-  title: 'Extension Components/MyComponent',
-  component: MyComponent,
-  parameters: {
-    docs: {
-      description: {
-        component: 'Description of the component...',
-      },
-    },
-  },
-};
-
-export const InteractiveMyComponent = (args) => <MyComponent {...args} />;
-
-InteractiveMyComponent.args = {
-  variant: 'primary',
-  disabled: false,
-};
-
-InteractiveMyComponent.argTypes = {
-  variant: {
-    control: { type: 'select' },
-    options: ['primary', 'secondary'],
-  },
-  disabled: {
-    control: { type: 'boolean' },
-  },
-};
-\`\`\`
-
-4. Run \`yarn start\` in \`docs/\` - the page generates automatically!
-
-## Interactive Documentation
-
-For interactive examples with controls, visit the [Storybook](/storybook/?path=/docs/extension-components--docs).
-`;
-}
-
-/**
- * Extract type exports from a component file
- */
-function extractComponentTypes(componentPath) {
-  if (!fs.existsSync(componentPath)) {
-    return null;
-  }
-
-  const content = fs.readFileSync(componentPath, 'utf-8');
-  const types = [];
-
-  // Find all "export type X = ..." declarations
-  const typeMatches = content.matchAll(/export\s+type\s+(\w+)\s*=\s*([^;]+);/g);
-  for (const match of typeMatches) {
-    types.push({
-      name: match[1],
-      definition: match[2].trim(),
-    });
-  }
-
-  // Find all "export const X = ..." declarations (components)
-  const constMatches = content.matchAll(/export\s+const\s+(\w+)\s*[=:]/g);
-  const components = [];
-  for (const match of constMatches) {
-    components.push(match[1]);
-  }
-
-  return { types, components };
-}
-
-/**
- * Generate the type declarations file content
- */
-function generateTypeDeclarations(componentInfos) {
-  const imports = new Set();
-  const typeDeclarations = [];
-  const componentDeclarations = [];
-
-  for (const info of componentInfos) {
-    const componentDir = path.dirname(info.filePath);
-    const componentFile = path.join(componentDir, 'index.tsx');
-    const extracted = extractComponentTypes(componentFile);
-
-    if (!extracted) continue;
-
-    // Check if types reference antd or react
-    for (const type of extracted.types) {
-      if (type.definition.includes('AntdAlertProps') || type.definition.includes('AlertProps')) {
-        imports.add("import type { AlertProps as AntdAlertProps } from 'antd/es/alert';");
-      }
-      if (type.definition.includes('PropsWithChildren') || type.definition.includes('FC')) {
-        imports.add("import type { PropsWithChildren, FC } from 'react';");
-      }
-
-      // Add the type declaration
-      typeDeclarations.push(`  export type ${type.name} = ${type.definition};`);
-    }
-
-    // Add component declarations
-    for (const comp of extracted.components) {
-      const propsType = `${comp}Props`;
-      const hasPropsType = extracted.types.some(t => t.name === propsType);
-      if (hasPropsType) {
-        componentDeclarations.push(`  export const ${comp}: FC<${propsType}>;`);
-      } else {
-        componentDeclarations.push(`  export const ${comp}: FC<Record<string, unknown>>;`);
-      }
-    }
-  }
-
-  // Remove 'export' prefix for direct exports (not in declare module)
-  const cleanedTypes = typeDeclarations.map(t => t.replace(/^ {2}export /, 'export '));
-  const cleanedComponents = componentDeclarations.map(c => c.replace(/^ {2}export /, 'export '));
-
-  return `/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- *   http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-/**
- * Type declarations for @apache-superset/core/ui
- *
- * AUTO-GENERATED by scripts/generate-extension-components.mjs
- * Do not edit manually - regenerate by running: yarn generate:extension-components
- */
-${Array.from(imports).join('\n')}
-
-${cleanedTypes.join('\n')}
-
-${cleanedComponents.join('\n')}
-`;
-}
-
-/**
- * Main function
- */
-async function main() {
-  console.log('Scanning for extension-compatible stories...\n');
-
-  // Find all story files
-  const storyFiles = await findStoryFiles();
-  console.log(`Found ${storyFiles.length} story files in superset-core\n`);
-
-  // Parse each story file
-  const components = [];
-  for (const file of storyFiles) {
-    const parsed = parseStoryFile(file);
-    if (parsed) {
-      components.push(parsed);
-      console.log(`  ✓ ${parsed.componentName} (${parsed.relativePath})`);
-    }
-  }
-
-  if (components.length === 0) {
-    console.log(
-      '\nNo extension-compatible components found. Make sure stories have:'
-    );
-    console.log("  tags: ['extension-compatible']");
-    return;
-  }
-
-  console.log(`\nFound ${components.length} extension-compatible components\n`);
-
-  // Ensure output directory exists
-  if (!fs.existsSync(OUTPUT_DIR)) {
-    fs.mkdirSync(OUTPUT_DIR, { recursive: true });
-    console.log(`Created directory: ${OUTPUT_DIR}\n`);
-  }
-
-  // Generate MDX files
-  for (const component of components) {
-    // Read the story content for extracting args/controls
-    const storyContent = fs.readFileSync(component.filePath, 'utf-8');
-    const mdxContent = generateMDX(component, storyContent);
-    const outputPath = path.join(
-      OUTPUT_DIR,
-      `${component.componentName.toLowerCase()}.mdx`
-    );
-    fs.writeFileSync(outputPath, mdxContent);
-    console.log(`  Generated: ${path.relative(DOCS_DIR, outputPath)}`);
-  }
-
-  // Generate index page
-  const indexContent = generateIndexMDX(components);
-  const indexPath = path.join(OUTPUT_DIR, 'index.mdx');
-  fs.writeFileSync(indexPath, indexContent);
-  console.log(`  Generated: ${path.relative(DOCS_DIR, indexPath)}`);
-
-  // Generate type declarations
-  if (!fs.existsSync(TYPES_OUTPUT_DIR)) {
-    fs.mkdirSync(TYPES_OUTPUT_DIR, { recursive: true });
-  }
-  const typesContent = generateTypeDeclarations(components);
-  fs.writeFileSync(TYPES_OUTPUT_PATH, typesContent);
-  console.log(`  Generated: ${path.relative(DOCS_DIR, TYPES_OUTPUT_PATH)}`);
-
-  console.log('\nDone! Extension component documentation generated.');
-  console.log(
-    `\nGenerated ${components.length + 2} files (${components.length + 1} MDX + 1 type declaration)`
-  );
-}
-
-main().catch(console.error);

docs/sidebarTutorials.js

@@ -42,24 +42,32 @@ const sidebars = {
         'contributing/howtos',
         'contributing/release-process',
         'contributing/resources',
-        'guidelines/design-guidelines',
         {
           type: 'category',
-          label: 'Frontend Style Guidelines',
+          label: 'Contribution Guidelines',
           collapsed: true,
           items: [
-            'guidelines/frontend-style-guidelines',
-            'guidelines/frontend/component-style-guidelines',
-            'guidelines/frontend/emotion-styling-guidelines',
-          ],
-        },
-        {
-          type: 'category',
-          label: 'Backend Style Guidelines',
-          collapsed: true,
-          items: [
-            'guidelines/backend-style-guidelines',
-            'guidelines/backend/dao-style-guidelines',
+            'guidelines/design-guidelines',
+            {
+              type: 'category',
+              label: 'Frontend Style Guidelines',
+              collapsed: true,
+              items: [
+                'guidelines/frontend-style-guidelines',
+                'guidelines/frontend/component-style-guidelines',
+                'guidelines/frontend/emotion-styling-guidelines',
+                'guidelines/frontend/testing-guidelines',
+              ],
+            },
+            {
+              type: 'category',
+              label: 'Backend Style Guidelines',
+              collapsed: true,
+              items: [
+                'guidelines/backend-style-guidelines',
+                'guidelines/backend/dao-style-guidelines',
+              ],
+            },
           ],
         },
       ],
@@ -72,31 +80,13 @@ const sidebars = {
         'extensions/overview',
         'extensions/quick-start',
         'extensions/architecture',
-        'extensions/contribution-types',
-        {
-          type: 'category',
-          label: 'Components',
-          collapsed: true,
-          items: [
-            {
-              type: 'autogenerated',
-              dirName: 'extensions/components',
-            },
-          ],
-        },
-        {
-          type: 'category',
-          label: 'Extension Points',
-          collapsed: true,
-          items: [
-            'extensions/extension-points/sqllab',
-          ],
-        },
-        'extensions/development',
-        'extensions/deployment',
-        'extensions/mcp',
-        'extensions/security',
-        'extensions/registry',
+        'extensions/extension-project-structure',
+        'extensions/extension-metadata',
+        'extensions/frontend-contribution-types',
+        'extensions/interacting-with-host',
+        'extensions/deploying-extension',
+        'extensions/development-mode',
+        'extensions/security-implications',
       ],
     },
     {
@@ -105,7 +95,6 @@ const sidebars = {
       collapsed: true,
       items: [
         'testing/overview',
-        'testing/testing-guidelines',
         'testing/frontend-testing',
         'testing/backend-testing',
         'testing/e2e-testing',

docs/src/theme/ReactLiveScope/index.tsx

@@ -1,53 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- *   http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-import React from 'react';
-import { Button, Card, Input, Space, Tag, Tooltip } from 'antd';
-
-// Import extension components from @apache-superset/core/ui
-// This matches the established pattern used throughout the Superset codebase
-// Resolved via webpack alias to superset-frontend/packages/superset-core/src/ui/components
-import { Alert } from '@apache-superset/core/ui';
-
-/**
- * ReactLiveScope provides the scope for live code blocks.
- * Any component added here will be available in ```tsx live blocks.
- *
- * To add more components:
- * 1. Import the component from @apache-superset/core above
- * 2. Add it to the scope object below
- */
-const ReactLiveScope = {
-  // React core
-  React,
-  ...React,
-
-  // Extension components from @apache-superset/core
-  Alert,
-
-  // Common Ant Design components (for demos)
-  Button,
-  Card,
-  Input,
-  Space,
-  Tag,
-  Tooltip,
-};
-
-export default ReactLiveScope;

docs/src/types/apache-superset-core/index.d.ts

@@ -1,31 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- *   http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-/**
- * Type declarations for @apache-superset/core/ui
- *
- * AUTO-GENERATED by scripts/generate-extension-components.mjs
- * Do not edit manually - regenerate by running: yarn generate:extension-components
- */
-import type { AlertProps as AntdAlertProps } from 'antd/es/alert';
-import type { PropsWithChildren, FC } from 'react';
-
-export type AlertProps = PropsWithChildren<Omit<AntdAlertProps, 'children'>>;
-
-export const Alert: FC<AlertProps>;

docs/src/webpack.extend.ts

@@ -51,15 +51,6 @@ export default function webpackExtendPlugin(): Plugin<void> {
               __dirname,
               '../../superset-frontend/packages/superset-ui-core/src/components',
             ),
-            // Extension API package - allows docs to import from @apache-superset/core/ui
-            // This matches the established pattern used throughout the Superset codebase
-            // Point directly to components to avoid importing theme (which has font dependencies)
-            // Note: TypeScript types come from docs/src/types/apache-superset-core (see tsconfig.json)
-            // This split is intentional: webpack resolves actual source, tsconfig provides simplified types
-            '@apache-superset/core/ui': path.resolve(
-              __dirname,
-              '../../superset-frontend/packages/superset-core/src/ui/components',
-            ),
             // Add proper Storybook aliases
             '@storybook/blocks': path.resolve(
               __dirname,

docs/tsconfig.json

@@ -6,23 +6,19 @@
     "skipLibCheck": true,
     "noImplicitAny": false,
     "strict": false,
-    "jsx": "react-jsx",
-    "moduleResolution": "node",
-    "types": ["@docusaurus/module-type-aliases"],
-    "paths": {
-      "@superset-ui/core": ["../superset-frontend/packages/superset-ui-core/src"],
-      "@superset-ui/core/*": ["../superset-frontend/packages/superset-ui-core/src/*"],
-      // Types for @apache-superset/core/ui are auto-generated by scripts/generate-extension-components.mjs
-      // Runtime resolution uses webpack alias pointing to actual source (see src/webpack.extend.ts)
-      // Using /ui path matches the established pattern used throughout the Superset codebase
-      "@apache-superset/core/ui": ["./src/types/apache-superset-core"],
-      "*": ["src/*", "node_modules/*"]
-    }
+    "types": ["@docusaurus/module-type-aliases"]
+  },
+  "jsx": "react-jsx",
+  "moduleResolution": "node",
+  "baseUrl": "./",
+  "paths": {
+    "@superset-ui/core": ["../superset-frontend/packages/superset-ui-core/src"],
+    "@superset-ui/core/*": ["../superset-frontend/packages/superset-ui-core/src/*"],
+    "*": ["src/*", "node_modules/*"]
   },
   "include": [
     "src/**/*.ts",
-    "src/**/*.tsx",
-    "src/**/*.d.ts"
+    "src/**/*.tsx"
   ],
   "exclude": [
     "node_modules",

docs/versioned_docs/version-6.0.0/configuration/sql-templating.mdx

@@ -17,8 +17,8 @@ made available in the Jinja context:
 
 - `columns`: columns which to group by in the query
 - `filter`: filters applied in the query
-- `from_dttm`: start `datetime` value from the selected time range (`None` if undefined). **Note:** Only available in virtual datasets when a time range filter is applied in Explore/Chart views—not available in standalone SQL Lab queries. (deprecated beginning in version 5.0, use `get_time_filter` instead)
-- `to_dttm`: end `datetime` value from the selected time range (`None` if undefined). **Note:** Only available in virtual datasets when a time range filter is applied in Explore/Chart views—not available in standalone SQL Lab queries. (deprecated beginning in version 5.0, use `get_time_filter` instead)
+- `from_dttm`: start `datetime` value from the selected time range (`None` if undefined) (deprecated beginning in version 5.0, use `get_time_filter` instead)
+- `to_dttm`: end `datetime` value from the selected time range (`None` if undefined). (deprecated beginning in version 5.0, use `get_time_filter` instead)
 - `groupby`: columns which to group by in the query (deprecated)
 - `metrics`: aggregate expressions in the query
 - `row_limit`: row limit of the query
@@ -58,54 +58,6 @@ the time filter is not set. For many database engines, this could be replaced wi
 Note that the Jinja parameters are called within _double_ brackets in the query and with
 _single_ brackets in the logic blocks.
 
-### Understanding Context Availability
-
-Some Jinja variables like `from_dttm`, `to_dttm`, and `filter` are **only available when a chart or dashboard provides them**. They are populated from:
-
-- Time range filters applied in Explore/Chart views
-- Dashboard native filters
-- Filter components
-
-**These variables are NOT available in standalone SQL Lab queries** because there's no filter context. If you try to use `{{ from_dttm }}` directly in SQL Lab, you'll get an "undefined parameter" error.
-
-#### Testing Time-Filtered Queries in SQL Lab
-
-To test queries that use time variables in SQL Lab, you have several options:
-
-**Option 1: Use Jinja defaults (recommended)**
-
-```sql
-SELECT *
-FROM tbl
-WHERE dttm_col > '{{ from_dttm | default("2024-01-01", true) }}'
-  AND dttm_col < '{{ to_dttm | default("2024-12-31", true) }}'
-```
-
-**Option 2: Use SQL Lab Parameters**
-
-Set parameters in the SQL Lab UI (Parameters menu):
-```json
-{
-  "from_dttm": "2024-01-01",
-  "to_dttm": "2024-12-31"
-}
-```
-
-**Option 3: Use `{% set %}` for testing**
-
-```sql
-{% set from_dttm = "2024-01-01" %}
-{% set to_dttm = "2024-12-31" %}
-SELECT *
-FROM tbl
-WHERE dttm_col > '{{ from_dttm }}' AND dttm_col < '{{ to_dttm }}'
-```
-
-:::tip
-When you save a SQL Lab query as a virtual dataset and use it in a chart with time filters,
-the actual filter values will override any defaults or test values you set.
-:::
-
 To add custom functionality to the Jinja context, you need to overload the default Jinja
 context in your environment by defining the `JINJA_CONTEXT_ADDONS` in your superset configuration
 (`superset_config.py`). Objects referenced in this dictionary are made available for users to use

docs/versioned_docs/version-6.0.0/configuration/theming.mdx

@@ -110,30 +110,18 @@ To export a theme for use in configuration files or another instance:
 
 ## Custom Fonts
 
-Superset supports custom fonts through the theme configuration, allowing you to use branded or custom typefaces without rebuilding the application.
-
-### Default Fonts
-
-By default, Superset uses Inter and Fira Code fonts which are bundled with the application via `@fontsource` packages. These fonts work offline and require no external network calls.
+Superset supports custom fonts through runtime configuration, allowing you to use branded or custom typefaces without rebuilding the application.
 
 ### Configuring Custom Fonts
 
-To use custom fonts, add font URLs to your theme configuration using the `fontUrls` token:
+Add font URLs to your `superset_config.py`:
 
 ```python
-THEME_DEFAULT = {
-    "token": {
-        # Load fonts from external sources (e.g., Google Fonts, Adobe Fonts)
-        "fontUrls": [
-            "https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;600;700&display=swap",
-            "https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500&display=swap",
-        ],
-        # Reference the loaded fonts
-        "fontFamily": "Roboto, -apple-system, BlinkMacSystemFont, sans-serif",
-        "fontFamilyCode": "JetBrains Mono, Monaco, monospace",
-        # ... other theme tokens
-    }
-}
+# Load fonts from Google Fonts, Adobe Fonts, or self-hosted sources
+CUSTOM_FONT_URLS = [
+    "https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap",
+    "https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500&display=swap",
+]
 
 # Update CSP to allow font sources
 TALISMAN_CONFIG = {
@@ -144,24 +132,31 @@ TALISMAN_CONFIG = {
 }
 ```
 
+### Using Custom Fonts in Themes
+
+Once configured, reference the fonts in your theme configuration:
+
+```python
+THEME_DEFAULT = {
+    "token": {
+        "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
+        "fontFamilyCode": "JetBrains Mono, Monaco, monospace",
+        # ... other theme tokens
+    }
+}
+```
+
 Or in the CRUD interface theme JSON:
 
 ```json
 {
   "token": {
-    "fontUrls": [
-      "https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;600;700&display=swap"
-    ],
-    "fontFamily": "Roboto, -apple-system, BlinkMacSystemFont, sans-serif",
+    "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
     "fontFamilyCode": "JetBrains Mono, Monaco, monospace"
   }
 }
 ```
 
-:::note
-Font URLs are validated against a configurable allowlist. By default, fonts from `fonts.googleapis.com`, `fonts.gstatic.com`, and `use.typekit.net` are allowed. Configure `THEME_FONT_URL_ALLOWED_DOMAINS` to customize the allowed domains.
-:::
-
 ### Font Sources
 
 - **Google Fonts**: Free, CDN-hosted fonts with wide variety