@salesforce/webapp-template-feature-react-chart-experimental 1.48.0 → 1.48.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -67,7 +67,7 @@ You can test the extension of the base app and the components via the following:
67
67
 
68
68
  ```bash
69
69
  npm run build # apply patches → dist
70
- npm run dev # run from dist
70
+ npm run start # run from dist
71
71
  npm run watch # watch and re-apply
72
72
  ```
73
73
 
@@ -0,0 +1,35 @@
1
+ # A4D Rules Index
2
+
3
+ Rules in this folder guide the agent for this SFDX project. **Knowledge** (expert content) lives in the **local-expert MCP** repo (e.g. `local-expert-mcp`); rules here reference when to call which expert.
4
+
5
+ ## Always-apply rules (MUST follow)
6
+
7
+ | File | Purpose |
8
+ |------|--------|
9
+ | **webapp.md** | Main web app rules: invoke local-expert MCP (`webapplications-design-system` + `webapplications`), no `node -e`, React/SFDX workflow; **replace default boilerplate**; **populate home page**; **frontend aesthetics**—avoid AI slop, follow design-system expert. |
10
+ | **webapp-no-node-e.md** | No `node -e` for any file/config/shell work; use `replace_in_file` or `write_to_file` only. |
11
+ | **a4d-webapp-generate.md** | Before `sf webapp generate`: call `get_expert_knowledge` with `webapplications-design-system` and `webapplications`; then run CLI. |
12
+ | **webapp-ui-first.md** | Build UI (layout, components, styling) first; then implement business logic (APIs, state, handlers). |
13
+ | **webapp-nav-and-placeholders.md** | **Build navigation into the app layout** (`appLayout.tsx`). Always update nav menu (app-specific items/labels) and placeholder name/design (header/nav/footer/title). Often missed—mandatory. |
14
+
15
+ ## Context-specific rules (by file pattern or topic)
16
+
17
+ | File | Purpose |
18
+ |------|--------|
19
+ | **react.md** | React web app structure, shadcn/Tailwind, data access, security; edit `appLayout.tsx` when changing layout. |
20
+ | **ui-layout.md** | When changing UI/nav/header/footer/sidebar/theme, always update `appLayout.tsx`. |
21
+ | **code-quality.md** | ESLint, Prettier, import order, naming, lint/build before completion; no `node -e`. |
22
+ | **build-validation.md** | `npm run build` must succeed from web app dir before completing. |
23
+ | **typescript.md** | TypeScript strictness, return types, interfaces. |
24
+ | **images.md** | Images: Unsplash default, CSP, alt text, error handling. |
25
+ | **react_image_processing.md** | Image handling (Unsplash, CSP, accessibility) for React components. |
26
+ | **graphql/** | GraphQL tools and knowledge (schemas, LDS guides). |
27
+
28
+ ## Knowledge repository (experts)
29
+
30
+ Expert knowledge is served by the **local-expert MCP** (e.g. at `local-expert-mcp`). The agent must call **`get_expert_knowledge`** with the appropriate topic:
31
+
32
+ - **webapplications-design-system** — Always use for web app UI/design work (design system, typography, color, motion).
33
+ - **webapplications** — Use for app generation and structure; then call sub-topics as needed (e.g. `webapplications-best-practice`, `webapplications-feature-*`).
34
+
35
+ See the MCP repo's **rule-expert-mcp.md** for full topic list and when to call which expert.
@@ -0,0 +1,27 @@
1
+ ---
2
+ description: A4D rule — call expert MCP (webapplications + webapplications-design-system) before sf webapp generate
3
+ alwaysApply: true
4
+ ---
5
+
6
+ # A4D Rule: Before `sf webapp generate`
7
+
8
+ Before running **`sf webapp generate`**, you **must**:
9
+
10
+ 1. **Call the expert MCP** (`get_expert_knowledge`) with topic **`webapplications-design-system`** — always invoke this expert for UI/design direction.
11
+ 2. **Call the expert MCP** with topic **`webapplications`** to get generation and structure guidance.
12
+ 3. Follow the instructions from the MCP responses.
13
+ 4. Only after that, run `sf webapp generate` (e.g. `sf webapp generate -n <AppName> -t <template>`).
14
+
15
+ **Webapp name (`-n` / `<AppName>`):** Must be **alphanumerical only**—no spaces, hyphens, underscores, or other special characters. Use only letters (A–Z, a–z) and digits (0–9). If the desired name has spaces or special characters, use a single alphanumeric word (e.g. `CoffeeBoutique` instead of `Coffee Boutique` or `coffee-boutique`).
16
+
17
+ Do not run `sf webapp generate` without having invoked the expert MCP with **`webapplications-design-system`** and **`webapplications`** first.
18
+
19
+ When modifying an existing web app (UI, layout, or new features), **always** call `get_expert_knowledge` with topic **`webapplications-design-system`** before making UI or design changes.
20
+
21
+ **After generating (or when touching a new app):** Replace all default boilerplate content (e.g. "React App", "Vite + React", default document title in `index.html`, placeholder text in the shell) with the actual app name or user-facing copy. Do not leave generic template text in the UI or `<title>`.
22
+
23
+ **Home page content:** Populate the home page (root route) with real, app-specific content (e.g. landing section, banners, tiles, hero, links to features). Never leave the home page as the default template or placeholder.
24
+
25
+ **Navigation menu and placeholder name/design:** After generating or when delivering a web app, **you must** (1) **Edit the navigation menu** in `appLayout.tsx`: replace every default nav item and label with app-specific routes and names; do not leave template "Home"/"About" or placeholder links. (2) **Replace the placeholder app name** in the header, nav brand, footer, and `index.html` `<title>` with the actual app name. (3) **Update placeholder design** in the shell (header/footer/branding) so it is not the template default. See **webapp-nav-and-placeholders.md**. Agents often skip this—do not.
26
+
27
+ Prioritize webapplications generation first, and then generate the metadata.
@@ -8,16 +8,16 @@ Build validation for successful deployments with minimal friction.
8
8
 
9
9
  ## MANDATORY: Build Success
10
10
 
11
- **Before completing any coding session:**
11
+ **Before completing any coding session** (from the web app directory `force-app/main/default/webapplications/<appName>/`):
12
12
  ```bash
13
13
  npm run build # MUST succeed with no errors
14
14
  ```
15
15
 
16
16
  ## Quick Quality Checks
17
+ Run from the web app directory (`force-app/main/default/webapplications/<appName>/`):
17
18
  ```bash
18
- npm run format:check # Auto-fixable
19
- npm run lint # Most issues auto-fixable
20
- tsc -b # Catches major issues
19
+ npm run lint # ESLint; fix issues before completing
20
+ npm run build # Runs tsc -b && vite build; catches TypeScript and build issues
21
21
  ```
22
22
 
23
23
  ## Requirements
@@ -29,14 +29,12 @@ tsc -b # Catches major issues
29
29
 
30
30
  **Can Be Warnings:**
31
31
  - ESLint warnings
32
- - Prettier formatting issues
33
32
  - Minor TypeScript warnings
34
33
 
35
- ## Auto-Fix Commands
34
+ ## Fix Commands (when available in the web app's package.json)
36
35
  ```bash
37
- npm run fix-all # Fix formatting + linting
38
- npm run format # Fix Prettier issues
39
- npm run lint:fix # Fix ESLint issues
36
+ npm run lint # Run ESLint (always available)
37
+ # If your project adds Prettier/format scripts, use those before completing
40
38
  ```
41
39
 
42
40
  ## Workflow
@@ -47,8 +45,8 @@ npm run lint:fix # Fix ESLint issues
47
45
  3. Check periodically: `npm run lint` (optional)
48
46
 
49
47
  **Before Completion:**
50
- 1. Run `npm run build`
51
- 2. If fails: Run `npm run fix-all`, fix TypeScript errors, retry build
48
+ 1. Run `npm run build` from the web app directory
49
+ 2. If it fails: fix TypeScript/ESLint errors (run `npm run lint`), then retry build
52
50
 
53
51
  ## Error Priority
54
52
 
@@ -59,7 +57,6 @@ npm run lint:fix # Fix ESLint issues
59
57
 
60
58
  **Fix When Convenient:**
61
59
  - ESLint warnings
62
- - Prettier formatting
63
60
  - Unused variables
64
61
 
65
62
  ## Hard Requirements
@@ -67,11 +64,11 @@ npm run lint:fix # Fix ESLint issues
67
64
  - No broken imports
68
65
  - Basic TypeScript type safety
69
66
 
70
- ## Key Commands
67
+ ## Key Commands (web app directory)
71
68
  ```bash
72
- npm run dev # Start development
73
- npm run build # Check deployment readiness
74
- npm run fix-all # Fix common issues
69
+ npm run start # Start development server (vite)
70
+ npm run build # TypeScript + Vite build; check deployment readiness
71
+ npm run lint # Run ESLint
75
72
  ```
76
73
 
77
74
  ## Troubleshooting Import Errors
@@ -2,38 +2,27 @@
2
2
 
3
3
  Enforces ESLint, Prettier, and coding best practices for consistent, maintainable code.
4
4
 
5
+ **Execution rule:** Do not use `node -e` for any file or config edits. Use `replace_in_file` or `write_to_file` only (see **webapp-no-node-e.md**).
6
+
5
7
  ## Targets
6
8
  - `force-app/main/default/webapplications/*/**/*`
7
9
  - `**/*.{js,ts,jsx,tsx,json,md}`
8
10
 
9
11
  ## MANDATORY Checks
10
12
 
11
- **Before writing code:**
13
+ **Before completing code** (run from the web app directory `force-app/main/default/webapplications/<appName>/`):
12
14
  ```bash
13
- npm run lint # MUST result in: 0 problems (0 errors, 0 warnings)
14
- npm run format:check # MUST result in: All matched files use Prettier code style!
15
+ npm run lint # MUST result in: 0 errors (0 warnings preferred)
16
+ npm run build # MUST succeed (includes TypeScript check)
15
17
  ```
16
18
 
17
- ## Prettier Config (.prettierrc)
18
- ```json
19
- {
20
- "semi": true,
21
- "trailingComma": "es5",
22
- "singleQuote": true,
23
- "printWidth": 80,
24
- "tabWidth": 2,
25
- "useTabs": false,
26
- "bracketSpacing": true,
27
- "arrowParens": "avoid",
28
- "endOfLine": "lf"
29
- }
30
- ```
19
+ If your project adds Prettier, use a consistent config (e.g. `.prettierrc` with `semi`, `singleQuote`, `printWidth`, etc.) and run format checks before completing.
20
+
21
+ ## Lint / Fix
31
22
 
32
- ## Auto-Fix Commands
33
23
  ```bash
34
- npm run fix-all # Fix formatting + linting (recommended)
35
- npm run format # Fix Prettier issues
36
- npm run lint:fix # Fix ESLint issues
24
+ npm run lint # Run ESLint (always available in the template web app)
25
+ # Use your editor's format-on-save or add npm scripts for Prettier if desired
37
26
  ```
38
27
 
39
28
  ## Import Order (MANDATORY)
@@ -139,12 +128,10 @@ const DEBOUNCE_DELAY = 5000; // Correct
139
128
  ## Quality Workflow
140
129
 
141
130
  **Before Committing:**
142
- 1. `npm run check-all` - All checks must pass
143
- 2. `npm run fix-all` - Auto-fix issues if needed
144
- 3. `npm run build` - Build must succeed
131
+ 1. `npm run lint` - 0 errors (and 0 warnings when possible)
132
+ 2. `npm run build` - Build must succeed (TypeScript + Vite)
145
133
 
146
134
  ## Zero Tolerance Policy
147
135
  - ESLint errors: MUST be 0
148
- - ESLint warnings: MUST be 0
149
- - Prettier violations: MUST be 0
150
- - TypeScript errors: MUST be 0
136
+ - ESLint warnings: MUST be 0 (fix when convenient)
137
+ - TypeScript errors: MUST be 0 (enforced by `npm run build`)
@@ -3,22 +3,23 @@
3
3
  Instructs agents to use the established GraphQL utilities for Salesforce data access.
4
4
 
5
5
  ## Targets
6
- - `force-app/main/default/webApplications/static-app/**/*.ts`
7
- - `force-app/main/default/webApplications/static-app/**/*.tsx`
6
+ - `force-app/main/default/webapplications/<appName>/**/*.ts`
7
+ - `force-app/main/default/webapplications/<appName>/**/*.tsx`
8
8
 
9
9
  ## TypeScript Types & Code Generation
10
10
 
11
11
  ### Generated Types File
12
- Types are auto-generated at: `force-app/main/default/webApplications/static-app/src/api/graphql-operations-types.ts`
12
+ Types are auto-generated at: `force-app/main/default/webapplications/<appName>/src/api/graphql-operations-types.ts`
13
13
 
14
14
  ### Generation Command
15
+ Run from the web app directory (replace `<appName>` with your app folder name, e.g. `base-react-app`):
15
16
  ```bash
16
- cd force-app/main/default/webApplications/static-app && npm run graphql:codegen
17
+ cd force-app/main/default/webapplications/<appName> && npm run graphql:codegen
17
18
  ```
18
19
 
19
- The codegen configuration is located at `scripts/graphql/codegen.js` and generates types from:
20
- - Schema: `schema.graphql` (root level)
21
- - Documents: `force-app/main/default/webApplications/static-app/src/**/*.{graphql,ts,tsx}`
20
+ The codegen configuration is located at `scripts/graphql/codegen.js` (or the package's codegen config) and generates types from:
21
+ - Schema: `schema.graphql` (root level of the web app or as configured)
22
+ - Documents: `force-app/main/default/webapplications/<appName>/src/**/*.{graphql,ts,tsx}`
22
23
 
23
24
  ### Type Naming Convention
24
25
  For a GraphQL operation named `GetHighRevenueAccounts`:
@@ -28,7 +29,7 @@ For a GraphQL operation named `GetHighRevenueAccounts`:
28
29
  ## Core Types & Function Signatures
29
30
 
30
31
  ### executeGraphQL Function
31
- Located in `force-app/main/default/webApplications/static-app/src/api/graphql.ts`:
32
+ Located in `force-app/main/default/webapplications/<appName>/src/api/graphql.ts`:
32
33
 
33
34
  ```typescript
34
35
  function executeGraphQL<T, InputVariables = Record<string, unknown>>(
@@ -118,7 +119,7 @@ There are **two acceptable patterns** for defining GraphQL queries:
118
119
  Store queries in `.graphql` files for codegen to process:
119
120
 
120
121
  ```graphql
121
- # force-app/main/default/webApplications/static-app/src/api/utils/query/myQuery.graphql
122
+ # force-app/main/default/webapplications/<appName>/src/api/utils/query/myQuery.graphql
122
123
  query GetMyData($myVariable: String) {
123
124
  uiapi {
124
125
  query {
@@ -137,7 +138,7 @@ query GetMyData($myVariable: String) {
137
138
 
138
139
  #### Step 2: Run Code Generation
139
140
  ```bash
140
- cd force-app/main/default/webApplications/static-app && npm run graphql:codegen
141
+ cd force-app/main/default/webapplications/<appName> && npm run graphql:codegen
141
142
  ```
142
143
 
143
144
  This generates types in `graphql-operations-types.ts`:
@@ -254,7 +255,7 @@ export async function getCurrentUser(): Promise<User | null> {
254
255
  ## Reference Examples
255
256
 
256
257
  ### Pattern 1 Example: accounts.ts
257
- See `force-app/main/default/webApplications/static-app/src/api/utils/accounts.ts` for Pattern 1:
258
+ See `force-app/main/default/webapplications/<appName>/src/api/utils/accounts.ts` for Pattern 1:
258
259
  1. Importing query from `.graphql` file with `?raw` suffix
259
260
  2. Importing generated types from `graphql-operations-types.ts`
260
261
  3. Using `NodeOfConnection` to extract node types
@@ -262,7 +263,7 @@ See `force-app/main/default/webApplications/static-app/src/api/utils/accounts.ts
262
263
  5. Safe data extraction from the nested response
263
264
 
264
265
  ### Pattern 2 Example: user.ts
265
- See `force-app/main/default/webApplications/static-app/src/api/utils/user.ts` for Pattern 2:
266
+ See `force-app/main/default/webapplications/<appName>/src/api/utils/user.ts` for Pattern 2:
266
267
  1. Using `gql` template tag for inline query definition
267
268
  2. Importing generated types from `graphql-operations-types.ts`
268
269
  3. Simple query without variables
@@ -279,7 +280,7 @@ For dynamic fieldsets with known fields that should be conditionally included, u
279
280
 
280
281
  ### Example with Fragments
281
282
  ```graphql
282
- # static-app/src/api/utils/query/getAccountDetails.graphql
283
+ # <appName>/src/api/utils/query/getAccountDetails.graphql
283
284
  query GetAccountDetails(
284
285
  $id: ID!
285
286
  $includeFinancials: Boolean!
@@ -17,17 +17,27 @@ Apply these rules to the React web app files under the SFDX package directory:
17
17
  - Standardize UI with shadcn/ui and Tailwind.
18
18
  - Prevent prohibited patterns that break React or Salesforce constraints.
19
19
 
20
+ ## UI / layout edits (MANDATORY — read before any UI change)
21
+
22
+ **When the user asks for UI changes** (new components, pages, navigation, header, footer, sidebar, theme, or “layout”):
23
+ **You MUST open and update `src/appLayout.tsx`** (the theme layout) whenever the change affects how the app shell looks or behaves.
24
+ Do not only edit pages or components and leave `appLayout.tsx` unchanged.
25
+ If in doubt, **edit appLayout.tsx as well**.
26
+ The layout file is: `force-app/main/default/webapplications/<appName>/src/appLayout.tsx` (or the app’s `appLayout.tsx` used by `routes.tsx`).
27
+
28
+ **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**.
29
+
20
30
  ## Project & Entry Points
21
31
 
22
32
  - React web app root: `force-app/main/default/webapplications/<appName>/`
23
33
  - Main entry component: `force-app/main/default/webapplications/<appName>/src/App.tsx`
24
- - Running Development Server:
25
- - `npm run dev`
34
+ - **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.
35
+ - Running Development Server (from the web app directory):
36
+ - `npm run start` — starts the Vite dev server
26
37
  - You can generally assume the dev server is already running and don't need to start it.
27
- - Keep build/deploy workflow intact:
28
- - `npm run build`
29
- - `npm run deploy`
30
- - `npm run open`
38
+ - Build (from the web app directory):
39
+ - `npm run build` — TypeScript check + Vite build
40
+ - 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.
31
41
 
32
42
  ## Component Library (MANDATORY)
33
43
 
@@ -45,6 +55,20 @@ import { Input } from '@/components/ui/input';
45
55
  - Use Tailwind CSS utility classes.
46
56
  - Follow consistent spacing, color, and typography conventions.
47
57
 
58
+ ## React & TypeScript Standards
59
+
60
+ - Component Architecture: Prefer functional components with hooks.
61
+ - File Naming: Use PascalCase for components (e.g., `Button.tsx`) and camelCase for hooks (e.g., `useAuth.ts`).
62
+ - Imports: Use absolute paths (e.g., `@/components/...`) if the `tsconfig.json` or `vite.config.ts` supports it.
63
+ - State: Default to `useState` for local state; avoid adding global state libraries unless requested.
64
+
65
+ ## Layout and theme (appLayout.tsx) — CRITICAL for UI edits
66
+
67
+ - **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.
68
+ - **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.
69
+ - **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.
70
+ - 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`.
71
+
48
72
  ## Module & Platform Restrictions
49
73
 
50
74
  - React apps must NOT import or rely on Salesforce platform modules; do not use:
@@ -281,6 +305,7 @@ async function safeFetch(recordId) {
281
305
 
282
306
  ## Anti-Patterns (Do NOT do these)
283
307
 
308
+ - **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.
284
309
  - **Apex REST is not available in React applications** - Do NOT attempt to use or call Apex REST endpoints from React code
285
310
  - Unnecessary Apex controllers for simple UI API/GraphQL operations
286
311
  - Missing error handling for async operations
@@ -352,7 +377,8 @@ function sanitizeInput(input) {
352
377
 
353
378
  ## Quality Checklist (for generated code)
354
379
 
355
- - Entry point maintained (`App.js` present and wired in pages).
380
+ - Entry point maintained (`App.tsx` or `App.js` present and wired in routes/pages).
381
+ - **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.
356
382
  - Uses shadcn/ui and Tailwind for UI.
357
383
  - Follows Data Access rules with proper auth and error handling.
358
384
  - Enforces Security standards and input sanitization.
@@ -0,0 +1,23 @@
1
+ # UI layout: always update appLayout.tsx (MANDATORY)
2
+
3
+ **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.
4
+
5
+ ## Targets (File Pattern Matching)
6
+
7
+ Apply this rule when editing React UI or layout:
8
+
9
+ - `force-app/main/default/webapplications/*/src/appLayout.tsx`
10
+ - `force-app/main/default/webapplications/*/src/**/*.tsx`
11
+ - `force-app/main/default/webapplications/*/src/**/*.jsx`
12
+
13
+ ## Rule (CRITICAL)
14
+
15
+ **When making any UI change** that affects navigation, header, footer, sidebar, theme, or overall layout:
16
+
17
+ 1. **You MUST also edit `src/appLayout.tsx`** (the theme layout used by `routes.tsx`).
18
+ 2. Do not only edit pages or components and leave `appLayout.tsx` unchanged.
19
+ 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.
20
+
21
+ **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**.
22
+
23
+ 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).
@@ -0,0 +1,33 @@
1
+ ---
2
+ description: A4D rule — always update navigation menu and placeholder name/design; never leave default
3
+ alwaysApply: true
4
+ ---
5
+
6
+ # Navigation Menu & Placeholder Name/Design (MANDATORY)
7
+
8
+ Agents consistently miss these. **You must not leave them default.**
9
+
10
+ **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.
11
+
12
+ ## 1. Navigation menu
13
+
14
+ - **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.
15
+ - 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).
16
+ - 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.
17
+
18
+ **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.
19
+
20
+ ## 2. Placeholder name and design
21
+
22
+ - **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).
23
+ - **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).
24
+
25
+ **Check before finishing:** Is the app name and shell design still the template default anywhere? If yes, update it.
26
+
27
+ ## Where to edit
28
+
29
+ - **Layout/nav/branding:** `force-app/main/default/webapplications/<appName>/src/appLayout.tsx` — the app layout must contain the navigation (build it in here).
30
+ - **Document title:** `force-app/main/default/webapplications/<appName>/index.html`
31
+ - **Root page content:** The component rendered at the root route (often `Home` or similar in `routes.tsx`)
32
+
33
+ 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.
@@ -0,0 +1,25 @@
1
+ ---
2
+ description: A4D rule — no node -e; use replace_in_file / write_to_file only
3
+ alwaysApply: true
4
+ ---
5
+
6
+ # A4D Enforcement: No node -e
7
+
8
+ This project forbids using "node -e" for any operation (file manipulation, string replacement, reading/writing configs, shell automation).
9
+
10
+ Policy:
11
+ - Never use "node -e" one-liners.
12
+ - Use replace_in_file or write_to_file for code/config edits.
13
+ - Use jq/sed/awk cautiously when needed; prefer replace_in_file for deterministic edits.
14
+ - For JSON edits: prefer write_to_file after reading, or replace_in_file with precise diffs.
15
+ - For ESLint/TS config changes: edit files directly via write_to_file or replace_in_file.
16
+
17
+ Rationale:
18
+ - Ensures reproducibility and auditability.
19
+ - Avoids shell escaping bugs and cross-platform inconsistencies.
20
+ - Aligns with project reliability protocol.
21
+
22
+ Violation handling:
23
+ - If any prior step used "node -e", revert and redo using write_to_file or replace_in_file.
24
+
25
+ **Cross-reference:** This rule is also summarized in **webapp.md** (MUST FOLLOW #1). Both apply.
@@ -0,0 +1,32 @@
1
+ ---
2
+ description: A4D rule — build UI first, then business logic for web apps
3
+ alwaysApply: true
4
+ ---
5
+
6
+ # A4D Rule: UI First, Then Business Logic (Proceed Immediately After UI)
7
+
8
+ When building or modifying a web application (or any feature within it):
9
+
10
+ 1. **Build the UI first**
11
+ - Implement layout, structure, and components (pages, forms, lists, navigation).
12
+ - Apply styling, theming, and design-system usage so the interface is visually complete and navigable.
13
+ - Use placeholder or mock data only where needed to render the UI; do not wire real APIs yet.
14
+
15
+ 2. **Proceed to API and business logic immediately after UI completion (same iteration)**
16
+ - 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.
17
+ - Add data fetching (GraphQL preferred per LDS rules, then UI API; avoid Apex REST for React), state management, and event handlers.
18
+ - Connect forms and actions to real APIs and backend behavior.
19
+ - Add validation, loading, and user-friendly error states.
20
+ - Keep the build green; fix TypeScript and ESLint issues as you wire logic.
21
+
22
+ 3. **Quality gates before marking the feature complete**
23
+ - Run `npm run lint` and ensure 0 errors (warnings acceptable if minor).
24
+ - Run `npm run build` and ensure it passes.
25
+ - Replace any remaining mock data relevant to the feature with real data paths or clearly marked TODOs if blocked.
26
+
27
+ **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.
28
+
29
+ Notes:
30
+ - Within LDS, prefer GraphQL for complex reads and mutations; fall back to standard UI API adapters when appropriate.
31
+ - 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.
32
+ - 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.
@@ -0,0 +1,75 @@
1
+ # MUST FOLLOW
2
+
3
+ 0. **Always invoke the `local-expert` MCP** when dealing with web applications: call **`get_expert_knowledge`** with topic **`webapplications-design-system`** (for UI/design), and with **`webapplications`** when generating or structuring the app. Do not skip the design-system expert for any web app UI work.
4
+ 1. **No `node -e`.** This project forbids `node -e` for any operation (file edits, config, shell automation). Use `replace_in_file` or `write_to_file` only. See **webapp-no-node-e.md**.
5
+
6
+ # React Development & Stability Rules
7
+
8
+ ## Terminal & Execution Strategy
9
+ - **NEVER use `node -e`** for file manipulation, string replacement, or reading files. Forbidden. Use `replace_in_file` or `write_to_file` only.
10
+ - ALWAYS use `replace_in_file` or `write_to_file` for code changes.
11
+ - IF you must parse JSON (like package.json), use `jq` if available. Otherwise, read the file and process it internally.
12
+ - ALWAYS use `npm` or `yarn` commands directly rather than writing custom Node scripts to trigger them.
13
+
14
+ ## React & TypeScript Standards
15
+ - Component Architecture: Prefer functional components with hooks.
16
+ - File Naming: Use PascalCase for components (e.g., `Button.tsx`) and camelCase for hooks (e.g., `useAuth.ts`).
17
+ - Imports: Use absolute paths (e.g., `@/components/...`) if the `tsconfig.json` or `vite.config.ts` supports it.
18
+ - State: Default to `useState` for local state; avoid adding global state libraries unless requested.
19
+
20
+ ## Reliability Protocol
21
+ - Before running any build or test command, check for the existence of `node_modules`. If missing, prompt to run `npm install`.
22
+ - When searching for code, use `search_files` with regex rather than trying to `grep` or `awk` through the terminal.
23
+ - If a command fails twice, STOP and report the exact error to the user rather than attempting a third "creative" bash one-liner.
24
+
25
+ # General app generation guidance
26
+
27
+ Your goal is to create a functioning app on Salesforce platform. Do not mock UIs, but use tools at your disposal, such as custom objects, graphql API, Apex controllers in order to achieve your goal.
28
+
29
+ **Home page must be populated:** The home page (root route) must never be left as the default template. Always populate it with real content—e.g. landing content, banners, tiles, hero, navigation to main features—tailored to the app or use case. Make it visually pleasing and purposeful. Do not leave placeholder or "Welcome to..." default content.
30
+
31
+ **Replace default boilerplate:** Always replace default scaffold content (e.g. "React App", "Vite + React", default page titles, placeholder headings in index.html or App.tsx) with **project- or app-specific** names and copy. Do not leave generic "React App" or template placeholders in the UI or document title.
32
+
33
+ **Navigation menu and placeholder name/design (critical — often missed):** **Build the navigation into the app layout** (`appLayout.tsx`) so every page shares the same nav. Always edit the **navigation menu** in that layout file: replace default nav items and labels with app-specific links and names; do not leave template "Home"/"About" or placeholder links. Always replace the **placeholder app name** in header, nav brand, footer, and `<title>` with the actual app name, and update **placeholder design** (header/footer/shell) so it's not the template default. See **webapp-nav-and-placeholders.md**.
34
+
35
+ **Frontend aesthetics (avoid AI slop):** Make creative, distinctive frontends that surprise and delight. Use distinctive typography (avoid Inter, Roboto, Arial, Space Grotesk as defaults), cohesive color with sharp accents (use CSS variables; avoid purple-on-white clichés), high-impact motion (e.g. staggered reveals), and atmosphere/depth in backgrounds. Do not converge on generic, cookie-cutter layouts. Follow **webapplications-design-system** expert knowledge for full guidance.
36
+
37
+ # SFDX React Web Application Creation
38
+
39
+ When the user asks to **create a React app** (or a web app, webpplication, etc) in this SFDX project:
40
+
41
+ 1. **Generate the app** using the Salesforce CLI:
42
+ \`\`\`bash
43
+ sf webapp generate -n MyWebApp -t reactbasic
44
+ \`\`\`
45
+ Use the app name the user requested instead of \`MyWebApp\` if they specify one.
46
+
47
+ Do not use \`create-react-app\`, Vite, or other generic React scaffolds for this scenario; use \`sf webapp generate\` so the app is SFDX-aware.
48
+
49
+ 2. **For B2B/B2C or authenticated/guest apps:** Also create site container metadata and create and configure Digital Experience Sites to host the React web application.
50
+
51
+ When modifying webapp in an SFDX project, use the experts MCP to obtain the latest guidance and design before starting implementation. Never assume or create tools that are not explicitly available
52
+
53
+ 3. Repeat iterations until the there are no pending actions left.
54
+
55
+
56
+ # Software development cycle (modified for continuous execution)
57
+
58
+ - Execute tasks continuously until all planned items are complete in the current iteration, without pausing after intermediate checkpoints.
59
+ - Maintain a running checklist and proceed through it sequentially.
60
+ - Quality gates (lint/build) remain required, but failures should be remediated inline and the workflow should continue through all feature tasks in this iteration unless the user directs otherwise.
61
+
62
+ ## Attempt Completion Enforcement (Local Project Rule)
63
+
64
+ - Do NOT invoke attempt_completion until ALL checklist items for the current iteration are complete and quality gates pass.
65
+ - Intermediate status updates must use task_progress on tool calls (never attempt_completion) until completion criteria are met.
66
+ - The only exceptions that allow early attempt_completion are:
67
+ - A blocking error that cannot be resolved after reasonable remediation and requires user input
68
+ - The user explicitly instructs to pause or complete early
69
+
70
+ ## Stop Conditions
71
+
72
+ Only stop when:
73
+ - All checklist items are completed and quality gates pass, or
74
+ - A blocking error cannot be resolved after reasonable remediation, or
75
+ - The user explicitly asks to pause.
package/dist/AGENT.md ADDED
@@ -0,0 +1,75 @@
1
+ # Agent guide: SFDX project with React web app
2
+
3
+ This project is a **Salesforce DX (SFDX) project** containing a **React web application**. The structure is generated; the app lives under `force-app/main/default/webapplications/<appName>/`. Use this file when working in this directory.
4
+
5
+ ## Project layout
6
+
7
+ - **Project root**: this directory — SFDX project root. Contains `sfdx-project.json`, `force-app/`, and (optionally) LWC/Aura.
8
+ - **React web app**: `force-app/main/default/webapplications/<appName>/`
9
+ - Replace `<appName>` with the actual app folder name (e.g. `base-react-app`, or the name chosen when the app was generated).
10
+ - Entry: `src/App.tsx`
11
+ - Routes: `src/routes.tsx`
12
+ - API/GraphQL: `src/api/` (e.g. `graphql.ts`, `graphql-operations-types.ts`, `utils/`)
13
+
14
+ Path convention: **webapplications** (lowercase).
15
+
16
+ ## Two package.json contexts
17
+
18
+ ### 1. Project root (this directory)
19
+
20
+ Used for SFDX metadata (LWC, Aura, etc.). Scripts here are for the base SFDX template:
21
+
22
+ | Command | Purpose |
23
+ |---------|---------|
24
+ | `npm run lint` | ESLint for `aura/` and `lwc/` |
25
+ | `npm run test` | LWC Jest (passWithNoTests) |
26
+ | `npm run prettier` | Format supported metadata files |
27
+ | `npm run prettier:verify` | Check Prettier |
28
+
29
+ Root **does not** run the React app. The root `npm run build` is a no-op for the base SFDX project.
30
+
31
+ ### 2. React web app (where you do most work)
32
+
33
+ **Always `cd` into the web app directory for dev/build/lint/test:**
34
+
35
+ ```bash
36
+ cd force-app/main/default/webapplications/<appName>
37
+ ```
38
+
39
+ | Command | Purpose |
40
+ |---------|---------|
41
+ | `npm run start` | Start Vite dev server |
42
+ | `npm run build` | TypeScript (`tsc -b`) + Vite build |
43
+ | `npm run lint` | ESLint for the React app |
44
+ | `npm run test` | Vitest |
45
+ | `npm run preview` | Preview production build |
46
+ | `npm run graphql:codegen` | Generate GraphQL types |
47
+ | `npm run graphql:schema` | Fetch GraphQL schema |
48
+
49
+ **Before finishing changes:** run `npm run build` and `npm run lint` from the web app directory; both must succeed.
50
+
51
+ ## Agent rules (.a4drules)
52
+
53
+ This project includes **.a4drules/** at the project root. Follow them when generating or editing code.
54
+
55
+ When rules refer to “web app directory” or `force-app/main/default/webapplications/<appName>/`, use the **actual app folder name** for this project.
56
+
57
+ ## Deploying
58
+
59
+ From **this project root**:
60
+
61
+ ```bash
62
+ # Build the React app first (replace <appName> with the app folder name)
63
+ cd force-app/main/default/webapplications/<appName> && npm i && npm run build && cd -
64
+
65
+ # Deploy web app only
66
+ sf project deploy start --source-dir force-app/main/default/webapplications --target-org <alias>
67
+
68
+ # Deploy all metadata
69
+ sf project deploy start --source-dir force-app --target-org <alias>
70
+ ```
71
+
72
+ ## Conventions (quick reference)
73
+
74
+ - **UI**: shadcn/ui + Tailwind. Import from `@/components/ui/...`.
75
+ - **Entry**: Keep `App.tsx` and routes in `src/`; add features as new routes or sections, don’t replace the app shell but you may modify it to match the requested design.
package/dist/CHANGELOG.md CHANGED
@@ -3,6 +3,22 @@
3
3
  All notable changes to this project will be documented in this file.
4
4
  See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.
5
5
 
6
+ ## [1.48.2](https://github.com/salesforce-experience-platform-emu/webapps/compare/v1.48.1...v1.48.2) (2026-02-23)
7
+
8
+ **Note:** Version bump only for package @salesforce/webapp-template-base-sfdx-project-experimental
9
+
10
+
11
+
12
+
13
+
14
+ ## [1.48.1](https://github.com/salesforce-experience-platform-emu/webapps/compare/v1.48.0...v1.48.1) (2026-02-21)
15
+
16
+ **Note:** Version bump only for package @salesforce/webapp-template-base-sfdx-project-experimental
17
+
18
+
19
+
20
+
21
+
6
22
  # [1.48.0](https://github.com/salesforce-experience-platform-emu/webapps/compare/v1.47.0...v1.48.0) (2026-02-20)
7
23
 
8
24
  **Note:** Version bump only for package @salesforce/webapp-template-base-sfdx-project-experimental
@@ -6575,24 +6575,24 @@
6575
6575
  }
6576
6576
  },
6577
6577
  "node_modules/@ts-morph/common/node_modules/balanced-match": {
6578
- "version": "4.0.3",
6579
- "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-4.0.3.tgz",
6580
- "integrity": "sha512-1pHv8LX9CpKut1Zp4EXey7Z8OfH11ONNH6Dhi2WDUt31VVZFXZzKwXcysBgqSumFCmR+0dqjMK5v5JiFHzi0+g==",
6578
+ "version": "4.0.4",
6579
+ "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-4.0.4.tgz",
6580
+ "integrity": "sha512-BLrgEcRTwX2o6gGxGOCNyMvGSp35YofuYzw9h1IMTRmKqttAZZVU67bdb9Pr2vUHA8+j3i2tJfjO6C6+4myGTA==",
6581
6581
  "license": "MIT",
6582
6582
  "engines": {
6583
- "node": "20 || >=22"
6583
+ "node": "18 || 20 || >=22"
6584
6584
  }
6585
6585
  },
6586
6586
  "node_modules/@ts-morph/common/node_modules/brace-expansion": {
6587
- "version": "5.0.2",
6588
- "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.2.tgz",
6589
- "integrity": "sha512-Pdk8c9poy+YhOgVWw1JNN22/HcivgKWwpxKq04M/jTmHyCZn12WPJebZxdjSa5TmBqISrUSgNYU3eRORljfCCw==",
6587
+ "version": "5.0.3",
6588
+ "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.3.tgz",
6589
+ "integrity": "sha512-fy6KJm2RawA5RcHkLa1z/ScpBeA762UF9KmZQxwIbDtRJrgLzM10depAiEQ+CXYcoiqW1/m96OAAoke2nE9EeA==",
6590
6590
  "license": "MIT",
6591
6591
  "dependencies": {
6592
6592
  "balanced-match": "^4.0.2"
6593
6593
  },
6594
6594
  "engines": {
6595
- "node": "20 || >=22"
6595
+ "node": "18 || 20 || >=22"
6596
6596
  }
6597
6597
  },
6598
6598
  "node_modules/@ts-morph/common/node_modules/minimatch": {
@@ -11573,9 +11573,9 @@
11573
11573
  }
11574
11574
  },
11575
11575
  "node_modules/hono": {
11576
- "version": "4.12.0",
11577
- "resolved": "https://registry.npmjs.org/hono/-/hono-4.12.0.tgz",
11578
- "integrity": "sha512-NekXntS5M94pUfiVZ8oXXK/kkri+5WpX2/Ik+LVsl+uvw+soj4roXIsPqO+XsWrAw20mOzaXOZf3Q7PfB9A/IA==",
11576
+ "version": "4.12.1",
11577
+ "resolved": "https://registry.npmjs.org/hono/-/hono-4.12.1.tgz",
11578
+ "integrity": "sha512-hi9afu8g0lfJVLolxElAZGANCTTl6bewIdsRNhaywfP9K8BPf++F2z6OLrYGIinUwpRKzbZHMhPwvc0ZEpAwGw==",
11579
11579
  "license": "MIT",
11580
11580
  "engines": {
11581
11581
  "node": ">=16.9.0"
@@ -4,7 +4,7 @@
4
4
  "version": "1.0.0",
5
5
  "type": "module",
6
6
  "scripts": {
7
- "dev": "vite",
7
+ "start": "vite",
8
8
  "build": "tsc -b && vite build",
9
9
  "build:e2e": "npm run build && node scripts/rewrite-e2e-assets.mjs",
10
10
  "lint": "eslint .",
package/dist/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@salesforce/webapp-template-base-sfdx-project-experimental",
3
- "version": "1.48.0",
3
+ "version": "1.48.2",
4
4
  "description": "Base SFDX project template",
5
5
  "private": true,
6
6
  "files": [
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@salesforce/webapp-template-feature-react-chart-experimental",
3
- "version": "1.48.0",
3
+ "version": "1.48.2",
4
4
  "description": "Chart feature with analytics chart components, agent skills, and rules (Recharts)",
5
5
  "license": "SEE LICENSE IN LICENSE.txt",
6
6
  "author": "",
@@ -27,7 +27,7 @@
27
27
  "clean": "rm -rf dist"
28
28
  },
29
29
  "devDependencies": {
30
- "@salesforce/webapp-experimental": "^1.48.0",
30
+ "@salesforce/webapp-experimental": "^1.48.2",
31
31
  "@types/react": "^19.2.7",
32
32
  "@types/react-dom": "^19.2.3",
33
33
  "react-dom": "^19.2.1",
@@ -46,10 +46,10 @@
46
46
  "build:dist-app": {
47
47
  "executor": "@salesforce/webapp-template-cli-experimental:build-dist-app"
48
48
  },
49
- "dev": {
49
+ "start": {
50
50
  "executor": "@salesforce/webapp-template-cli-experimental:dev-server"
51
51
  }
52
52
  }
53
53
  },
54
- "gitHead": "5ccfffec66505f70bdf4e6679e886c7bdabfe0ff"
54
+ "gitHead": "0b08119c77a0bac17a705ba303a89e4630a9b39f"
55
55
  }
@@ -1,66 +0,0 @@
1
- ---
2
- name: install-feature
3
- description: Install a feature into the current app. Use when the user asks to add a feature, capability, or functionality like authentication, search, charts, or navigation to their React web app. Do this when user wants to do _anything_ to webapplications/webapps.
4
- ---
5
-
6
- # Install feature
7
-
8
- When the user asks to add a feature to their app, follow this workflow.
9
-
10
- ## 1. Match the request to a feature
11
-
12
- Available features (npm packages):
13
-
14
-
15
- | Feature | Package | Description |
16
- | ---------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------- |
17
- | **Authentication** | `@salesforce/webapp-template-feature-react-authentication-experimental` | Login, register, password reset, protected routes |
18
- | **Global search** | `@salesforce/webapp-template-feature-react-global-search-experimental` | Search Salesforce objects with filters and pagination |
19
- | **Analytics charts** | `@salesforce/webapp-template-feature-react-chart-experimental` | Recharts line/bar charts with theming (AnalyticsChart, ChartContainer) |
20
- | **GraphQL data access**| `@salesforce/webapp-template-feature-graphql-experimental` | AI agent skills, rules, and docs for GraphQL development |
21
- | **Shared UI (shadcn)** | `@salesforce/webapp-template-feature-react-shadcn-experimental` | Button, Card, Input, Select, Table, Tabs, etc. |
22
- | **Micro frontends** | `@salesforce/webapp-template-feature-micro-frontend-experimental` | Embed an App into Salesforce UI
23
-
24
-
25
-
26
- If no feature matches, tell the user and offer to build it from scratch following the project's existing patterns.
27
-
28
- ## 2. Install the npm package
29
-
30
- ```bash
31
- npm install <package-name>
32
- ```
33
-
34
- ## 3. Copy skills and rules from the package
35
-
36
- Run the script so skills and rules from the package are copied into your project. Pass `[skills-dir]` and `[rules-dir]` for your environment; the script reports what it copied.
37
-
38
- ```bash
39
- # Default (e.g. Cline): .cline/skills, .clinerules
40
- bash <this-skill>/scripts/copy-feature-assets.sh <package-name>
41
-
42
- # Agentforce: .a4drules/ ([docs](https://developer.salesforce.com/docs/platform/einstein-for-devs/guide/devagent-rules.html))
43
- bash <this-skill>/scripts/copy-feature-assets.sh <package-name> .a4drules/skills .a4drules
44
-
45
- # Cursor: .cursor/skills, .cursor/rules
46
- bash <this-skill>/scripts/copy-feature-assets.sh <package-name> .cursor/skills .cursor/rules
47
- ```
48
-
49
- ## 4. Read the feature's exports and components
50
-
51
- Read the package's entry point (usually `index.ts` or the `main` field in its `package.json`) to understand what components and types it exports.
52
-
53
- Also read the `feature.ts` file if it exists — it lists dependencies on other features (e.g. shadcn) and any npm dependencies the feature needs (e.g. `recharts`). Install any missing dependencies.
54
-
55
- ## 5. Implement the feature in the current app
56
-
57
- - **If the package exports reusable components** (e.g. `AnalyticsChart`, `ChartContainer`): import and use them directly. Follow the package's README or skill instructions for props, data shapes, and usage patterns.
58
- - **If the package is a reference implementation** (e.g. authentication pages, search pages): read its source code under `src/` as a reference, then create equivalent pages/components in the current app following the app's existing patterns and conventions.
59
-
60
- Place new routes inside the existing app's router (e.g. `routes.tsx`). Do not replace the app shell; add the feature as new routes or sections within it.
61
-
62
- ## 6. Verify
63
-
64
- - Confirm the app builds without errors.
65
- - Confirm any new routes are accessible and render correctly.
66
-
@@ -1,36 +0,0 @@
1
- #!/usr/bin/env bash
2
- # Copies skills/ and rules/ from an installed npm package into the current project.
3
- # Usage: bash <this-script> <package-name> [skills-dir] [rules-dir]
4
- #
5
- # Examples:
6
- # bash copy-feature-assets.sh @salesforce/webapp-template-feature-graphql-experimental
7
- # bash copy-feature-assets.sh @salesforce/webapp-template-feature-graphql-experimental .cursor/skills .cursor/rules
8
- set -euo pipefail
9
-
10
- PKG="${1:?Usage: copy-feature-assets.sh <package-name> [skills-dir] [rules-dir]}"
11
- SKILLS_DIR="${2:-.cline/skills}"
12
- RULES_DIR="${3:-.clinerules}"
13
-
14
- PKG_DIR="node_modules/$PKG"
15
-
16
- if [ ! -d "$PKG_DIR" ]; then
17
- echo "Error: Package not found at $PKG_DIR" >&2
18
- echo "Run 'npm install $PKG' first." >&2
19
- exit 1
20
- fi
21
-
22
- if [ -d "$PKG_DIR/skills" ] && [ "$(ls -A "$PKG_DIR/skills")" ]; then
23
- mkdir -p "$SKILLS_DIR"
24
- cp -r "$PKG_DIR"/skills/* "$SKILLS_DIR"/
25
- echo "Copied skills → $SKILLS_DIR/"
26
- else
27
- echo "No skills/ found in $PKG_DIR — nothing to copy."
28
- fi
29
-
30
- if [ -d "$PKG_DIR/rules" ] && [ "$(ls -A "$PKG_DIR/rules")" ]; then
31
- mkdir -p "$RULES_DIR"
32
- cp -r "$PKG_DIR"/rules/* "$RULES_DIR"/
33
- echo "Copied rules → $RULES_DIR/"
34
- else
35
- echo "No rules/ found in $PKG_DIR — nothing to copy."
36
- fi