feat(data): zero-config dev auth for GraphQLResolver via everywhere view

[mackenziemcclaskey]

Summary

• Renamed TridentResolver to GraphQLResolver — same interface, cleaner name that reflects what it actually does
• GraphQLResolver accepts an optional endpoint argument; when omitted it defaults to /api/data/graphql on the current origin (safe in both browser and Node/SSR environments)
• everywhere view now proxies /api/data/graphql to the real API server and injects the stored bearer token only when the incoming request carries no existing auth (no Authorization header and no we_session cookie) — so the WE-NEXT shell's session is respected and never overwritten
• --mock-data flag default flipped to false — real API is used by default when credentials are present; mock mode is opt-in
• Removed the old /_we/trident proxy middleware
• README updated to reference GraphQLResolver throughout and document auth login as step 1 of the data connection flow
• Fixed cli/package.json name field (@workday/wdcli-plugin-everywhere → @workday/everywhere) so npx @workday/everywhere init resolves correctly — oclif was failing to find the plugin because the name didn't match what's installed

Test plan

• just test — all 306 tests pass
• just check — typecheck + lint clean
• everywhere auth login, then everywhere view in a plugin directory — confirm requests reach the real GraphQL endpoint with the bearer token injected
• With an active WE-NEXT shell session (we_session cookie present), confirm the stored token is NOT injected (existing auth is preserved)
• Confirm no Authorization header is sent when no token is configured
• npx @workday/everywhere init — confirm the command resolves without "command everywhere:init not found"

🤖 Generated with Claude Code

[jheddings]

Posting the critical findings from a thorough review here as inline comments. There are also several non-blocking concerns and suggestions (e.g. PR description vs. implementation drift, mock-data default, import type consistency, globalThis.window test teardown, window.location.origin baked at construction, missing integration test for the proxy hook) — happy to follow up with those separately if useful.

[jheddings]

This beforeEach overwrites globalThis.window for every test in the file, but there's no matching afterEach to restore it. Vitest doesn't isolate global-object mutations across files in the same worker by default, so if any later test file relies on happy-dom's real window, behavior becomes order-dependent.

Small fix using vitest's stub helpers:

beforeEach(() => {
  vi.stubGlobal('window', { location: { origin: 'https://tenant.workday.com' } });
});
afterEach(() => {
  vi.unstubAllGlobals();
});

or stash and restore the original explicitly.

[mpfilbin]

Alternatively, we could drop the explicit dependency on the window global in the TridentResolver class and accept host as a constructor argument instead. This way, you don't have to worry about managing state in the tests, making them less brittle.

[mpfilbin]

Alternatively, we could drop the explicit dependency on the window global in the TridentResolver class and accept host as a constructor argument instead. This way, you don't have to worry about managing state in the tests, making them less brittle.

[jheddings]

Concern — browser-only assumption baked at construction. window.location.origin is referenced unconditionally in the constructor, so:

• Importing/instantiating this class in any non-DOM context (Node test runner without happy-dom, SSR, a Worker without location, a build-time codegen step) throws ReferenceError: window is not defined before the caller can do anything about it.
• The endpoint is frozen at construction. A consumer that wants to point at a different gateway in production (different region, multi-tenant routing, an embedded sandbox) has no escape hatch — the README/PR description claim TridentResolverOptions provides one, but it doesn't exist.

Accepting an optional endpoint (or host) on the constructor — defaulting to globalThis.window?.location.origin + '/api/data/graphql' resolved lazily inside execute() — would address both, and dovetails with @mpfilbin's suggestion on the test file.

[mackenziemcclaskey]

BUG FIX: This was previously "@workday/wdcli-plugin-everywhere" (a legacy internal identity). oclif resolves command IDs by searching node_modules for the plugin name at runtime. Because only "@workday/everywhere" is installed, every command lookup failed with "command everywhere:X not found". Correcting the name here also removes spurious hidden flags from all user facing commands in the regenerated manifest.