create-ec-app 1.4.0 → 1.5.0

package/README.md

@@ -54,24 +54,61 @@ bash update-templates.sh
 
 The script updates `package.patch.json` files, template `package.json` files, installs dependencies to refresh lockfiles, then removes template `node_modules` directories.
 
-## Generate A PCF Control
+## Generate a PCF Control
 
-After creating a webresource app, build it first so `dist/main.css` exists:
+If you want to host the React webresource inside a PCF control instead of loading the HTML webresource directly in an iframe, use `create-ec-app` itself to generate the wrapper for an existing webresource project.
+
+Basic flow:
+
+1. Build the webresource:
 
 ```bash
-cd my-app
 npm run build
 ```
 
-Then run the published CLI and install the generated PCF project's dependencies:
+2. Run the generator and point `--pcf-dir` at the generated PCF project directory:
 
 ```bash
 npx create-ec-app@latest --pcf-dir ./pcf/{{ControlName}} namespace {{EC}} --constructor {{ControlName}} --display-name "Control Name"
+```
+
+3. Install dependencies inside that generated PCF directory:
+
+```bash
 cd ./pcf/{{ControlName}}
 npm install
 ```
 
-This creates a PCF wrapper under the webresource project, reuses the app's built CSS, and keeps the generated app wrapped in `EcAppShell` so scoped styles and app-local portals continue to work inside the PCF host.
+This writes a standalone PCF project to the `--pcf-dir` folder. The generated control:
+
+- imports `src/App.tsx` directly instead of wrapping built HTML in an iframe
+- reuses the built stylesheet from `dist/main.css`
+- creates `src/runtime/types.ts` only if that file does not already exist
+- provides a runtime object with record context and `context.webAPI` access inside the generated PCF shell, following the `PcfBase` pattern
+- mounts your React app directly into the PCF container
+
+Typical conversion flow from inside a generated webresource project:
+
+```bash
+npm install
+npm run build
+npx create-ec-app@latest --pcf-dir ./pcf/FusionNotebookHost namespace EC --constructor FusionNotebookHost --display-name "Fusion Notebook Host"
+cd pcf/FusionNotebookHost
+npm install
+npm run build
+```
+
+What gets generated:
+
+- a minimal PCF wrapper project under `pcf/<ConstructorName>`
+- a checked-in PCF shell stamped out from `create-ec-app/templates/pcf/base`
+- direct imports back to your webresource source and built CSS
+
+What does not happen:
+
+- your existing webresource project is not converted in place
+- your React source is not moved into the PCF project
+- the generated PCF project does not automatically get added to a Dataverse solution
 
 ## Verification
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "create-ec-app",
-	"version": "1.4.0",
+	"version": "1.5.0",
 	"description": "Unified CLI tool to create different types of EC applications: Webresource, Portal, Power Pages",
 	"bin": {
 		"create-ec-app": "./dist/index.js"

package/templates/targets/webresource/AGENTS.md

@@ -3,6 +3,8 @@
 This is a Dynamics 365 / Dataverse web resource template using React + TypeScript + Vite.
 Treat it as a **Dynamics-hosted frontend** — not a generic SPA. Do not modernise it into something else unless explicitly asked.
 
+The default philosophy is: keep the app small, readable, and easy to ship into Dynamics. Prefer obvious code, existing components, and the template's established runtime patterns over broad abstractions or clever defensive layers.
+
 ---
 
 ## Hard Constraints
@@ -43,10 +45,13 @@ Never mix the two modes or duplicate their logic — reuse `authService.ts`.
 - Always reuse `getApiUrl()` and `getAuthHeaders()` — never duplicate them
 - Use narrow `$select` queries; throw on non-OK responses
 - No raw fetch calls scattered across UI components
+- Use Zod for validation where data crosses a boundary: form inputs, URL/search params, config, and Dataverse/API responses that the UI depends on
+- Keep service functions boring and explicit: one fetch function, one hook, one mutation where needed
+- Do not add repository/client layers unless the app has enough repeated API logic to justify them
 
 **Preferred pattern:**
 ```ts
-// service.ts — fetch function + TanStack Query hook
+// {entity}Service.ts — fetch function + TanStack Query hook
 // invalidate relevant queryKey on mutation success
 ```
 
@@ -65,21 +70,24 @@ See the example at the bottom of this file.
 
 ## UI & Styling
 
-- Kendo UI or Shadcn/ui — stay consistent with whichever the project uses; don't mix
-- Tailwind is the default styling approach; preserve `main.css` output
-- Reuse existing components and utilities before building new ones
+- Kendo UI or Shadcn/ui — stay consistent with whichever the project uses; don't mix UI systems unless explicitly asked.
+- If the project uses Shadcn/ui, use Shadcn components from `@/components/ui` and style them with Tailwind utility classes.
+- If the project uses Kendo UI, use Kendo React components for controls, grids, menus, dialogs, inputs, and other rich UI. Use Tailwind for layout, spacing, and local composition around those components.
+- Tailwind is the default styling approach for both Shadcn/ui and Kendo projects; preserve `main.css` output.
+- Do not hand-roll component styling or custom CSS unless Tailwind/component props cannot reasonably express the requirement.
+- Prefer existing component APIs, theme tokens, variants, and utility helpers before creating new wrappers.
+- Keep screen layouts practical for embedded Dynamics use: compact, scannable, responsive, and not marketing-page styled.
 
 ---
 
-## Planning Rule
-
-For changes touching multiple files, auth, build config, or new service patterns — write a short plan first:
-- current state
-- intended change
-- files to touch
-- risks / compatibility concerns
+## Code Shape
 
-For large or risky changes, write an `ExecPlan` in `PLANS.md` before implementing.
+- Keep code simple and readable. A future maintainer should understand the main path quickly.
+- Avoid over-engineering: no generic frameworks, broad factories, speculative abstractions, or excessive configuration for small features.
+- Avoid being overly defensive. Validate real external inputs and API responses where useful, but don't wrap every local value in ceremony.
+- Prefer direct, typed functions over classes unless the existing code already uses classes for that concern.
+- Keep React components focused: UI in components, reusable data access in services, shared client state in Zustand only when local state is no longer enough.
+- Make the smallest change that solves the request cleanly.
 
 ---
 
@@ -120,4 +128,4 @@ export const useUpdateAccount = () => {
     onSuccess: () => queryClient.invalidateQueries({ queryKey: ["accounts"] }),
   });
 };
-```
+```

package/templates/targets/webresource/README.md

@@ -302,33 +302,12 @@ npm install
 npm run build
 ```
 
-Useful options:
-
-- `--dist dist` to point at a different build folder
-- `--output pcf/MyControl` to choose the target folder
-- `--template /path/to/create-ec-app/templates/pcf/base` to swap the base shell
-- `--layer path/to/layer` to apply one or more patch layers after the base copy
-
-Build the generated PCF project from inside the generated folder:
-
-```bash
-cd pcf/FusionNotebookHost
-npm install
-npm run build
-```
-
 What gets generated:
 
 - a minimal PCF wrapper project under `pcf/<ConstructorName>`
 - a checked-in PCF shell stamped out from `create-ec-app/templates/pcf/base`
 - direct imports back to your webresource source and built CSS
 
-What does not happen:
-
-- your existing webresource project is not converted in place
-- your React source is not moved into the PCF project
-- the generated PCF project does not automatically get added to a Dataverse solution
-
 ## Notes
 
 - If you change the build, ensure code splitting stays disabled and asset names remain predictable to simplify web resource updates.

package/templates/targets/webresource/CLAUDE.md

@@ -1 +0,0 @@
-[AGENTS.md](AGENTS.md)