michael-s-molina commented on issue #33441: URL: https://github.com/apache/superset/issues/33441#issuecomment-2930665900
Hi @mistercrunch. We have been discussing this actively in the context of extensions. We analyzed the following platforms to understand how they deal with package organization in the context of extensions: SDK/Ecosystem | Description -- | -- Android | Official toolkit for building Android apps, including APIs, UI widgets, tools, and emulators. Shopify | Tools and APIs for building Shopify apps and extensions. Firebase | APIs and tools for integrating Firebase services (auth, database, etc.) into apps. Stripe | APIs for payment processing. Microsoft Graph | APIs and types for accessing Microsoft Graph (Office 365, Azure AD, etc.). Twilio | APIs for SMS, voice, and other communications. Slack | APIs and types for building Slack apps and bots. VS Code Extensions | APIs for building VS Code extensions. Atlassian Forge | SDK for building Jira/Confluence cloud apps. Figma | APIs and types for building Figma plugins. Notion | APIs for integrating with Notion. Key Takeaways: - The term “SDK” is often used to describe the overall toolkit or collection of resources for development, not necessarily a single package. - Many platforms split their SDK into multiple focused packages (e.g., APIs, types, UI, CLI), rather than bundling everything into a single <tool>-sdk package. - Sometimes there is a package named <tool>-sdk, but it usually serves as an entry point or meta-package, while the actual functionality is distributed across several specialized packages. One example of a meta package is the [Firebase](https://www.npmjs.com/package/firebase) package which has the following `package.json`: ``` "dependencies": { "@firebase/ai": "1.3.0", "@firebase/app": "0.13.0", "@firebase/app-compat": "0.4.0", "@firebase/app-types": "0.9.3", "@firebase/auth": "1.10.6", "@firebase/auth-compat": "0.5.26", "@firebase/data-connect": "0.3.9", "@firebase/database": "1.0.19", "@firebase/database-compat": "2.0.10", "@firebase/firestore": "4.7.16", "@firebase/firestore-compat": "0.3.51", "@firebase/functions": "0.12.8", "@firebase/functions-compat": "0.3.25", "@firebase/installations": "0.6.17", "@firebase/installations-compat": "0.2.17", "@firebase/messaging": "0.12.21", "@firebase/messaging-compat": "0.2.21", "@firebase/storage": "0.13.12", "@firebase/storage-compat": "0.3.22", "@firebase/performance": "0.7.6", "@firebase/performance-compat": "0.2.19", "@firebase/remote-config": "0.6.4", "@firebase/remote-config-compat": "0.2.17", "@firebase/analytics": "0.10.16", "@firebase/analytics-compat": "0.2.22", "@firebase/app-check": "0.10.0", "@firebase/app-check-compat": "0.3.25", "@firebase/util": "1.12.0" }, ``` In the extensions project, we currently have `@apache-superset/core` as the only frontend dependency for extensions. We might have another one called `@apache-superset/extensions-testing` in the future as an optional development dependency. @villebro pointed out that the meta package is a valid approach but will be an overkill for a single dependency. We opted for not creating a meta package initially given the small number of dependencies we have. At the same time, if the number of dependencies increase due to new features or refactoring of the core package, we'll create a meta package similar to what Firebase does. We took your images above and created a proposal for keeping this SIP aligned with the extensions work. <img width="916" alt="Image" src="https://github.com/user-attachments/assets/480a3039-999c-42c7-a3b8-2aa9f854ba10"; /> The only differences are: - We consider plugins as extensions. They will be a specific contribution type. - Both built-in and external extensions depend on the @apache-superset/core package. I believe the rest is similar to your suggestion. @villebro Let us know if I missed anything from our discussion. -- 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]
