michael-s-molina commented on PR #36498:
URL: https://github.com/apache/superset/pull/36498#issuecomment-3657204368
## Potential Issues
### 1. Script Comment Mismatch
**File**: `docs/scripts/generate-extension-components.mjs:21-22`
The comment says:
```js
* This script scans for Storybook stories tagged with 'extension-compatible'
```
But the implementation doesn't actually check for tags - it processes ALL
stories in `superset-core/src`. The comment at lines 72-74 correctly notes
this, but the file header comment at line 21 is misleading.
### 2. Hardcoded "Sample alert message" in Generated MDX
**File**: `docs/scripts/generate-extension-components.mjs:304-305`
The generated component always renders:
```jsx
<${componentName}...>
Sample alert message
</${componentName}>
```
This is hardcoded and specific to Alert. For other components that don't
accept children or use children differently, this would be incorrect.
### 3. MDX Generation Assumes Alert-like Component Structure
**File**: `docs/scripts/generate-extension-components.mjs:318-319`
The generated "Try It" section always uses:
```jsx
<${componentName} type="info">
```
This assumes all components have a `type` prop, which is Alert-specific.
Future components may not have this prop.
### 4. Alias Mismatch Between Webpack and TypeScript
**Files**:
- `docs/src/webpack.extend.ts:56-59`: Points to
`.../superset-core/src/ui/components`
- `docs/tsconfig.json:15`: Points to `./src/types/apache-superset-core`
While this works because webpack handles runtime and tsconfig handles
IDE/typecheck, the inconsistency could cause confusion. At runtime, `Alert` is
resolved from the full components directory, but types come from the generated
`.d.ts` file.
### 5. Inconsistent Import Path for Alert Component
**Files**:
- `docs/src/theme/ReactLiveScope/index.tsx:25`: `import { Alert } from
'@apache-superset/core';`
- `docs/developer_portal/extensions/components/alert.mdx:26,107`: Same import
- `docs/scripts/generate-extension-components.mjs:291,407`: Generates same
import
But the existing codebase pattern uses `@apache-superset/core/ui`:
-
`superset-frontend/src/SqlLab/components/EstimateQueryCostButton/index.tsx:22`:
`import { css, styled, Alert } from '@apache-superset/core/ui';`
- `superset-frontend/src/SqlLab/components/SouthPane/Results.tsx:23`:
`import { styled, Alert } from '@apache-superset/core/ui';`
- And many other files...
**The issue**: The docs use a webpack alias that points
`@apache-superset/core` directly to `ui/components`, which makes the import
work in docs but is **misleading for extension developers**. In a real
extension environment:
- `import { Alert } from '@apache-superset/core'` - works (via re-export
chain)
- `import { Alert } from '@apache-superset/core/ui'` - also works and is the
existing pattern
The documentation should be consistent with the established codebase
patterns. Either:
1. Update docs to use `@apache-superset/core/ui` (matches existing codebase)
2. Or explicitly document that both paths work and which is preferred
### 6. Components Section Positioned at End of Sidebar
**File**: `docs/sidebarTutorials.js:97-108`
The Components section is currently the last item in the Extensions sidebar
(lines 97-108), appearing after Registry, Security, MCP, Deployment, and
Development. This makes it feel like an afterthought when components are
actually foundational building blocks.
**Current order:**
1. Overview
2. Quick Start
3. Architecture
4. Contribution Types
5. Extension Points
6. Development
7. Deployment
8. MCP
9. Security
10. Registry
11. Components ← Currently here
**Recommended order:**
Place Components after Contribution Types (position 5) to follow the logical
learning path: understand what's available (contribution types, components) →
then learn where to use them (extension points) → then how to build
(development).
**Suggested order:**
1. Overview
2. Quick Start
3. Architecture
4. Contribution Types
5. **Components** ← Move here
6. Extension Points
7. Development
8. Deployment
9. MCP
10. Security
11. Registry
This positions Components as part of the "learning the toolkit" phase before
developers dive into implementation details.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
