zudojs-cli 2.0.0 → 2.0.1

package/README.md

@@ -133,8 +133,16 @@ current directory.
 Where a schematic lands depends on the architecture: a `monolith` puts
 services in `src/services` and modules in `src/modules`; a
 `modular-monolith` has modules only, so `generate service` there generates a
-module; in a `microservice` project a schematic goes to the gateway app, or
-to `apps/services/<name>` with `--service <name>`.
+module and registers it in `app.ts`; in a `microservice` project a schematic
+goes to the gateway app, or to `apps/services/<name>` with `--service <name>`.
+
+`generate service` is **refused** in a microservice project. A service there is
+a whole workspace app — its own `package.json`, `tsconfig.json`, `Dockerfile`
+and port — which the schematic does not produce; it used to write a bare class
+into a directory pnpm skipped and no build compiled. Create services with
+`zudojs create <project> --architecture microservice --services <names>`, and
+add domain logic to an existing app with
+`zudojs generate module <name> --service <existing-service>`.
 
 ## Commands
 

package/dist/src/templates/microservice/microservice.template.d.ts

@@ -37,7 +37,10 @@ export declare const RESERVED_MICROSERVICE_APP_NAMES: readonly ["gateway"];
  * (`identity`, `enrollment`, `assessment`, `notification`), which put four
  * domains nobody asked for into every microservice project and left the
  * author deleting them before they could start. Services are created when
- * they are named — here, or later with `zudojs generate service <name>`.
+ * they are named — here, or in another `create` run. `generate service` is
+ * refused in a microservice project, because a service is a whole workspace
+ * app (package.json, tsconfig, Dockerfile, port) that the schematic does not
+ * produce; `generate module --service <name>` adds to an existing app.
  */
 export declare function resolveMicroserviceServices(requested: readonly string[]): readonly string[];
 export declare function generateMicroserviceFiles(options: ScaffoldOptions): Record<string, string>;

package/dist/src/templates/microservice/microservice.template.js

@@ -39,7 +39,10 @@ export const RESERVED_MICROSERVICE_APP_NAMES = ["gateway"];
  * (`identity`, `enrollment`, `assessment`, `notification`), which put four
  * domains nobody asked for into every microservice project and left the
  * author deleting them before they could start. Services are created when
- * they are named — here, or later with `zudojs generate service <name>`.
+ * they are named — here, or in another `create` run. `generate service` is
+ * refused in a microservice project, because a service is a whole workspace
+ * app (package.json, tsconfig, Dockerfile, port) that the schematic does not
+ * produce; `generate module --service <name>` adds to an existing app.
  */
 export function resolveMicroserviceServices(requested) {
     const normalized = requested
@@ -158,10 +161,17 @@ A microservice architecture built with the Zudojs framework.
 ${services.length > 0
         ? services.map((s, i) => `- **${s}** - Port ${3001 + i}`).join("\n")
         : `
-No services yet. Add one with:
+No services yet. A service is a whole workspace app, so it is created with
+\`create\` rather than by a schematic:
 
 \`\`\`bash
-npx zudojs generate service <name>
+npx zudojs create <project> --architecture microservice --services <name>
+\`\`\`
+
+To add domain logic to an app that already exists, generate a module into it:
+
+\`\`\`bash
+npx zudojs generate module <name> --service <existing-service>
 \`\`\``}
 
 ## Getting Started

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zudojs-cli",
-  "version": "2.0.0",
+  "version": "2.0.1",
   "description": "Command-line interface for scaffolding, generating, and managing Zudojs framework projects.",
   "license": "MIT",
   "author": {