@salesforce/webapp-template-app-react-sample-b2e-experimental 1.61.3 → 1.61.4

package/dist/.a4drules/react.md

@@ -1,388 +0,0 @@
-# AI Customization Rule: React Web App (SFDX)
-
-This rule consolidates React web application guidelines, data access rules, security standards, anti-patterns, and project integration requirements for consistent AI-generated code.
-
-## Targets (File Pattern Matching)
-
-Apply these rules to the React web app files under the SFDX package directory:
-
-- `force-app/main/default/webapplications/*/**/*.js`
-- `force-app/main/default/webapplications/*/**/*.jsx`
-- `force-app/main/default/webapplications/*/**/*.ts`
-- `force-app/main/default/webapplications/*/**/*.tsx`
-
-## Rule Objectives
-
-- Enforce secure, performant, and maintainable patterns for Salesforce data access.
-- Standardize UI with shadcn/ui and Tailwind.
-- Prevent prohibited patterns that break React or Salesforce constraints.
-
-## UI / layout edits (MANDATORY — read before any UI change)
-
-**When the user asks for UI changes** (new components, pages, navigation, header, footer, sidebar, theme, or “layout”):  
-**You MUST open and update `src/appLayout.tsx`** (the theme layout) whenever the change affects how the app shell looks or behaves.  
-Do not only edit pages or components and leave `appLayout.tsx` unchanged.  
-If in doubt, **edit appLayout.tsx as well**.  
-The layout file is: `force-app/main/default/webapplications/<appName>/src/appLayout.tsx` (or the app’s `appLayout.tsx` used by `routes.tsx`).
-
-**Navigation menu and placeholder name/design:** In `appLayout.tsx`, always replace the **default navigation menu** (items and labels) with app-specific links and names, and replace the **placeholder app name** (header, nav brand, footer) and **placeholder design** with the actual app name and intentional styling. Do not leave template nav or "React App"–style branding. See **webapp-nav-and-placeholders.md**.
-
-## Project & Entry Points
-
-- React web app root: `force-app/main/default/webapplications/<appName>/`
-- Main entry component: `force-app/main/default/webapplications/<appName>/src/App.tsx`
-- **Theme/layout shell**: `force-app/main/default/webapplications/<appName>/src/appLayout.tsx` — wraps all routed content (navigation, header, sidebar, outlet). Routes use `<AppLayout />` as the layout element; page content renders inside it via `<Outlet />`. When making UI edits that affect global layout, navigation, header, footer, sidebar, or theme, **you must consider and edit appLayout.tsx** in addition to page or component files; do not only edit individual pages and omit the layout.
-- Running Development Server (from the web app directory):
-  - `npm run dev` — starts the Vite dev server
-  - You can generally assume the dev server is already running and don't need to start it.
-- Build (from the web app directory):
-  - `npm run build` — TypeScript check + Vite build
-- Deploy and open in Salesforce are done from the **SFDX project root** (e.g. via Salesforce CLI or the IDE), not via the web app's package.json. Keep the app buildable so deploy workflows continue to work.
-
-## Component Library (MANDATORY)
-
-- Use shadcn/ui for UI components (Buttons, Cards, Inputs, Dialogs, etc.).
-- Import patterns:
-
-```javascript
-import { Button } from '@/components/ui/button';
-import { Card, CardHeader, CardContent } from '@/components/ui/card';
-import { Input } from '@/components/ui/input';
-```
-
-## Styling Standards
-
-- Use Tailwind CSS utility classes.
-- Follow consistent spacing, color, and typography conventions.
-
-## React & TypeScript Standards
-
-- Component Architecture: Prefer functional components with hooks.
-- File Naming: Use PascalCase for components (e.g., `Button.tsx`) and camelCase for hooks (e.g., `useAuth.ts`).
-- Imports: Use absolute paths (e.g., `@/components/...`) if the `tsconfig.json` or `vite.config.ts` supports it.
-- State: Default to `useState` for local state; avoid adding global state libraries unless requested.
-
-## Layout and theme (appLayout.tsx) — CRITICAL for UI edits
-
-- **appLayout.tsx** is the application shell: it wraps every page and typically contains the main navigation (e.g. `NavigationMenu`), header, sidebar, and `<Outlet />` for child routes. It defines the global look and structure of the app.
-- **MANDATORY:** When asked to change the UI in ways that affect the **overall layout**, **navigation**, **header**, **footer**, **sidebar**, or **theme** (e.g. add a top bar, change nav items, add a sidebar, apply a theme wrapper), you **MUST** edit `appLayout.tsx` (or the app’s layout file) as part of the same change. Do not only edit individual pages or components and leave the layout unchanged.
-- **Before finishing any UI edit:** Ask yourself: “Does this touch layout, nav, header, footer, sidebar, or theme?” If yes, **you must have modified appLayout.tsx** (or the layout file used by routes). If you did not, add that edit before considering the task done.
-- If the project uses feature inheritance (e.g. `__inherit__appLayout`), the editable layout may live in the app or feature at `src/appLayout.tsx`; ensure you modify the correct file that is actually used by `routes.tsx`.
-
-## Module & Platform Restrictions
-
-- React apps must NOT import or rely on Salesforce platform modules; do not use:
-  - `@salesforce/*`
-  - `lightning/*`
-  - `@wire` (LWC-only)
-- Use standard web APIs and npm packages only.
-
-## LWC MCP Server Integration (Data Access Guidance)
-
-The LWC MCP server (via Agentforce Vibes extension) provides framework-agnostic data access guidance for UI API and GraphQL patterns.
-
-### Primary Tool: `orchestrate_lds_data_requirements`
-
-The `orchestrate_lds_data_requirements` tool analyzes data requirements and routes to appropriate guidance tools (UI API or GraphQL). **Note:** Tool names may change, but the purpose remains orchestrating LDS data requirements.
-
-**Important for React Applications:** If the MCP tool recommends Apex REST, React applications should ignore this recommendation. Apex REST is not available in React applications. Follow the [Apex REST Strategy](#data-access-priority-order) section above to evaluate whether GraphQL can handle the requirement, or inform the user that the feature is not currently supported in React.
-
-### Tool Availability Check (MANDATORY)
-
-Before implementing data access, **MUST** verify `orchestrate_lds_data_requirements` is available. If unavailable:
-
-1. Notify user: "LWC MCP data access tools not enabled. Add 'lwc-experts' to --toolsets in a4d_mcp_settings.json"
-2. Offer to update the file if you have write access
-3. Otherwise, provide manual instructions
-
-**Configuration:** Add `"lwc-experts"` to `--toolsets` in `a4d_mcp_settings.json` (typically at `{VSCode/Cursor globalStorage}/salesforce.salesforcedx-einstein-gpt/settings/a4d_mcp_settings.json`). Example: `"metadata,lwc-experts"` in the args array.
-
-### LWC MCP Server Tool Usage Restrictions (CRITICAL)
-
-**This rule applies when building React applications. Do NOT create LWC components or use LWC-specific development tools.**
-
-**Allowed MCP Tools (Data Access Only):**
-
-- `orchestrate_lds_data_requirements` - Primary tool for data access guidance
-- Any data access guidance tools referenced by `orchestrate_lds_data_requirements` (e.g., UI API or GraphQL guidance tools)
-
-**Note:** If the MCP tool recommends Apex REST guidance tools, React applications should ignore these recommendations as Apex REST is not available in React.
-
-**Prohibited MCP Tools (LWC Component Development):**
-
-- `guide_lwc_development` - LWC component development guidance
-- `orchestrate_lwc_component_creation` - LWC component creation orchestration
-- `create_lwc_component_from_prd` - LWC component creation from PRD
-- Any other LWC component creation, development, or framework-specific tools
-
-**Enforcement:**
-
-- **NEVER** call LWC component creation or development tools from the LWC MCP server
-- **ONLY** use data access related tools that provide framework-agnostic guidance
-- If you encounter a request to create LWC components, remind the user that you are building a React app and redirect them to use React patterns instead
-
-## Data Access Rules (CRITICAL)
-
-- MANDATORY: Use the DataSDK (`getDataSDK()` from `@salesforce/sdk-data`) for all API calls from React. The SDK handles authentication and CSRF token management. Do NOT use `axios` or raw `fetch` for Salesforce API calls.
-
-### Data Access Workflow (MANDATORY)
-
-**Before implementing any data access functionality:**
-
-1. **Proactively check** for LWC MCP server tool availability (see [LWC MCP Server Integration](#lwc-mcp-server-integration-data-access-guidance) section above)
-2. **Use the LWC MCP server's `orchestrate_lds_data_requirements` tool** to get guidance on the appropriate data access pattern
-3. The MCP tool will analyze your requirements and guide you to the appropriate Salesforce data access pattern (GraphQL or UI API)
-4. **Follow the MCP tool's recommendations** when implementing data access code, prioritizing GraphQL for all operations
-5. **If the tool recommends Apex REST**, ignore this recommendation and follow the [Apex REST Strategy](#data-access-priority-order) to evaluate if GraphQL can handle the requirement
-
-**Note:** The code examples below serve as reference patterns, but your implementation should be informed by the MCP tool's guidance, which provides the most up-to-date best practices and framework-agnostic patterns.
-
-### Data Access Priority Order
-
-The LWC MCP server's `orchestrate_lds_data_requirements` tool follows this priority order when recommending data access patterns:
-
-1. **GraphQL** (queries & mutations) - Preferred for all data operations including reads, writes, complex queries, relationships, and multi-entity operations
-2. **Salesforce UI API** - For standard CRUD operations when GraphQL is not suitable
-
-**Apex REST Strategy (CRITICAL):**
-
-- **Apex REST is NOT available in React applications.** If the MCP tool recommends Apex REST, or if you believe Apex is needed:
-  1. **Reflect** on why Apex seems necessary
-  2. **Evaluate** whether GraphQL queries or mutations can accomplish the task
-  3. **If GraphQL cannot handle the requirement**, inform the user that the feature is not currently supported in React applications
-  4. **Do NOT** implement Apex REST endpoints or attempt to call them from React
-
-**Note:** For AI/generative features, see the [Einstein LLM Gateway](#einstein-llm-gateway-aigenerative-features) section below.
-
-### Reference Code Examples
-
-The following code examples serve as reference patterns for React applications. **Always consult the LWC MCP server's `orchestrate_lds_data_requirements` tool first** to ensure you're using the most appropriate pattern and latest best practices for your specific use case.
-
-GraphQL query example:
-
-```typescript
-import { getDataSDK, gql } from '@salesforce/sdk-data';
-
-const GET_ACCOUNT = gql`
-  query GetAccount($id: ID!) {
-    uiapi {
-      query {
-        Account(where: { Id: { eq: $id } }) {
-          edges {
-            node {
-              Id
-              Name {
-                value
-              }
-            }
-          }
-        }
-      }
-    }
-  }
-`;
-
-const data = await getDataSDK();
-const response = await data.graphql?.<GetAccountQuery>(GET_ACCOUNT, { id: '001...' });
-
-if (response?.errors?.length) {
-  throw new Error(response.errors.map(e => e.message).join('; '));
-}
-
-const account = response?.data;
-```
-
-GraphQL mutation example:
-
-```typescript
-import { getDataSDK, gql } from '@salesforce/sdk-data';
-
-const UPDATE_ACCOUNT = gql`
-  mutation UpdateAccount($id: ID!, $name: String!) {
-    uiapi {
-      AccountUpdate(input: {
-        Id: $id
-        Account: {
-          Name: { value: $name }
-        }
-      }) {
-        Record {
-          Id
-          Name {
-            value
-          }
-        }
-      }
-    }
-  }
-`;
-
-const data = await getDataSDK();
-const result = await data.graphql?.<UpdateAccountMutation>(UPDATE_ACCOUNT, {
-  id: '001...',
-  name: 'New Name',
-});
-
-if (result?.errors?.length) {
-  throw new Error(result.errors.map(e => e.message).join('; '));
-}
-```
-
-UI API example (using the SDK's fetch):
-
-```typescript
-import { getDataSDK } from '@salesforce/sdk-data';
-
-async function fetchRecord(recordId: string) {
-  const data = await getDataSDK();
-  const response = await data.fetch!(`/services/data/v62.0/ui-api/records/${recordId}`);
-
-  if (!response.ok) {
-    throw new Error(`UI API failed: ${response.status}`);
-  }
-
-  return response.json();
-}
-```
-
-## Einstein LLM Gateway (AI/Generative Features)
-
-Einstein LLM Gateway provides AI and generative capabilities for your React application. Use this service when you want to add features such as:
-
-- Text generation
-- Prompt-based AI responses
-- LLM-powered content creation
-- AI-assisted workflows
-
-### Einstein LLM Gateway Pattern
-
-```typescript
-import { getDataSDK } from '@salesforce/sdk-data';
-
-async function callEinsteinGenerations({ prompt, model = 'gpt-4', signal }: {
-  prompt: string;
-  model?: string;
-  signal?: AbortSignal;
-}): Promise<string> {
-  const url = '/services/data/v62.0/einstein/llm/prompt/generations';
-  const sdk = await getDataSDK();
-  const resp = await sdk.fetch!(url, {
-    method: 'POST',
-    headers: { 'Content-Type': 'application/json', Accept: 'application/json' },
-    body: JSON.stringify({
-      additionalConfig: {
-        applicationName: 'PromptTemplateGenerationsInvocable',
-        model,
-      },
-      promptTextorId: prompt,
-    }),
-    signal,
-  });
-
-  if (!resp.ok) {
-    throw new Error(`Einstein LLM request failed (${resp.status})`);
-  }
-
-  const data = await resp.json();
-  return data?.generations?.[0]?.text || '';
-}
-```
-
-## Error Handling Pattern
-
-- Always implement robust try/catch for async operations.
-- Provide useful but safe error messages (no sensitive data leakage).
-
-```javascript
-async function safeFetch(recordId) {
-  try {
-    const data = await fetchRecord(recordId);
-    return data;
-  } catch (err) {
-    console.error('Salesforce UI API Error:', err);
-    throw err;
-  }
-}
-```
-
-## Anti-Patterns (Do NOT do these)
-
-- **Do NOT make UI/layout/theme/nav changes without updating appLayout.tsx** — If you add or change navigation, header, footer, sidebar, or overall layout, you must also edit the layout shell (`src/appLayout.tsx`). Leaving appLayout.tsx untouched while editing only pages or components is an error.
-- **Apex REST is not available in React applications** - Do NOT attempt to use or call Apex REST endpoints from React code
-- Unnecessary Apex controllers for simple UI API/GraphQL operations
-- Missing error handling for async operations
-- Hardcoded Salesforce URLs, IDs, or sensitive data
-- Ignoring field-level security and permission checks
-- Direct DOM manipulation in React components
-- Using LWC-specific patterns (`@wire`, LDS) or `@salesforce/*` modules in React
-
-## Security Standards (CRITICAL)
-
-- Validate user permissions before data operations.
-- Respect record sharing rules and field-level security.
-- Never hardcode credentials or secrets in client code.
-- Sanitize all user inputs.
-- Use HTTPS for all API calls.
-
-### Authentication Error Handling (MANDATORY)
-
-- The Data SDK handles 401/403 errors.
-- When a 401 (Unauthorized) or 403 (Forbidden) response is received, trigger a page refresh with `window.location.reload()` to redirect to login.
-
-### Notes
-
-- avoid swallowing errors.
-
-Input sanitization example:
-
-```javascript
-function sanitizeInput(input) {
-  if (typeof input !== 'string') return '';
-  return input
-    .trim()
-    .replace(/<script[^>]*>.*?<\/script>/gi, '')
-    .replace(/javascript:/gi, '')
-    .slice(0, 255);
-}
-```
-
-## Performance Standards
-
-- Implement client-side caching (e.g., RTK Query or React Query) for API data.
-- Use `React.memo`, `useMemo`, and `useCallback` where appropriate.
-- Implement proper loading and error states.
-
-## TypeScript Standards
-
-- Prefer TypeScript for React components and utilities.
-- Define clear and explicit interfaces for props and API data.
-
-## Testing Requirements
-
-- Use Jest + React Testing Library for UI tests.
-- Test loading, success, and error states for data-fetching components.
-
-## Application Generation Rules
-
-- When requested to generate a new application:
-  - Replace existing template content; do not append to the starter.
-  - Preserve the entry point and routes under `force-app/main/default/webapplications/<appName>/src/`.
-  - Keep existing build and deploy commands working.
-  - Follow the Data Access and Security standards above.
-
-## Debugging Guidance
-
-- Use React DevTools for component inspection.
-- Monitor the browser Network tab for REST/GraphQL calls and auth headers.
-- Implement Error Boundaries for unhandled exceptions.
-
-## Quality Checklist (for generated code)
-
-- Entry point maintained (`App.tsx` or `App.js` present and wired in routes/pages).
-- **Layout maintained (MANDATORY for UI work):** For any change that affects global layout, nav, header, footer, sidebar, or theme, you **must** have edited `appLayout.tsx`. If you did not open or modify appLayout.tsx, the change is incomplete — go back and update the layout file.
-- Uses shadcn/ui and Tailwind for UI.
-- Follows Data Access rules with proper auth and error handling.
-- Enforces Security standards and input sanitization.
-- Includes loading and error states.
-- Performance optimizations present where reasonable.
-- Tests cover core UI and data interactions.

package/dist/.a4drules/react_image_processing.md

@@ -1,45 +0,0 @@
-#Goal
-
-- You are configuring image usage for React applications generated through Vibe Coding. 
-- Your goal is to ensure Unsplash is used as the default image source unless the developer provides their own images.
-
-# AI Customization Rule: React Image Processing
-
-Image handling standards for React web apps (SFDX): CSP compliance, accessibility, and proper image sources.
-
-## Targets (File Pattern Matching)
-
-- `force-app/main/default/webapplications/*/**/*.tsx`
-- `force-app/main/default/webapplications/*/**/*.ts`
-- `force-app/main/default/webapplications/*/**/*.jsx`
-- `force-app/main/default/webapplications/*/**/*.js`
-- `force-app/main/default/webapplications/*/**/*.html`
-
-## Core Rules
-
-### Default Image Source: Unsplash
-
-Use Unsplash by default (pre-configured in CSP):
-
-```
-https://images.unsplash.com/photo-{PHOTO_ID}?w={WIDTH}&h={HEIGHT}&fit=crop&q=80
-```
-
-Sample Photo IDs: `1557683316-973673baf926` (tech), `1506905925346-21bda4d32df4` (nature)
-
-### Alternative Sources
-
-If user requests another source (Pexels, custom):
-
-- Use requested source
-- Inform user: "Add CSP Trusted Site in Setup → Security → CSP Trusted Sites"
-
-### Accessibility (MANDATORY)
-
-- Always include descriptive `alt` text
-- Use `alt=""` for decorative images only
-
-### Avoid (CSP Violations)
-
-- Avoid until requested `placeholder.com`, `picsum.photos`, `via.placeholder.com`  
-- Pre-configured: `images.unsplash.com`, `source.unsplash.com`, `images.pexels.com`

package/dist/.a4drules/ui-layout.md

@@ -1,23 +0,0 @@
-# UI layout: always update appLayout.tsx (MANDATORY)
-
-**Build navigation into the app layout:** The app layout (e.g. `appLayout.tsx`) must **include** the navigation—header nav, sidebar, or both—so that every routed page is wrapped by the same shell and nav. Do not omit nav from the layout or rely on per-page nav only.
-
-## Targets (File Pattern Matching)
-
-Apply this rule when editing React UI or layout:
-
-- `force-app/main/default/webapplications/*/src/appLayout.tsx`
-- `force-app/main/default/webapplications/*/src/**/*.tsx`
-- `force-app/main/default/webapplications/*/src/**/*.jsx`
-
-## Rule (CRITICAL)
-
-**When making any UI change** that affects navigation, header, footer, sidebar, theme, or overall layout:
-
-1. **You MUST also edit `src/appLayout.tsx`** (the theme layout used by `routes.tsx`).
-2. Do not only edit pages or components and leave `appLayout.tsx` unchanged.
-3. Before finishing: confirm you opened and modified `appLayout.tsx` if the change touches layout/nav/theme. If you did not, the task is incomplete — update the layout file.
-
-**Navigation menu and placeholder name/design (often missed):** When editing the layout, **always** update (1) the **navigation menu**—replace default nav items and labels with app-specific links and names; do not leave template "Home"/"About" or placeholder links; (2) the **app name** in header/nav brand/footer and in `index.html` `<title>`—use the actual app name, not the template placeholder; (3) any **placeholder design** in the shell so it matches the app. See **webapp-nav-and-placeholders.md**.
-
-Path: `force-app/main/default/webapplications/<appName>/src/appLayout.tsx` (or the app's layout file that `routes.tsx` imports). (or the app’s layout file that `routes.tsx` imports).

package/dist/.a4drules/webapp-nav-and-placeholders.md

@@ -1,33 +0,0 @@
----
-description: A4D rule — always update navigation menu and placeholder name/design; never leave default
-alwaysApply: true
----
-
-# Navigation Menu & Placeholder Name/Design (MANDATORY)
-
-Agents consistently miss these. **You must not leave them default.**
-
-**Navigation belongs in the app layout:** Build the navigation **into** the app layout (e.g. `appLayout.tsx`). The layout component must include the nav—header nav, sidebar, or both—so every page is wrapped by the same shell and nav. Do not omit navigation from the layout or put it only on individual pages.
-
-## 1. Navigation menu
-
-- **Always edit the navigation menu** in the layout file (typically `src/appLayout.tsx`). Replace default/placeholder nav items and labels with **app-specific** links and names.
-- Do **not** leave template items (e.g. "Home", "About", generic links or placeholder labels). Use real routes and labels that match the app (e.g. "Dashboard", "Products", "Orders" for an e‑commerce app).
-- The navigation is part of the app shell; it lives in **appLayout.tsx** (or the file that `routes.tsx` uses as the layout). Open that file and update every nav link and label.
-
-**Check before finishing:** Did I change the nav items and labels in the layout file to match this app? If not, the task is incomplete.
-
-## 2. Placeholder name and design
-
-- **Replace the placeholder app name** everywhere it appears: header, nav brand/logo area, footer, document `<title>`, and any "Welcome to…" or generic title text. Use the **actual app name** (e.g. the name used in `sf webapp generate -n <AppName>` or the user's requested name).
-- **Replace placeholder design** in the shell: default header/footer styling, generic logo area, and any template branding must be updated to match the app's aesthetic (or at least use the real app name and intentional styling).
-
-**Check before finishing:** Is the app name and shell design still the template default anywhere? If yes, update it.
-
-## Where to edit
-
-- **Layout/nav/branding:** `force-app/main/default/webapplications/<appName>/src/appLayout.tsx` — the app layout must contain the navigation (build it in here).
-- **Document title:** `force-app/main/default/webapplications/<appName>/index.html`
-- **Root page content:** The component rendered at the root route (often `Home` or similar in `routes.tsx`)
-
-Completing a web app task includes updating **navigation menu**, **app name in header/nav/footer/title**, and **placeholder design** in the shell—not only the main page content.

package/dist/.a4drules/webapp-ui-first.md

@@ -1,32 +0,0 @@
----
-description: A4D rule — build UI first, then business logic for web apps
-alwaysApply: true
----
-
-# A4D Rule: UI First, Then Business Logic (Proceed Immediately After UI)
-
-When building or modifying a web application (or any feature within it):
-
-1. **Build the UI first**
-   - Implement layout, structure, and components (pages, forms, lists, navigation).
-   - Apply styling, theming, and design-system usage so the interface is visually complete and navigable.
-   - Use placeholder or mock data only where needed to render the UI; do not wire real APIs yet.
-
-2. **Proceed to API and business logic immediately after UI completion (same iteration)**
-   - As soon as the UI for a feature is visually complete and routable, begin wiring the data layer for that same feature in the same iteration.
-   - Add data fetching (GraphQL preferred per LDS rules, then UI API; avoid Apex REST for React), state management, and event handlers.
-   - Connect forms and actions to real APIs and backend behavior.
-   - Add validation, loading, and user-friendly error states.
-   - Keep the build green; fix TypeScript and ESLint issues as you wire logic.
-
-3. **Quality gates before marking the feature complete**
-   - Run `npm run lint` and ensure 0 errors (warnings acceptable if minor).
-   - Run `npm run build` and ensure it passes.
-   - Replace any remaining mock data relevant to the feature with real data paths or clearly marked TODOs if blocked.
-
-**Rationale:** A visible, stable UI gives a clear target, and immediately wiring the API and business logic in the same iteration ensures end‑to‑end functionality and avoids stale mock UIs. This also aligns with design-system guidance (invoke **webapplications-design-system**) and LDS data access rules.
-
-Notes:
-- Within LDS, prefer GraphQL for complex reads and mutations; fall back to standard UI API adapters when appropriate.
-- For React apps, do not implement or call Apex REST. If server-side logic is truly required and cannot be achieved via GraphQL/UI API, surface a limitation explicitly.
-- If a feature's UI spans multiple pages, wire business logic page-by-page as each page's UI stabilizes, rather than deferring all logic to the end.

package/dist/force-app/main/default/webapplications/appreactsampleb2e/build/vite.config.d.ts

@@ -1,2 +0,0 @@
-declare const _default: import("vite").UserConfigFnObject;
-export default _default;

package/dist/force-app/main/default/webapplications/appreactsampleb2e/build/vite.config.js

@@ -1,93 +0,0 @@
-import { defineConfig } from 'vite';
-import react from '@vitejs/plugin-react';
-import path from 'path';
-import { resolve } from 'path';
-import tailwindcss from '@tailwindcss/vite';
-import salesforce from '@salesforce/vite-plugin-webapp-experimental';
-import codegen from 'vite-plugin-graphql-codegen';
-export default defineConfig(function (_a) {
-    var mode = _a.mode;
-    return {
-        // Ensure root base for e2e/static serve; plugin may override when deployed under a path
-        base: '/',
-        plugins: [
-            tailwindcss(),
-            react(),
-            salesforce(),
-            codegen({
-                // Path to the codegen config file
-                configFilePathOverride: resolve(__dirname, 'codegen.yml'),
-                // Run codegen on dev server start
-                runOnStart: true,
-                // Don't run codegen on build for now
-                runOnBuild: false,
-                // Enable file watcher during development
-                enableWatcher: true,
-                // Fail build if codegen errors
-                throwOnBuild: true,
-            }),
-        ],
-        // Build configuration for MPA
-        build: {
-            outDir: resolve(__dirname, 'dist'),
-            assetsDir: 'assets',
-            sourcemap: false,
-        },
-        // Resolve aliases (shared between build and test)
-        resolve: {
-            dedupe: ['react', 'react-dom'],
-            alias: {
-                '@': path.resolve(__dirname, './src'),
-                '@api': path.resolve(__dirname, './src/api'),
-                '@components': path.resolve(__dirname, './src/components'),
-                '@utils': path.resolve(__dirname, './src/utils'),
-                '@styles': path.resolve(__dirname, './src/styles'),
-                '@assets': path.resolve(__dirname, './src/assets'),
-            },
-        },
-        // Vitest configuration
-        test: {
-            // Override root for tests (build uses src/pages as root)
-            root: resolve(__dirname),
-            // Use jsdom environment for React component testing
-            environment: 'jsdom',
-            // Setup files to run before each test
-            setupFiles: ['./src/test/setup.ts'],
-            // Global test patterns
-            include: [
-                'src/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}',
-                'src/**/__tests__/**/*.{js,mjs,cjs,ts,mts,cts,jsx,tsx}',
-            ],
-            // Coverage configuration
-            coverage: {
-                provider: 'v8',
-                reporter: ['text', 'html', 'clover', 'json'],
-                exclude: [
-                    'node_modules/',
-                    'src/test/',
-                    'src/**/*.d.ts',
-                    'src/main.tsx',
-                    'src/vite-env.d.ts',
-                    'src/components/**/index.ts',
-                    '**/*.config.ts',
-                    'build/',
-                    'dist/',
-                    'coverage/',
-                    'eslint.config.js',
-                ],
-                thresholds: {
-                    global: {
-                        branches: 85,
-                        functions: 85,
-                        lines: 85,
-                        statements: 85,
-                    },
-                },
-            },
-            // Test timeout
-            testTimeout: 10000,
-            // Globals for easier testing
-            globals: true,
-        },
-    };
-});