amaannawab923 commented on code in PR #45522:
URL: https://github.com/apache/superset/pull/45522#discussion_r4401416726
##########
superset-extensions-cli/src/superset_extensions_cli/templates/frontend/webpack.config.js.j2:
##########
@@ -61,6 +61,15 @@ module.exports = (env, argv) => {
singleton: true,
import: false,
},
+ // Declared here as well as by the host, because Module Federation
+ // only consumes the share scope for modules the remote itself
+ // declares as shared. Without this the extension bundles its own
+ // copy, whose SupersetClient is never configured -- so every call
+ // through it goes out without a CSRF token.
+ "@superset-ui/core": {
+ singleton: true,
+ import: false,
+ },
Review Comment:
This resolves the other way in f4a38f7: the scaffold stops mentioning
`@superset-ui/core` rather than starting to declare it.
The share is dropped (see the webpack.config.js thread), so there is no
runtime instruction left for a `package.json` entry to match, and nothing for
`ts-loader` to fail to resolve. Extensions reach Superset's API through the new
`http` namespace on `@apache-superset/core`, which they already declare.
The documentation half was fixed earlier in 37caec2c -- three places told
authors to write an import that could not compile, because a `shared` entry is
runtime-only and `tsc` never sees it. Those now say so, and the share lists in
`architecture.md` and `quick-start.md` are correct again.
What is left on this thread is only the release task:
`@apache-superset/core` has to be published with the `http` namespace in it
before a scaffolded extension can resolve the import from npm rather than from
a local build. That is a version bump and a manual publish, not a code change,
so I will track it separately rather than hold this thread open for it.
--
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]