michael-s-molina commented on issue #33441:
URL: https://github.com/apache/superset/issues/33441#issuecomment-2897999639
Thank you for the discussion and additional research @mistercrunch. Writing
our thoughts might be helpful to get to the best solution. In order for me to
understand your proposal, I'll add some details and ask some questions. I'll
start with what was the model that we were thinking in the extensions project
and try to understand how that would change with your proposal.
Our initial thinking was that we would have separate packages for public,
private, and SDKs:
- `@apache-superset/primitives` would contain the shared
components/functions that are public, or in other words, that can be used by
extensions and need to be versioned. One example here would be the `Button`
component.
- `@apache-superset/extensions-sdk` would contain functions that are used to
build, bundle, and publish extensions to Superset. It would also contain a
testing framework to help unit test extensions without the host application.
- Private functions and components like the ones you mentioned would not be
included in `@apache-superset/primitives` and would reside in another package
inside Superset.
An extension would have a production dependency on
`@apache-superset/primitives`:
```
import { Button } from '@apache-superset/primitives';
```
and a dev-dependency (not production) on `@apache-superset/extensions-sdk`
to run the following commands:
```
superset-sdk build
superset-sdk bundle
superset-sdk test
...
```
Superset would also have a dependency on `@apache-superset/primitives`, no
dependency on the SDK, and follow the same pattern as extensions:
```
import { Button } from '@apache-superset/primitives';
```
If any other project would like to use the components available in
`@apache-superset/primitives`, they could just add them as a dependency. One
example, would be a host application that embeds Superset and wants to use the
same button styles in the host part to match the design.
Now, I'll try to port these abstractions to your proposal to see if I'm
understanding correctly. Only assumptions and questions from now on 😄
1. When you say that the SDKs should be gate keepers for the public parts,
do both packages exist? If yes, how that would work?
```
@apache-superset/extensions-sdk
@apache-superset/primitives
```
Or is the primitives package a sub-folder of the SDK? Or something else?
```
@apache-superset/extensions-sdk
- primitives (sub-folder)
```
2. If it's the sub-folder approach, how does Superset import the primitives?
I'm assuming we don't want something like
```
import { Button } from '@apache-superset/extension-sdk';
```
in the host application, only in extensions.
3. How do we reuse the primitives with other SDKs and applications?
4. Are you thinking of a layer of abstraction like `Button` interfaces that
belong in the SDK but the implementation is in a private part?
--
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]
