Plugin SDK: unexported apiFetch helpers, non-workspace devDependency, and missing files field

[antoninbas]

Three small, independent problems in the plugin SDK / components packaging. All verified against main as of today. None of them are on fire, but each has a cheap fix.

1. apiFetch / apiFetchJSON are documented but not exported

Both the SDK doc comment and the plugin docs tell plugin authors to use these:

client/web/antrea-ui-plugin-sdk/src/index.ts:41

so use apiFetch()/apiFetchJSON() from @antrea/ui-components and add nothing of your own.

docs/plugins.md:89

(apiFetch/apiFetchJSON from @antrea/ui-components do this for you, along with turning a non-2xx response into an APIError, if you would rather not hand-roll it.)

But the public entry point doesn't export them — client/web/antrea-ui-components/src/index.ts:37:

export { APIError, setApiBase, getApiBase } from './lib/api.js';

apiFetch and apiFetchJSON are defined in src/lib/api.ts (lines 62 and 93) but never re-exported, and the exports map in antrea-ui-components/package.json only exposes "." and "./src/tokens.css", so the deep path is blocked too. A plugin author following the docs gets TS2305: Module '"@antrea/ui-components"' has no exported member 'apiFetch'.

Note the SDK comment is also copied verbatim into the emitted dist/index.d.ts, so it ships to consumers.

Fix: either add apiFetch, apiFetchJSON to the re-export on line 37, or reword both doc references. This is the only one of the three that affects anyone writing a plugin today.

2. SDK's devDependency on @antrea/ui-components doesn't use the workspace protocol

client/web/antrea-ui-plugin-sdk/package.json:

  "devDependencies": {
    "@antrea/ui-components": "0.1.0",
    "typescript": "^6.0.0"
  }

The app uses "@antrea/ui-components": "workspace:*"; the SDK uses a bare version. Today that still resolves to the local workspace, but only because the versions happen to match — visible in client/web/yarn.lock, where the npm descriptor got folded in with the workspace ones:

"@antrea/ui-components@npm:0.1.0, @antrea/ui-components@workspace:*, @antrea/ui-components@workspace:antrea-ui-components":
  version: 0.0.0-use.local
  resolution: "@antrea/ui-components@workspace:antrea-ui-components"

The moment antrea-ui-components' version changes (to 0.1.1, 0.2.0, anything), Yarn stops matching the workspace for the npm:0.1.0 descriptor and falls back to the public registry, where the package doesn't exist. yarn install --immutable then fails with YN0035: Package not found / HTTP 404 — which is every CI job in node.yml and kind_e2e.yml.

The version has never been bumped since the workspaces were created, so this hasn't fired yet. It's a landmine rather than an active bug, but the failure mode is confusing enough (a 404 on an internal package) to be worth defusing now.

Fix: "@antrea/ui-components": "workspace:^".

3. yarn npm publish would ship the SDK without its type declarations

client/web/antrea-ui-plugin-sdk has no files field and no .npmignore, and its .gitignore contains dist/. Yarn's packer applies .gitignore when there's no .npmignore, and force-includes only the main/module/browser/bin targets — types and exports are not on that list.

Result (yarn workspace @antrea/ui-plugin-sdk pack --dry-run):

dist/index.js
package.json
src/index.ts
tsconfig.json

dist/index.d.ts is missing, so the published package would have no types. (npm's own packer behaves differently and does include it, so this only shows up on the Yarn publish path — which is the likely one, given packageManager: yarn@4.18.0.)

Nothing currently guarantees dist/ is built or fresh at publish time either, so an unbuilt tree would publish with no dist/ at all.

Fix: add "files": ["dist"], plus a prepack (or prepublishOnly) that runs tsc. Only matters once the SDK is actually published, so this can wait for the pre-release pass — but it's a one-line change.

---

Filing together since they're all in the same corner of the tree; happy to split if you'd rather track them separately.