@salesforce/webapp-template-app-react-sample-b2e-experimental 1.92.1 → 1.93.1

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.
@@ -0,0 +1,396 @@
1
+ ---
2
+ name: feature-react-file-upload-file-upload
3
+ description: Add file upload functionality to React webapps with progress tracking and Salesforce ContentVersion integration. Use when the user wants to upload files, attach documents, handle file input, create file dropzones, track upload progress, or link files to Salesforce records. This feature provides programmatic APIs ONLY — no components or hooks are exported. Build your own custom UI using the upload() API. ALWAYS use this feature instead of building file upload from scratch with FormData or XHR.
4
+ ---
5
+
6
+ # File Upload API (workflow)
7
+
8
+ When the user wants file upload functionality in a React webapp, follow this workflow. This feature provides **APIs only** — you must build the UI components yourself using the provided APIs.
9
+
10
+ ## CRITICAL: This is an API-only package
11
+
12
+ The package exports **programmatic APIs**, not React components or hooks. You will:
13
+
14
+ - Use the `upload()` function to handle file uploads with progress tracking
15
+ - Build your own custom UI (file input, dropzone, progress bars, etc.)
16
+ - Track upload progress through the `onProgress` callback
17
+
18
+ **Do NOT:**
19
+
20
+ - Expect pre-built components like `<FileUpload />` — they are not exported
21
+ - Try to import React hooks like `useFileUpload` — they are not exported
22
+ - Look for dropzone components — they are not exported
23
+
24
+ The source code contains reference components for demonstration, but they are **not available** as imports. Use them as examples to build your own UI.
25
+
26
+ ## 1. Install the package
27
+
28
+ ```bash
29
+ npm install @salesforce/webapp-template-feature-react-file-upload-experimental
30
+ ```
31
+
32
+ Dependencies are automatically installed:
33
+
34
+ - `@salesforce/webapp-experimental` (API client)
35
+ - `@salesforce/sdk-data` (data SDK)
36
+
37
+ ## 2. Understand the three upload patterns
38
+
39
+ ### Pattern A: Basic upload (no record linking)
40
+
41
+ Upload files to Salesforce and get back `contentBodyId` for each file. No ContentVersion record is created.
42
+
43
+ **When to use:**
44
+
45
+ - User wants to upload files first, then create/link them to a record later
46
+ - Building a multi-step form where the record doesn't exist yet
47
+ - Deferred record linking scenarios
48
+
49
+ ```tsx
50
+ import { upload } from "@salesforce/webapp-template-feature-react-file-upload-experimental";
51
+
52
+ const results = await upload({
53
+ files: [file1, file2],
54
+ onProgress: (progress) => {
55
+ console.log(`${progress.fileName}: ${progress.status} - ${progress.progress}%`);
56
+ },
57
+ });
58
+
59
+ // results[0].contentBodyId: "069..." (always available)
60
+ // results[0].contentVersionId: undefined (no record linked)
61
+ ```
62
+
63
+ ### Pattern B: Upload with immediate record linking
64
+
65
+ Upload files and immediately link them to an existing Salesforce record by creating ContentVersion records.
66
+
67
+ **When to use:**
68
+
69
+ - Record already exists (Account, Opportunity, Case, etc.)
70
+ - User wants files immediately attached to the record
71
+ - Direct upload-and-attach scenarios
72
+
73
+ ```tsx
74
+ import { upload } from "@salesforce/webapp-template-feature-react-file-upload-experimental";
75
+
76
+ const results = await upload({
77
+ files: [file1, file2],
78
+ recordId: "001xx000000yyyy", // Existing record ID
79
+ onProgress: (progress) => {
80
+ console.log(`${progress.fileName}: ${progress.status} - ${progress.progress}%`);
81
+ },
82
+ });
83
+
84
+ // results[0].contentBodyId: "069..." (always available)
85
+ // results[0].contentVersionId: "068..." (linked to record)
86
+ ```
87
+
88
+ ### Pattern C: Deferred record linking (record creation flow)
89
+
90
+ Upload files without a record, then link them after the record is created.
91
+
92
+ **When to use:**
93
+
94
+ - Building a "create record with attachments" form
95
+ - Record doesn't exist until form submission
96
+ - Need to upload files before knowing the final record ID
97
+
98
+ ```tsx
99
+ import {
100
+ upload,
101
+ createContentVersion,
102
+ } from "@salesforce/webapp-template-feature-react-file-upload-experimental";
103
+
104
+ // Step 1: Upload files (no recordId)
105
+ const uploadResults = await upload({
106
+ files: [file1, file2],
107
+ onProgress: (progress) => console.log(progress),
108
+ });
109
+
110
+ // Step 2: Create the record
111
+ const newRecordId = await createRecord(formData);
112
+
113
+ // Step 3: Link uploaded files to the new record
114
+ for (const file of uploadResults) {
115
+ const contentVersionId = await createContentVersion(
116
+ new File([""], file.fileName),
117
+ file.contentBodyId,
118
+ newRecordId,
119
+ );
120
+ }
121
+ ```
122
+
123
+ ## 3. Build your custom UI
124
+
125
+ The package provides the backend — you build the frontend. Here's a minimal example:
126
+
127
+ ```tsx
128
+ import {
129
+ upload,
130
+ type FileUploadProgress,
131
+ } from "@salesforce/webapp-template-feature-react-file-upload-experimental";
132
+ import { useState } from "react";
133
+
134
+ function CustomFileUpload({ recordId }: { recordId?: string }) {
135
+ const [progress, setProgress] = useState<Map<string, FileUploadProgress>>(new Map());
136
+
137
+ const handleFileSelect = async (event: React.ChangeEvent<HTMLInputElement>) => {
138
+ const files = Array.from(event.target.files || []);
139
+
140
+ await upload({
141
+ files,
142
+ recordId,
143
+ onProgress: (fileProgress) => {
144
+ setProgress((prev) => new Map(prev).set(fileProgress.fileName, fileProgress));
145
+ },
146
+ });
147
+ };
148
+
149
+ return (
150
+ <div>
151
+ <input type="file" multiple onChange={handleFileSelect} />
152
+
153
+ {Array.from(progress.entries()).map(([fileName, fileProgress]) => (
154
+ <div key={fileName}>
155
+ {fileName}: {fileProgress.status} - {fileProgress.progress}%
156
+ {fileProgress.error && <span>Error: {fileProgress.error}</span>}
157
+ </div>
158
+ ))}
159
+ </div>
160
+ );
161
+ }
162
+ ```
163
+
164
+ ## 4. Track upload progress
165
+
166
+ The `onProgress` callback fires multiple times for each file as it moves through stages:
167
+
168
+ | Status | When | Progress Value |
169
+ | -------------- | ---------------------------------------------- | -------------------- |
170
+ | `"pending"` | File queued for upload | `0` |
171
+ | `"uploading"` | Upload in progress (XHR) | `0-100` (percentage) |
172
+ | `"processing"` | Creating ContentVersion (if recordId provided) | `0` |
173
+ | `"success"` | Upload complete | `100` |
174
+ | `"error"` | Upload failed | `0` |
175
+
176
+ **Always provide visual feedback:**
177
+
178
+ - Show file name
179
+ - Display current status
180
+ - Render progress bar for "uploading" status
181
+ - Show error message if status is "error"
182
+
183
+ ## 5. Cancel uploads (optional)
184
+
185
+ Use an `AbortController` to allow users to cancel uploads:
186
+
187
+ ```tsx
188
+ const abortController = new AbortController();
189
+
190
+ const handleUpload = async (files: File[]) => {
191
+ try {
192
+ await upload({
193
+ files,
194
+ signal: abortController.signal,
195
+ onProgress: (progress) => console.log(progress),
196
+ });
197
+ } catch (error) {
198
+ console.error("Upload cancelled or failed:", error);
199
+ }
200
+ };
201
+
202
+ const cancelUpload = () => {
203
+ abortController.abort();
204
+ };
205
+ ```
206
+
207
+ ## 6. Link to current user (special case)
208
+
209
+ If the user wants to upload files to their own profile or personal library:
210
+
211
+ ```tsx
212
+ import {
213
+ upload,
214
+ getCurrentUserId,
215
+ } from "@salesforce/webapp-template-feature-react-file-upload-experimental";
216
+
217
+ const userId = await getCurrentUserId();
218
+ await upload({ files, recordId: userId });
219
+ ```
220
+
221
+ ## API Reference
222
+
223
+ ### upload(options)
224
+
225
+ Main upload API that handles complete flow with progress tracking.
226
+
227
+ ```typescript
228
+ interface UploadOptions {
229
+ files: File[];
230
+ recordId?: string | null; // If provided, creates ContentVersion
231
+ onProgress?: (progress: FileUploadProgress) => void;
232
+ signal?: AbortSignal; // Optional cancellation
233
+ }
234
+
235
+ interface FileUploadProgress {
236
+ fileName: string;
237
+ status: "pending" | "uploading" | "processing" | "success" | "error";
238
+ progress: number; // 0-100 for uploading, 0 for other states
239
+ error?: string;
240
+ }
241
+
242
+ interface FileUploadResult {
243
+ fileName: string;
244
+ size: number;
245
+ contentBodyId: string; // Always available
246
+ contentVersionId?: string; // Only if recordId was provided
247
+ }
248
+ ```
249
+
250
+ **Returns:** `Promise<FileUploadResult[]>`
251
+
252
+ ### createContentVersion(file, contentBodyId, recordId)
253
+
254
+ Manually create a ContentVersion record from a previously uploaded file.
255
+
256
+ ```typescript
257
+ async function createContentVersion(
258
+ file: File,
259
+ contentBodyId: string,
260
+ recordId: string,
261
+ ): Promise<string | undefined>;
262
+ ```
263
+
264
+ **Parameters:**
265
+
266
+ - `file` — File object (used for metadata like name)
267
+ - `contentBodyId` — ContentBody ID from previous upload
268
+ - `recordId` — Record ID for FirstPublishLocationId
269
+
270
+ **Returns:** ContentVersion ID if successful
271
+
272
+ ### getCurrentUserId()
273
+
274
+ Get the current user's Salesforce ID.
275
+
276
+ ```typescript
277
+ async function getCurrentUserId(): Promise<string>;
278
+ ```
279
+
280
+ **Returns:** Current user ID
281
+
282
+ ## Common UI patterns
283
+
284
+ ### File input with button
285
+
286
+ ```tsx
287
+ <input type="file" multiple accept=".pdf,.doc,.docx,.jpg,.png" onChange={handleFileSelect} />
288
+ ```
289
+
290
+ ### Drag-and-drop zone
291
+
292
+ Build your own dropzone using native events:
293
+
294
+ ```tsx
295
+ function DropZone({ onDrop }: { onDrop: (files: File[]) => void }) {
296
+ const handleDrop = (e: React.DragEvent) => {
297
+ e.preventDefault();
298
+ const files = Array.from(e.dataTransfer.files);
299
+ onDrop(files);
300
+ };
301
+
302
+ return (
303
+ <div
304
+ onDrop={handleDrop}
305
+ onDragOver={(e) => e.preventDefault()}
306
+ style={{ border: "2px dashed #ccc", padding: "2rem" }}
307
+ >
308
+ Drop files here
309
+ </div>
310
+ );
311
+ }
312
+ ```
313
+
314
+ ### Progress bar
315
+
316
+ ```tsx
317
+ {
318
+ progress.status === "uploading" && (
319
+ <div style={{ width: "100%", background: "#eee" }}>
320
+ <div
321
+ style={{
322
+ width: `${progress.progress}%`,
323
+ background: "#0176d3",
324
+ height: "8px",
325
+ }}
326
+ />
327
+ </div>
328
+ );
329
+ }
330
+ ```
331
+
332
+ ## Decision tree for agents
333
+
334
+ **User asks for file upload functionality:**
335
+
336
+ 1. **Ask about record context:**
337
+ - "Do you want to link uploaded files to a specific record, or upload them first and link later?"
338
+
339
+ 2. **Based on response:**
340
+ - **Link to existing record** → Use Pattern B with `recordId`
341
+ - **Upload first, link later** → Use Pattern A (no recordId), then Pattern C for linking
342
+ - **Link to current user** → Use Pattern B with `getCurrentUserId()`
343
+
344
+ 3. **Build the UI:**
345
+ - Create file input or dropzone (not provided by package)
346
+ - Add progress display for each file (status + progress bar)
347
+ - Handle errors in the UI
348
+
349
+ 4. **Test the implementation:**
350
+ - Verify progress callbacks fire correctly
351
+ - Check that `contentBodyId` is returned
352
+ - If `recordId` was provided, verify `contentVersionId` is returned
353
+
354
+ ## Reference implementation
355
+
356
+ The package includes a reference implementation in `src/features/fileupload/` with:
357
+
358
+ - `FileUpload.tsx` — Complete component with dropzone and dialog
359
+ - `FileUploadDialog.tsx` — Progress tracking dialog
360
+ - `FileUploadDropZone.tsx` — Drag-and-drop zone
361
+ - `useFileUpload.ts` — React hook for state management
362
+
363
+ **These are NOT exported** but can be viewed as examples. Read the source files to understand patterns for building your own UI.
364
+
365
+ ## Troubleshooting
366
+
367
+ **Upload fails with CORS error:**
368
+
369
+ - Ensure the webapp is properly deployed to Salesforce or running on `localhost`
370
+ - Check that the org allows the origin in CORS settings
371
+
372
+ **No progress updates:**
373
+
374
+ - Verify `onProgress` callback is provided
375
+ - Check that the callback function updates React state correctly
376
+
377
+ **ContentVersion not created:**
378
+
379
+ - Verify `recordId` is provided to `upload()` function
380
+ - Check that the record ID is valid and exists in the org
381
+ - Ensure user has permissions to create ContentVersion records
382
+
383
+ **Files upload but don't appear in record:**
384
+
385
+ - Verify `recordId` is correct
386
+ - Check that ContentVersion was created (look for `contentVersionId` in results)
387
+ - Confirm user has access to view files on the record
388
+
389
+ ## DO NOT do these things
390
+
391
+ - ❌ Build XHR/fetch upload logic from scratch — use the `upload()` API
392
+ - ❌ Try to import `<FileUpload />` component — it's not exported
393
+ - ❌ Try to import `useFileUpload` hook — it's not exported
394
+ - ❌ Use third-party file upload libraries when this feature exists
395
+ - ❌ Skip progress tracking — always provide user feedback
396
+ - ❌ Ignore errors — always handle and display error messages
@@ -0,0 +1,88 @@
1
+ ---
2
+ description: CLI command generation rules — no node -e one-liners; safe quoting and scripts
3
+ paths:
4
+ - "**/webapplications/**/*"
5
+ ---
6
+
7
+ # A4D Enforcement: CLI Command Generation & No `node -e` One-Liners
8
+
9
+ When **generating any CLI/shell commands** (for the user or for automation), follow the rules below. Default shell is **Zsh** (macOS); commands must work there without Bash-only syntax.
10
+
11
+ ---
12
+
13
+ ## 1. Never Use Complex `node -e` One-Liners
14
+
15
+ **Forbidden:** `node -e` (or `node -p`, `node --eval`) for file manipulation, string replacement, reading/writing configs, or multi-line logic.
16
+
17
+ **Why:** In Zsh, `node -e '...'` **silently breaks** due to:
18
+ - **`!` (history expansion):** Zsh expands `!` in double-quoted strings → `event not found` or wrong output.
19
+ - **Backticks:** `` ` `` is command substitution; the shell runs it before Node sees the string.
20
+ - **Nested quoting:** Escaping differs between Bash and Zsh; multi-line JS in one string is fragile.
21
+
22
+ **Allowed:** Trivial one-line only if it has **no** backticks, no `!`, no nested quotes, no multi-line, no `fs` usage. Example: `node -e "console.log(1+1)"`. If in doubt, **use a script file**.
23
+
24
+ ---
25
+
26
+ ## 2. How To Generate CLI Commands Correctly
27
+
28
+ ### Run Node scripts by path, not inline code
29
+
30
+ - **Do:** `node scripts/setup-cli.mjs --target-org myorg`
31
+ - **Do:** `node path/to/script.mjs arg1 arg2`
32
+ - **Do not:** `node -e "require('fs').writeFileSync(...)"` or any non-trivial inline JS.
33
+
34
+ ### For file edits or transforms
35
+
36
+ 1. **Prefer IDE/agent file tools** (StrReplace, Write, etc.) — they avoid the shell.
37
+ 2. **Otherwise:** write a **temporary `.js` or `.mjs` file**, run it, then remove it. Use a **heredoc with quoted delimiter** so the shell does not interpret `$`, `` ` ``, or `!`:
38
+
39
+ ```bash
40
+ cat > /tmp/_transform.js << 'SCRIPT'
41
+ const fs = require('fs');
42
+ const data = JSON.parse(fs.readFileSync('package.json', 'utf8'));
43
+ data.name = 'my-app';
44
+ fs.writeFileSync('package.json', JSON.stringify(data, null, 2) + '\n');
45
+ SCRIPT
46
+ node /tmp/_transform.js && rm /tmp/_transform.js
47
+ ```
48
+
49
+ 3. **Simple replacements:** `sed -i '' 's/old/new/g' path/to/file` (macOS: `-i ''`).
50
+ 4. **JSON:** `jq '.name = "my-app"' package.json > tmp.json && mv tmp.json package.json`.
51
+
52
+ ### Quoting and shell safety
53
+
54
+ - Use **single quotes** around the outer shell string when the inner content has `$`, `` ` ``, or `!`.
55
+ - For heredocs that must be literal, use **`<< 'END'`** (quoted delimiter) so the body is not expanded.
56
+ - **Do not** generate commands that rely on Bash-only features (e.g. `[[ ]]` is fine in Zsh; avoid `source` vs `.` if you need POSIX).
57
+
58
+ ### Paths and working directory
59
+
60
+ - **State where to run from** when it matters, e.g. "From project root" or "From `force-app/main/default/webapplications/<appName>`".
61
+ - Prefer **explicit paths** or `cd <dir> && ...` so the command is copy-paste safe.
62
+ - This project: setup is `node scripts/setup-cli.mjs --target-org <alias>` from **project root**. Web app commands (`npm run dev`, `npm run build`, `npm run lint`) run from the **web app directory** (e.g. `force-app/main/default/webapplications/<appName>` or `**/webapplications/<appName>`).
63
+
64
+ ### npm / npx
65
+
66
+ - Use **exact package names** (e.g. `npx @salesforce/webapps-features-experimental list`).
67
+ - For app-specific scripts, **cd to the web app directory first**, then run `npm run <script>` or `npm install ...`.
68
+ - Chain steps with `&&`; one logical command per line is clearer than one giant line.
69
+
70
+ ### Summary checklist when generating a command
71
+
72
+ - [ ] No `node -e` / `node -p` / `node --eval` with complex or multi-line code.
73
+ - [ ] If Node logic is needed, use `node path/to/script.mjs` or a temp script with heredoc `<< 'SCRIPT'`.
74
+ - [ ] No unescaped `!`, `` ` ``, or `$` in double-quoted strings in Zsh.
75
+ - [ ] Working directory and required args (e.g. `--target-org`) are clear.
76
+ - [ ] Prefer file-editing tools over shell one-liners when editing project files.
77
+
78
+ ---
79
+
80
+ ## 3. Violation Handling
81
+
82
+ - If a generated command used a complex `node -e` one-liner, **revert and redo** using a script file, `sed`/`jq`, or IDE file tools.
83
+ - If the user sees `event not found`, `unexpected token`, or garbled output, **check for**:
84
+ - `node -e` with special characters,
85
+ - Double-quoted strings containing `!` or backticks,
86
+ - Wrong working directory or missing args.
87
+
88
+ **Cross-reference:** **webapp.md** (MUST FOLLOW #1) summarizes the no–`node -e` rule; this file is the full reference for CLI command generation and alternatives.
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  description: Code quality and build validation standards
3
3
  paths:
4
- - "force-app/main/default/webapplications/**/*"
4
+ - "**/webapplications/**/*"
5
5
  ---
6
6
 
7
7
  # Code Quality & Build Validation
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  description: Strict TypeScript standards for type-safe React applications
3
3
  paths:
4
- - "force-app/main/default/webapplications/**/*"
4
+ - "**/webapplications/**/*"
5
5
  ---
6
6
 
7
7
  # TypeScript Standards
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  description: React-specific patterns and Salesforce data access for SFDX web apps
3
3
  paths:
4
- - "force-app/main/default/webapplications/**/*"
4
+ - "**/webapplications/**/*"
5
5
  ---
6
6
 
7
7
  # React Web App (SFDX)
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  description: Always search for and read relevant skills before starting any task
3
3
  paths:
4
- - "force-app/main/default/webapplications/**/*"
4
+ - "**/webapplications/**/*"
5
5
  ---
6
6
 
7
7
  # Skills-First Protocol (MUST FOLLOW)
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  description: Core web application rules for SFDX React apps
3
3
  paths:
4
- - "force-app/main/default/webapplications/**/*"
4
+ - "**/webapplications/**/*"
5
5
  ---
6
6
 
7
7
  # Skills-First (MUST FOLLOW)
@@ -81,7 +81,7 @@ Agents consistently miss these. **You must not leave them default.**
81
81
 
82
82
  # Shell Command Safety (MUST FOLLOW)
83
83
 
84
- **Never use complex `node -e` one-liners** for file edits or multi-line transforms. They break in Zsh due to `!` history expansion and backtick interpolation. Use a temporary `.js` file, `sed`/`awk`, `jq`, or IDE file-editing tools instead. See **webapp-no-node-e.md** for full details and approved alternatives.
84
+ **Never use complex `node -e` one-liners** for file edits or multi-line transforms. They break in Zsh due to `!` history expansion and backtick interpolation. Use a temporary `.js` file, `sed`/`awk`, `jq`, or IDE file-editing tools instead. See **webapp-cli-commands.md** for full details and approved alternatives.
85
85
 
86
86
  # Development Cycle
87
87
 
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.93.1](https://github.com/salesforce-experience-platform-emu/webapps/compare/v1.93.0...v1.93.1) (2026-03-12)
7
+
8
+ **Note:** Version bump only for package @salesforce/webapp-template-base-sfdx-project-experimental
9
+
10
+
11
+
12
+
13
+
14
+ # [1.93.0](https://github.com/salesforce-experience-platform-emu/webapps/compare/v1.92.1...v1.93.0) (2026-03-11)
15
+
16
+ **Note:** Version bump only for package @salesforce/webapp-template-base-sfdx-project-experimental
17
+
18
+
19
+
20
+
21
+
6
22
  ## [1.92.1](https://github.com/salesforce-experience-platform-emu/webapps/compare/v1.92.0...v1.92.1) (2026-03-11)
7
23
 
8
24
 
@@ -15,9 +15,9 @@
15
15
  "graphql:schema": "node scripts/get-graphql-schema.mjs"
16
16
  },
17
17
  "dependencies": {
18
- "@salesforce/agentforce-conversation-client": "^1.92.1",
19
- "@salesforce/sdk-data": "^1.92.1",
20
- "@salesforce/webapp-experimental": "^1.92.1",
18
+ "@salesforce/agentforce-conversation-client": "^1.93.1",
19
+ "@salesforce/sdk-data": "^1.93.1",
20
+ "@salesforce/webapp-experimental": "^1.93.1",
21
21
  "@tailwindcss/vite": "^4.1.17",
22
22
  "@tanstack/react-form": "^1.28.4",
23
23
  "class-variance-authority": "^0.7.1",
@@ -42,7 +42,7 @@
42
42
  "@graphql-eslint/eslint-plugin": "^4.1.0",
43
43
  "@graphql-tools/utils": "^11.0.0",
44
44
  "@playwright/test": "^1.49.0",
45
- "@salesforce/vite-plugin-webapp-experimental": "^1.92.1",
45
+ "@salesforce/vite-plugin-webapp-experimental": "^1.93.1",
46
46
  "@testing-library/jest-dom": "^6.6.3",
47
47
  "@testing-library/react": "^16.1.0",
48
48
  "@testing-library/user-event": "^14.5.2",
package/dist/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@salesforce/webapp-template-base-sfdx-project-experimental",
3
- "version": "1.92.1",
3
+ "version": "1.93.1",
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-app-react-sample-b2e-experimental",
3
- "version": "1.92.1",
3
+ "version": "1.93.1",
4
4
  "description": "B2E starter app template",
5
5
  "license": "SEE LICENSE IN LICENSE.txt",
6
6
  "author": "",
@@ -16,8 +16,8 @@
16
16
  "clean": "rm -rf dist"
17
17
  },
18
18
  "dependencies": {
19
- "@salesforce/webapp-experimental": "^1.92.1",
20
- "@salesforce/webapp-template-feature-react-global-search-experimental": "^1.92.1"
19
+ "@salesforce/webapp-experimental": "^1.93.1",
20
+ "@salesforce/webapp-template-feature-react-global-search-experimental": "^1.93.1"
21
21
  },
22
22
  "devDependencies": {
23
23
  "@testing-library/jest-dom": "^6.6.3",
@@ -1,65 +0,0 @@
1
- ---
2
- description: No complex node -e one-liners — use temp .js files or sed/awk instead
3
- paths:
4
- - "force-app/main/default/webapplications/**/*"
5
- ---
6
-
7
- # A4D Enforcement: No `node -e` One-Liners
8
-
9
- This project **forbids** using `node -e` (or `node -p`, `node --eval`) one-liners for any operation—file manipulation, string replacement, reading/writing configs, or shell automation.
10
-
11
- ## Why This Exists
12
-
13
- Complex `node -e '...'` one-liners **silently break in Zsh** (the default macOS shell) because of:
14
-
15
- - **`!` (history expansion):** Zsh interprets `!` inside double quotes as history expansion, causing `event not found` errors or silent corruption.
16
- - **Backtick interpolation:** Template literals (`` ` ``) are interpreted as command substitution by the shell before Node.js ever sees them.
17
- - **Nested quoting:** Multi-line JS crammed into a single shell string requires fragile quote escaping that differs between Bash and Zsh.
18
-
19
- These failures are **silent and intermittent**—the command may appear to succeed while producing corrupt output.
20
-
21
- ## What To Do Instead
22
-
23
- ### For multi-line file edits or transforms
24
-
25
- 1. **Write a temporary `.js` script**, run it, then delete it:
26
-
27
- ```bash
28
- cat > /tmp/_transform.js << 'SCRIPT'
29
- const fs = require('fs');
30
- const data = JSON.parse(fs.readFileSync('package.json', 'utf8'));
31
- data.name = 'my-app';
32
- fs.writeFileSync('package.json', JSON.stringify(data, null, 2) + '\n');
33
- SCRIPT
34
- node /tmp/_transform.js && rm /tmp/_transform.js
35
- ```
36
-
37
- 2. **Use `sed` or `awk`** for simple, single-pattern replacements with careful escaping:
38
-
39
- ```bash
40
- sed -i '' 's/old-value/new-value/g' path/to/file
41
- ```
42
-
43
- 3. **Use `jq`** for JSON edits:
44
-
45
- ```bash
46
- jq '.name = "my-app"' package.json > tmp.json && mv tmp.json package.json
47
- ```
48
-
49
- 4. **Use the IDE/agent file-editing tools** (replace_in_file, write_to_file, StrReplace, Write) whenever available—these bypass the shell entirely.
50
-
51
- ### For simple, truly one-line expressions
52
-
53
- A trivial `node -e "console.log(1+1)"` with no special characters is acceptable, but **if the expression contains any of these, use a temp file instead:**
54
- - Template literals (backticks)
55
- - `!` characters
56
- - Nested quotes
57
- - Multi-line strings
58
- - `fs` read/write operations
59
-
60
- ## Violation Handling
61
-
62
- - If any prior step used a complex `node -e` one-liner, **revert and redo** using one of the approved methods above.
63
- - If a shell command fails with `event not found`, `unexpected token`, or produces garbled output, check for a `node -e` violation first.
64
-
65
- **Cross-reference:** This rule is also summarized in **webapp.md** (MUST FOLLOW #1). Both apply.