exadev-eslint-config 2.31.0 → 2.31.2

package/README.md

@@ -1215,6 +1215,35 @@ export default exadevConfig({
 });
 ```
 
+### Reading the shared layout from @exadev/config
+
+A repository that describes its workspace once in [`@exadev/config`](https://github.com/ExaDev/config)'s `layout` section can feed the same description to these rules. The `layout` section's type is checked equal to `WorkspaceArchitectureOptions`, so the value `loadSection(layoutSection)` returns is passed to `workspaceArchitecture` as it is. In an ESM `eslint.config.ts`, read it with top-level `await`:
+
+```ts
+// eslint.config.ts
+import { layoutSection, loadSection } from '@exadev/config';
+import { exadevConfig } from '@exadev/eslint-config';
+import { defineConfig } from 'eslint/config';
+
+const layout = await loadSection(layoutSection, { cwd: import.meta.dirname });
+if (layout === undefined) throw new Error('exadev.config.ts defines no layout section');
+
+export default defineConfig(
+  {
+    languageOptions: {
+      parserOptions: { project: './tsconfig.json', tsconfigRootDir: import.meta.dirname },
+    },
+  },
+  ...exadevConfig({ workspaceArchitecture: layout }),
+);
+```
+
+`loadSection` resolves to `undefined` when no `layout` section is defined, hence the check. `cwd` is the directory holding `exadev.config.ts` (or `exadev.layout.config.ts`). A layout that fails the section's schema throws when the config loads, with the path and the rule that failed.
+
+The layout carries structure only: groups, ranks, slices, naming and isolated pairs. Policy stays here, so `allow`, `exemptTargetGroups`, `requiredFiles`, `devOnly` and `requiredScripts` are not part of it; add them with a spread (`workspaceArchitecture: { ...layout, allow: [...] }`).
+
+The ESLint config itself stays in `eslint.config.*`. Only the layout moves into `exadev.config.ts`: ESLint loads its own config file, and the unified file has no section for rules or plugins. Neither package depends on the other: install `@exadev/config` (and its `cosmiconfig` peer) in the repository, and `@exadev/eslint-config` takes the value structurally. This repository keeps `@exadev/config` as a dev dependency only, for the test that fails when either side's types drift apart.
+
 ## Turbo
 
 These rules keep a repository that uses [turbo](https://turborepo.dev) honest about what turbo actually runs. Turbo skips a task silently when no package has a script of that name, restores only a task's log when `outputs` is missing, and caches a task under a hash taken before the task runs; none of that shows up as an error. They share one options object, `TurboOptions`, and all are off unless the `turbo` option is given, since only a repository can say it uses turbo. Enable them through `exadevConfig({ turbo })` or the standalone `turboConfig(options)`, which returns the blocks to spread into `defineConfig(...)`:
@@ -1490,7 +1519,7 @@ Conventional commits are enforced by a husky `commit-msg` hook and re-checked in
 
 ### Release
 
-Conventional commits drive [semantic-release](https://semantic-release.gitbook.io/semantic-release) on every push to `main`: version bump, `CHANGELOG.md`, GitHub Release, and npm publish via [OIDC trusted publishing](https://docs.npmjs.com/trusted-publishers) (no stored token). A second CI job republishes the identical build under the unscoped alias `exadev-eslint-config`.
+Conventional commits drive [semantic-release](https://semantic-release.gitbook.io/semantic-release) on every push to `main`: version bump, `CHANGELOG.md`, GitHub Release, and npm publish via [OIDC trusted publishing](https://docs.npmjs.com/trusted-publishers) (no stored token). The release commit and tag are pushed over SSH with a repository deploy key that bypasses the `main` ruleset; the key is written to the runner's temporary directory only by the step directly before semantic-release (checkout does not receive it and persists no credentials) and removed afterwards, and the job's actions are pinned to commit SHAs. This narrows the key's exposure without isolating it: code run by an earlier step, or by semantic-release and its plugins from `node_modules`, can still reach it, so a credential that does not outlive the job (a short-lived GitHub App installation token) remains the complete fix. A second CI job republishes the identical build under the unscoped alias `exadev-eslint-config`.
 
 ## License
 

package/dist/index.cjs

@@ -185,7 +185,7 @@ function buildGitignoreConfig(options = {}) {
 }
 //#endregion
 //#region package.json
-var version = "2.31.0";
+var version = "2.31.2";
 //#endregion
 //#region src/is-record.ts
 /**

package/dist/index.js

@@ -150,7 +150,7 @@ function buildGitignoreConfig(options = {}) {
 }
 //#endregion
 //#region package.json
-var version = "2.31.0";
+var version = "2.31.2";
 //#endregion
 //#region src/is-record.ts
 /**

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "exadev-eslint-config",
   "description": "Shared custom ESLint rules and plugin for ExaDev projects",
-  "version": "2.31.0",
+  "version": "2.31.2",
   "dependencies": {
     "@eslint/js": "^10.0.1",
     "@microsoft/tsdoc": "0.17.0",
@@ -20,6 +20,7 @@
     "@eslint/config-helpers": "0.7.0",
     "@eslint/json": "2.1.0",
     "@eslint/markdown": "8.0.3",
+    "@exadev/config": "1.1.3",
     "@humanwhocodes/momoa": "^3.3.13",
     "@next/eslint-plugin-next": "^16.3.2",
     "@semantic-release/changelog": "^7.0.0",
@@ -32,6 +33,7 @@
     "@typescript-eslint/rule-tester": "^8.67.0",
     "@vitest/coverage-v8": "^4.1.10",
     "@vitest/eslint-plugin": "^1.6.27",
+    "cosmiconfig": "10.0.1",
     "eslint": "^10.8.0",
     "eslint-plugin-jsx-a11y": "^6.10.2",
     "eslint-plugin-react": "^7.37.5",