@oddessentials/repo-standards 1.0.1

package/dist/config/standards.typescript-js.github-actions.json

@@ -0,0 +1,555 @@
+{
+  "checklist": {
+    "core": [
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Maintain proper .gitignore and .dockerignore files to prevent committing secrets, build artifacts, or unnecessary files.",
+        "id": "gitignore-and-dockerignore",
+        "label": "Git and Docker Ignore Files",
+        "stack": {
+          "exampleConfigFiles": [
+            ".gitignore",
+            ".dockerignore"
+          ],
+          "notes": "Use the official github/gitignore Node template as a base and add .env*, node_modules, dist/, coverage/, *.log, npm-debug.log*, etc. .dockerignore must exclude node_modules, .git, and local build output.",
+          "optionalFiles": [
+            ".dockerignore"
+          ],
+          "requiredFiles": [
+            ".gitignore"
+          ],
+          "verification": ".gitignore must exist; .dockerignore is recommended when containerizing or using Docker workflows."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Run static code linting to enforce consistency and catch common issues early.",
+        "id": "linting",
+        "label": "Linting",
+        "stack": {
+          "exampleConfigFiles": [
+            ".eslintrc.*"
+          ],
+          "exampleTools": [
+            "eslint"
+          ],
+          "notes": "Treat new lint errors as CI failures; keep existing issues as warnings until addressed.",
+          "optionalFiles": [
+            ".eslintrc.js",
+            ".eslintrc.cjs",
+            ".eslintrc.json",
+            ".eslintrc.yaml",
+            ".prettierrc",
+            "prettier.config.js",
+            "prettier.config.cjs",
+            "prettier.config.json",
+            "prettier.config.yaml"
+          ],
+          "requiredFiles": [
+            "eslint.config.js"
+          ],
+          "requiredScripts": [
+            "lint"
+          ],
+          "verification": "Presence of eslint.config.js (or any .eslintrc* file) indicates linting is enforced for the repository."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Provide a deterministic unit test framework with a single command to run all tests.",
+        "id": "unit-test-runner",
+        "label": "Unit Test Runner",
+        "stack": {
+          "exampleConfigFiles": [
+            "jest.config.*"
+          ],
+          "exampleTools": [
+            "jest"
+          ],
+          "notes": "Keep unit tests fast and deterministic; move slow or flaky tests into integration or E2E suites.",
+          "optionalFiles": [
+            "jest.config.js",
+            "jest.config.ts",
+            "vitest.config.js",
+            "vitest.config.ts"
+          ],
+          "requiredScripts": [
+            "test"
+          ],
+          "verification": "Test framework configuration is present; test script is defined in package.json."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Provide a Dockerfile and, if applicable, a docker-compose file for local dev and CI parity.",
+        "id": "containerization",
+        "label": "Containerization (Docker / Docker Compose)",
+        "stack": {
+          "exampleConfigFiles": [
+            "Dockerfile",
+            "docker-compose.yml"
+          ],
+          "exampleTools": [],
+          "notes": "Use multi-stage builds and pin Node.js and base image versions in the Dockerfile to match CI (e.g., node:22-alpine).",
+          "optionalFiles": [
+            "docker-compose.yml"
+          ],
+          "requiredFiles": [
+            "Dockerfile"
+          ],
+          "verification": "Dockerfile must be present; docker-compose.yml is optional and indicates orchestration usage."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "release"
+          }
+        },
+        "description": "Use MAJOR.MINOR.PATCH versioning with clear rules and automated changelog generation based on commit history.",
+        "id": "semantic-versioning",
+        "label": "Semantic Versioning",
+        "stack": {
+          "exampleConfigFiles": [
+            ".releaserc",
+            "package.json",
+            "CHANGELOG.md"
+          ],
+          "exampleTools": [
+            "semantic-release",
+            "standard-version"
+          ],
+          "notes": "Automate version bumping and changelog generation from Conventional Commits using semantic-release or standard-version. Configure CI to automatically bump package.json version, generate/update CHANGELOG.md, create git tags, and publish release artifacts. Protect release branches and ensure release tooling only runs there.",
+          "verification": "Check that the version field follows SemVer, and trigger the configured release workflow (for example, a dry run of semantic-release or standard-version) to confirm it automatically generates the expected next version, updates package.json, and creates/updates CHANGELOG.md with commit-based entries."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Enforce structured commit messages such as Conventional Commits.",
+        "id": "commit-linting",
+        "label": "Commit Linting",
+        "stack": {
+          "exampleConfigFiles": [
+            "commitlint.config.*"
+          ],
+          "exampleTools": [
+            "@commitlint/cli",
+            "@commitlint/config-conventional"
+          ],
+          "notes": "Enforce commit message format via commit-msg hooks (e.g., Husky) before CI.",
+          "verification": "Create a test commit using the documented convention and ensure the commit message passes the configured commit linting or wizard (for example, commitlint or commitizen)."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Generate readable unit test and coverage reports and enforce a minimum coverage threshold (around 80%) for new or changed code.",
+        "id": "unit-test-reporter",
+        "label": "Unit Test Reporter / Coverage",
+        "stack": {
+          "exampleConfigFiles": [
+            "jest.config.*"
+          ],
+          "exampleTools": [
+            "jest",
+            "nyc"
+          ],
+          "notes": "Collect coverage in lcov or similar format; use diff coverage so legacy gaps are visible but non-blocking.",
+          "verification": "Run the unit tests with coverage enabled and confirm that a coverage report is produced and that the configured threshold (around 80%) is enforced for new changes."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Single CI pipeline that runs linting, formatting, type checking, tests, coverage, build, and containerization.",
+        "id": "ci-quality-gates",
+        "label": "CI Quality Gates",
+        "stack": {
+          "exampleConfigFiles": [
+            ".github/workflows/*",
+            "azure-pipelines.yml"
+          ],
+          "exampleTools": [],
+          "notes": "Expose a single npm script (e.g., `npm run ci`) that mirrors the CI pipeline so contributors can reproduce failures locally.",
+          "verification": "Open the CI configuration and verify there is a job or stage that runs linting, type checking, tests, build, and any required container checks before merging to main."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Automatic code formatting to maintain a consistent style across all contributors.",
+        "id": "code-formatter",
+        "label": "Code Formatter",
+        "stack": {
+          "exampleConfigFiles": [
+            ".prettierrc.*",
+            ".prettierignore"
+          ],
+          "exampleTools": [
+            "prettier"
+          ],
+          "notes": "Run Prettier in check mode in CI; auto-fix locally via pre-commit hooks or editor integration.",
+          "verification": "Run the formatter in check mode (for example, `npm run format:check`) and confirm it reports clean formatting on committed code and auto-fixes as expected locally."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Use git hooks to run linting, formatting, tests, and commit linting before changes are committed.",
+        "id": "pre-commit-hooks",
+        "label": "Pre-Commit Hooks",
+        "stack": {
+          "exampleConfigFiles": [
+            ".husky/",
+            "package.json"
+          ],
+          "exampleTools": [
+            "husky",
+            "lint-staged"
+          ],
+          "notes": "Run ESLint and Prettier on staged files and enforce commit message format via commit-msg hooks.",
+          "verification": "Inspect the pre-commit and commit-msg hooks (for example, files under .husky or other hook tooling) and confirm they run linting/formatting and commit linting on staged changes."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Use static type checking to catch errors before runtime and enforce strictness on new code.",
+        "id": "type-checking",
+        "label": "Type Checking",
+        "stack": {
+          "exampleConfigFiles": [
+            "tsconfig.json"
+          ],
+          "exampleTools": [
+            "TypeScript compiler (tsc)"
+          ],
+          "notes": "Enable strict mode ('strict': true) and treat type-check failures as CI failures for new code; gradually expand strictness into legacy modules.",
+          "requiredFiles": [
+            "tsconfig.json"
+          ],
+          "requiredScripts": [
+            "typecheck"
+          ],
+          "verification": "Presence of tsconfig.json indicates type-checking is configured for the repository."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Lock dependencies and scan regularly for known vulnerabilities; fail CI on newly introduced high-severity issues.",
+        "id": "dependency-security",
+        "label": "Dependency Management & Vulnerability Scanning",
+        "stack": {
+          "exampleConfigFiles": [
+            "package-lock.json",
+            "pnpm-lock.yaml",
+            "yarn.lock"
+          ],
+          "exampleTools": [
+            "npm audit",
+            "Snyk"
+          ],
+          "notes": "Require a lockfile for reproducible installs and pin Node.js/tooling versions; block merges on new high-severity vulnerabilities.",
+          "optionalFiles": [
+            "package-lock.json",
+            "pnpm-lock.yaml",
+            "yarn.lock"
+          ],
+          "verification": "Dependency lockfile is present; security scanning is configured in CI or project tooling."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Specify required runtime/engine versions in package manifests to ensure environment stability and prevent version-related issues across development teams.",
+        "id": "runtime-version",
+        "label": "Runtime Version Specification",
+        "stack": {
+          "exampleConfigFiles": [
+            "package.json"
+          ],
+          "exampleTools": [],
+          "notes": "Specify the 'engines' field in package.json to define the required Node.js version (e.g., \"engines\": { \"node\": \">=18.0.0\" }). This helps prevent environment-related bugs and ensures all developers use compatible Node.js versions.",
+          "requiredFiles": [
+            "package.json"
+          ],
+          "verification": "package.json must contain an 'engines' field specifying the required Node.js version."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Maintain a comprehensive README and, where applicable, auto-generated API docs to support onboarding and maintainability.",
+        "id": "documentation",
+        "label": "Documentation Standards",
+        "stack": {
+          "exampleConfigFiles": [
+            "README.md",
+            "docs/"
+          ],
+          "exampleTools": [
+            "JSDoc",
+            "TypeDoc"
+          ],
+          "notes": "README should describe setup, scripts, and architecture; generate API docs from TypeScript types and JSDoc where helpful.",
+          "optionalFiles": [
+            "docs/",
+            "typedoc.json"
+          ],
+          "requiredFiles": [
+            "README.md"
+          ],
+          "verification": "README.md is present in the repository root; docs/ directory or documentation tooling configuration exists if applicable."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Include standard governance files (LICENSE, CODE_OF_CONDUCT.md, CONTRIBUTING.md), branch protection rules, and review standards to define legal, ethical, and workflow expectations.",
+        "id": "repository-governance",
+        "label": "Repository Governance",
+        "stack": {
+          "exampleConfigFiles": [
+            "LICENSE",
+            "CODE_OF_CONDUCT.md",
+            "CONTRIBUTING.md"
+          ],
+          "exampleTools": [],
+          "notes": "Use an SPDX license identifier in package.json and describe review expectations, tests, and docs requirements in CONTRIBUTING.md.",
+          "optionalFiles": [
+            "CODE_OF_CONDUCT.md",
+            "CONTRIBUTING.md"
+          ],
+          "requiredFiles": [
+            "LICENSE"
+          ],
+          "verification": "LICENSE file is present in the repository root; CODE_OF_CONDUCT.md and CONTRIBUTING.md are present for contribution guidance."
+        }
+      }
+    ],
+    "optionalEnhancements": [
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Standardize error handling and structured logging to make debugging and production monitoring easier.",
+        "id": "observability",
+        "label": "Observability (Logging & Error Handling)",
+        "stack": {
+          "exampleConfigFiles": [],
+          "exampleTools": [
+            "Winston",
+            "Pino"
+          ],
+          "notes": "Adopt structured JSON logging with correlation IDs and send logs to a centralized sink in production.",
+          "verification": "Confirm that a structured logging library (such as Winston or Pino) is configured to emit JSON or key-value logs and that error handling routes important failures through this logger."
+        }
+      }
+    ],
+    "recommended": [
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Test how components interact with each other and external systems, running after unit tests with more relaxed coverage thresholds.",
+        "id": "integration-testing",
+        "label": "Integration Testing",
+        "stack": {
+          "exampleConfigFiles": [
+            "jest.config.*",
+            "playwright.config.*"
+          ],
+          "exampleTools": [
+            "Jest",
+            "Supertest",
+            "Playwright"
+          ],
+          "notes": "Use Supertest for HTTP APIs and Playwright or similar tools for end-to-end flows; keep integration suites slower but reliable.",
+          "verification": "Confirm there is a separate integration or end-to-end test command or configuration and run it to verify that cross-component flows behave as expected."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "performance"
+          }
+        },
+        "description": "Establish performance baselines and monitor for regressions using lightweight benchmarks or audits in CI.",
+        "id": "performance-baselining",
+        "label": "Performance Baselines",
+        "stack": {
+          "exampleConfigFiles": [
+            "lighthouserc.json"
+          ],
+          "exampleTools": [
+            "Lighthouse CI",
+            "custom Node.js benchmarks"
+          ],
+          "notes": "Run Lighthouse CI for web apps and basic Node benchmarks on critical endpoints; schedule runs or limit to key branches to keep CI fast.",
+          "verification": "Identify and run the configured performance or Lighthouse-style checks and verify that key metrics are captured and compared to documented baselines."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Measure cyclomatic complexity or similar metrics to keep code maintainable, starting as a warning-only check.",
+        "id": "complexity-analysis",
+        "label": "Complexity Analysis",
+        "stack": {
+          "exampleConfigFiles": [
+            ".eslintrc.*",
+            "sonar-project.properties"
+          ],
+          "exampleTools": [
+            "ESLint complexity rules",
+            "SonarQube"
+          ],
+          "notes": "Warn on overly complex functions and methods; fail CI only when new or modified code exceeds thresholds.",
+          "verification": "Run the configured complexity tooling or rules (for example, ESLint complexity rules or Sonar analysis) and review any hot spots, ensuring new code does not exceed agreed thresholds."
+        }
+      },
+      {
+        "ciHints": {
+          "github-actions": {
+            "job": "ci"
+          }
+        },
+        "description": "Run accessibility checks on web-facing components to detect critical issues and improve inclusive UX.",
+        "id": "accessibility-auditing",
+        "label": "Accessibility Auditing",
+        "stack": {
+          "exampleConfigFiles": [],
+          "exampleTools": [
+            "axe-core",
+            "Lighthouse accessibility audits"
+          ],
+          "notes": "Run accessibility checks against key pages or components in CI; fail on critical violations while treating minor issues as warnings initially.",
+          "verification": "For web-facing apps, run the configured accessibility tooling (for example, axe, pa11y, or Lighthouse accessibility audits) against key pages and confirm that critical issues are resolved."
+        }
+      }
+    ]
+  },
+  "ciSystems": [
+    "github-actions"
+  ],
+  "meta": {
+    "complexityChecks": {
+      "description": "When supported by the stack, run cyclomatic complexity or similar metrics in CI as a warning-only check initially.",
+      "enabledByDefault": true
+    },
+    "defaultCoverageThreshold": 0.8,
+    "migrationGuide": [
+      {
+        "description": "Start by adding pre-commit hooks and core formatting/linting so developers get fast feedback without touching CI.",
+        "focusIds": [
+          "pre-commit-hooks",
+          "linting",
+          "code-formatter"
+        ],
+        "notes": "Keep hooks fast and focused on changed files to avoid slowing down day-to-day work.",
+        "step": 1,
+        "title": "Establish Local Safety Nets First"
+      },
+      {
+        "description": "Introduce CI quality gates that mirror local checks, but treat existing violations as warnings wherever possible.",
+        "focusIds": [
+          "ci-quality-gates",
+          "linting",
+          "code-formatter",
+          "commit-linting"
+        ],
+        "notes": "Use diff-based tools or baselines so only new violations break builds; legacy issues remain visible but non-blocking.",
+        "step": 2,
+        "title": "Mirror Local Checks in CI (Soft-Fail on Legacy)"
+      },
+      {
+        "description": "Enable type-checking, coverage thresholds, and dependency/vulnerability scanning with gradual enforcement.",
+        "focusIds": [
+          "type-checking",
+          "unit-test-runner",
+          "unit-test-reporter",
+          "dependency-security"
+        ],
+        "notes": "Pin tool and runtime versions in CI and containers to avoid flaky differences across environments.",
+        "step": 3,
+        "title": "Add Type Safety, Coverage, and Dependency Security"
+      },
+      {
+        "description": "Add documentation standards, governance files, integration testing, performance baselines, complexity analysis, accessibility auditing, and (optionally) ML-specific practices for data-heavy Python repos.",
+        "focusIds": [
+          "documentation",
+          "repository-governance",
+          "integration-testing",
+          "performance-baselining",
+          "complexity-analysis",
+          "accessibility-auditing"
+        ],
+        "notes": "Tackle recommended items in order of business value; backend-only repos can skip web-focused checks like accessibility. For AI/ML-heavy Python teams, consider extending containerization with data versioning (DVC) and unit tests with data quality checks (e.g., Great Expectations) as part of this step.",
+        "step": 4,
+        "title": "Layer in Docs, Governance, and Recommended Checks"
+      }
+    ],
+    "qualityGatePolicy": {
+      "description": "New quality checks should warn on existing code and fail CI only for violations introduced in new or changed code, to reduce friction on legacy codebases.",
+      "preferSoftFailOnLegacy": true
+    }
+  },
+  "stack": "typescript-js",
+  "stackLabel": "TypeScript / JavaScript",
+  "version": 1
+}