@devbie/style-guide 1.2.0 → 1.3.0

package/README.md

@@ -5,26 +5,44 @@ Single source of truth for code style across the devbie ecosystem
 
 ## Exports
 
-| Entry                             | Contents                                            |
-| --------------------------------- | --------------------------------------------------- |
-| `@devbie/style-guide/prettier`    | Canonical prettier config (all repos)               |
-| `@devbie/style-guide/eslint/base` | eslint flat standard for Node TypeScript repos      |
-| `@devbie/style-guide/eslint/next` | `base` + canonical Next.js rules (for Next.js apps) |
-
-## Which entry each repo uses
-
-| Repo                                                       | eslint entry |
-| ---------------------------------------------------------- | ------------ |
-| newbie, newbie-starter, nightwatch-backend, newbie-modules | `base`       |
-| fewbie-starter, nightwatch-frontend                        | `next`       |
-
-`base` is the shared default: language-level rules plus prettier, with no
-framework content — it serves Nest services, CLIs, code generators, and
-source registries alike. `next` is `base`'s baseline plus `eslint-config-next`
-(which already bundles the React / react-hooks / jsx-a11y layers), so every
-repo shares the same language-level rules while Next.js applications add only
-the canonical framework layer. `eslint-config-next` requires the `next`
-package at load time, which is why Node repos cannot use `next`.
+| Entry                             | Contents                                        |
+| --------------------------------- | ----------------------------------------------- |
+| `@devbie/style-guide/prettier`    | Canonical prettier config (all repos)           |
+| `@devbie/style-guide/eslint/base` | Baseline eslint flat config for Node TypeScript |
+| `@devbie/style-guide/eslint/nest` | Nest.js layer (Nest-specific rules, type-aware) |
+| `@devbie/style-guide/eslint/next` | Next.js layer (canonical Next.js rules)         |
+
+`nest` and `next` are **layers, not standalone standards**: every consumer
+composes `[...base, ...nest]` or `[...base, ...next]`. The baseline carries
+the shared language-level rules and prettier; a layer adds only its
+framework's rules. `base` alone covers CLIs, code generators, registries, and
+SDKs.
+
+## Coverage: which entry each repo uses
+
+| Repo                                | Composition                               |
+| ----------------------------------- | ----------------------------------------- |
+| newbie-monorepo root                | `base` + `nest` scoped to `packages/core` |
+| newbie-starter, nightwatch-backend  | `base` + `nest`                           |
+| fewbie-starter, nightwatch-frontend | `base` + `next`                           |
+| newbie-modules                      | `base` only                               |
+
+Two structural facts drive this table:
+
+- `newbie-modules` installs no dependencies at all (modules are copied into a
+  consumer, not built in place), so it can only use `base`, which is purely
+  syntactic.
+- The newbie monorepo root lints heterogeneous packages in one config: only
+  `packages/core` is Nest framework code, while the CLIs, the generator and
+  the SDKs are plain Node. ESLint flat config does not read `package.json` and
+  nested `eslint.config.mjs` files are not inherited, so per-package
+  differentiation must be expressed in the root config with `files` scoping —
+  never with per-package config files or `package.json` entry fields.
+
+`next` (and `nest`) must be loaded where the framework's packages are
+installed; `eslint-config-next` requires `next` at load time, and the Nest
+layer requires `class-validator` plus a TypeScript project for its four
+type-aware rules.
 
 ## Usage
 
@@ -48,11 +66,12 @@ not style decisions.
 
 ```js
 import base from "@devbie/style-guide/eslint/base";
-// Next.js apps: import next from "@devbie/style-guide/eslint/next";
+// Nest apps:      import nest from "@devbie/style-guide/eslint/nest";
+// Next.js apps:   import next from "@devbie/style-guide/eslint/next";
 
 export default [
   ...base,
-  // Repo-specific rules and ignores go here.
+  // ...nest or ...next, then repo-specific rules and ignores.
 ];
 ```
 
@@ -68,6 +87,11 @@ default, only as a deliberate milestone.
 
 ## Changelog
 
+- 1.3.0 — new `nest` layer backed by `@darraghor/eslint-plugin-nestjs-typed`
+  (recommended flat config, four type-aware rules), and `next` reshaped into a
+  layer. Consumers now compose `[...base, ...nest]` / `[...base, ...next]`;
+  this also lets the newbie monorepo scope the Nest layer to `packages/core`
+  via `files` instead of giving a Nest framework standard to its CLIs.
 - 1.2.0 — `backend` renamed to `base` and `frontend` removed. After apits and
   fewbie-cli joined the newbie monorepo (ADR-012/ADR-015), `frontend` had no
   consumer left, and `backend` no longer described its consumers (CLIs, code

package/eslint/base.js

@@ -2,12 +2,13 @@ import core from "./core.js";
 import prettierConfig from "eslint-config-prettier";
 
 /**
- * Base standard for the devbie ecosystem.
+ * Baseline standard for the devbie ecosystem.
  *
- * Consumers: newbie (monorepo), newbie-starter, nightwatch-backend,
- * newbie-modules, apits, fewbie-cli (inside newbie). All of them are Node.js
- * TypeScript codebases — no browser DOM framework. The language-level rules
- * live in `core` so base and next standards never drift on the shared part.
+ * Consumers: every repo composes this and optionally adds a framework layer —
+ * `[...base, ...nest]` for Nest applications, `[...base, ...next]` for Next.js
+ * applications. Repos without a framework (newbie-modules, a dependency-free
+ * source registry) use `base` alone: every rule here is syntactic, so it runs
+ * without installing module dependencies.
  *
  * Repo-specific rules and ignores belong in the consumer's own
  * eslint.config.mjs, spread after this entry.

package/eslint/core.js

@@ -8,8 +8,8 @@ import tseslint from "typescript-eslint";
  * eslint-config-prettier last so no plugin can re-enable eslint formatting
  * rules afterwards.
  *
- * Internal entry: consumers import `backend`, `frontend` or `next`, never
- * this file.
+ * Internal entry: consumers import `base` (or compose a layer such as
+ * `nest` / `next` on top of it), never this file.
  */
 export default [
   ...tseslint.configs.recommended,

package/eslint/nest.js

@@ -0,0 +1,29 @@
+import nestjsTyped from "@darraghor/eslint-plugin-nestjs-typed";
+import prettierConfig from "eslint-config-prettier";
+
+/**
+ * Nest.js layer for the devbie ecosystem.
+ *
+ * This is a layer, not a standalone standard: compose it after `base`
+ * (`export default [...base, ...nest]`). Keeping it separable lets a
+ * monorepo scope the Nest rules to the packages that actually contain Nest
+ * code, instead of applying a framework standard to its plain Node packages.
+ *
+ * The rule set is the plugin's recommended flat config. Four of those rules
+ * are type-aware, so every file covered by this layer must belong to a
+ * TypeScript project (projectService resolves the nearest tsconfig.json), and
+ * the plugin's peers (`class-validator`, `@typescript-eslint/parser`) must be
+ * installed by the consumer.
+ *
+ * `prettierConfig` is repeated here so that composing `[...base, ...nest]`
+ * still ends on the formatting-rule shutdown.
+ */
+export default [
+  ...nestjsTyped.configs.flatRecommended,
+  {
+    languageOptions: {
+      parserOptions: { projectService: true },
+    },
+  },
+  prettierConfig,
+];

package/eslint/next.js

@@ -1,26 +1,30 @@
-import { defineConfig, globalIgnores } from "eslint/config";
-import core from "./core.js";
+import { globalIgnores } from "eslint/config";
 import nextVitals from "eslint-config-next/core-web-vitals";
 import nextTs from "eslint-config-next/typescript";
 import prettierConfig from "eslint-config-prettier";
 
 /**
- * Next.js standard for Next.js applications
- * (nightwatch-frontend, fewbie-starter).
+ * Next.js layer for the devbie ecosystem.
+ *
+ * This is a layer, not a standalone standard: compose it after `base`
+ * (`export default [...base, ...next]`), so every repo shares the same
+ * language-level rules while Next.js applications add only the canonical
+ * framework rule set.
  *
- * Extends the shared `core` baseline with the canonical Next rule set.
  * `eslint-config-next` already bundles the React / react-hooks / jsx-a11y
  * layers, so nothing else is layered on top: spreading another React layer
  * would redefine the same plugin and flat config rejects that.
  *
  * This entry can only be loaded where the `next` package is installed; Node
- * repos without a Next runtime use the `base` entry instead.
+ * repos without a Next runtime compose `base` with `nest` or nothing at all.
+ *
+ * `prettierConfig` is repeated here so that composing `[...base, ...next]`
+ * still ends on the formatting-rule shutdown.
  */
-export default defineConfig([
-  ...core,
+export default [
   ...nextVitals,
   ...nextTs,
   prettierConfig,
   // Framework-generated artifacts; consumers append their own ignores.
   globalIgnores([".next/**", "out/**", "build/**", "next-env.d.ts"]),
-]);
+];

package/package.json

@@ -1,13 +1,14 @@
 {
   "name": "@devbie/style-guide",
-  "version": "1.2.0",
-  "description": "Single source of truth for devbie ecosystem code style: shared prettier config and eslint flat standards (base, next)",
+  "version": "1.3.0",
+  "description": "Single source of truth for devbie ecosystem code style: shared prettier config and composable eslint flat layers (base, nest, next)",
   "license": "MIT",
   "author": "worldzhy",
   "type": "module",
   "exports": {
     "./prettier": "./prettier.js",
     "./eslint/base": "./eslint/base.js",
+    "./eslint/nest": "./eslint/nest.js",
     "./eslint/next": "./eslint/next.js",
     "./package.json": "./package.json"
   },
@@ -19,6 +20,7 @@
     "access": "public"
   },
   "dependencies": {
+    "@darraghor/eslint-plugin-nestjs-typed": "^7.5.8",
     "eslint-config-next": "^16.4.2",
     "eslint-config-prettier": "^10.1.8",
     "typescript-eslint": "^8.71.2"