mirror of
https://github.com/multica-ai/multica.git
synced 2026-06-17 03:38:32 +02:00
6330286c7e
* fix(lark): use named import for react-qr-code to survive electron-vite interop
Clicking Bind on the agent detail page white-screened the desktop app at
the QR step:
Element type is invalid: expected a string or a class/function but got:
object. Check the render method of `LarkInstallDialog`.
react-qr-code is a CJS package. `import QRCode from "react-qr-code"`
relies on the bundler's __esModule default-interop to unwrap `.default`.
Next.js (web) unwraps it correctly; electron-vite's dep-optimizer handed
back the whole module namespace object `{ default, QRCode, __esModule }`
instead of the component, so React got an object where it expected a
component the moment <QRCode> mounted — desktop-only white screen, web
unaffected.
Switch to the named import `{ QRCode }`, which maps straight to
`exports.QRCode` and doesn't depend on the flaky default-interop path.
Resolves correctly under both bundlers; the package's own .d.ts exports
both the named class and the default, so it typechecks unchanged.
Not a backend / Lark-config issue — purely a frontend CJS interop bug.
* test(lark): expose named QRCode export in react-qr-code mock
Follow-up to the named-import switch in lark-tab. The test stubbed
react-qr-code with only a `default` export; now that the component
imports `{ QRCode }`, the named binding resolved to undefined and the
3 QR-rendering tests failed with "No QRCode export is defined on the
react-qr-code mock". Return the stub as both `QRCode` and `default`,
defined inside the factory (vi.mock is hoisted above top-level vars).