agentleFS
actionsactions/dependency-review-action/.github/copilot-instructions.md

dependency-review-action

Copilot instructions911 starsChanged 2 years agoMITView on GitHub

Trust these instructions. Only search the codebase if information here is incomplete or found to be in error. dependency-review-action is a GitHub Action (TypeScript/Node.js 24) that scans pull requests for dependency changes, raising errors for vulnerabilities or invalid licenses. It queries the GitHub Dependency Review API, evaluates changes against configured rules, and produces job summaries and PR comments. The action entry point is dist/index.js (bundled via ncc). The repo is small (~15 source files, ~15 test files). For CI-parity installs…

We split this copilot-instructions.md into the rules it gives an agent

7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always run these commands in this order to validate changes:

    line 26
  2. Very specific:

    If format-check fails, run npm run format to auto-fix, then re-check.

    line 35
  3. Distinctive:

    No semicolons (enforced by ESLint and Prettier)

    line 88
  4. Very specific:

    Use Zod schemas (in src/schemas.ts) for all data validation and type definitions

    line 93
  5. Very specific:

    Use __tests__/test-helpers.ts setInput(name, value) to mock action inputs (sets INPUT_* env vars)

    line 99
  6. Very specific:

    Use __tests__/fixtures/create-test-change.ts and create-test-vulnerability.ts for test data factories

    line 100
  7. Very specific:

    Test files follow __tests__/<module>.test.ts naming convention

    line 101

≈ “Common” is an estimate: at least 1 in 5 of the 3,669 Copilot instructions files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
copilot-instructions.md

Copilot Coding Agent Instructions

Trust these instructions. Only search the codebase if information here is incomplete or found to be in error.

Repository Overview

dependency-review-action is a GitHub Action (TypeScript/Node.js 24) that scans pull requests for dependency changes, raising errors for vulnerabilities or invalid licenses. It queries the GitHub Dependency Review API, evaluates changes against configured rules, and produces job summaries and PR comments. The action entry point is dist/index.js (bundled via ncc). The repo is small (~15 source files, ~15 test files).

Build & Validation Commands

For CI-parity installs and local validation, run npm ci --ignore-scripts before other commands. This is the install step used in CI; release workflows may follow different install instructions (see CONTRIBUTING).

TaskCommandNotes
Installnpm ci --ignore-scripts~45s. Use --ignore-scripts for CI-parity installs; release workflows may use npm i per CONTRIBUTING.
Buildnpm run buildCompiles src/*.ts → lib/*.js via tsc -p tsconfig.build.json. ~5s.
Testnpm testRuns Jest. ~8s. All tests should pass.
Lintnpm run lintESLint on src/**/*.ts. Ignore the TS version warning—it still passes.
Format checknpm run format-checkPrettier check on **/*.ts.
Format fixnpm run formatAuto-fix formatting with Prettier.
Packagenpm run packageBundles the action entrypoint (package.json#main) → dist/index.js via ncc. ~7s. Do NOT include dist/ changes in non-release PRs.
Allnpm run allRuns: build → format → lint → package → test (in that order).

Validation Sequence After Making Changes

Always run these commands in this order to validate changes:

npm run build
npm run format-check
npm run lint
npm test

If format-check fails, run npm run format to auto-fix, then re-check.

CI Checks (.github/workflows/ci.yml)

CI runs on PRs (excluding **.md changes) with Node 24:

  1. test job: npm ci --ignore-scripts → npm test
  2. lint job: npm ci --ignore-scripts → npm run format-check → npm run lint

Additional workflows: dependency-review.yml (self-test), codeql.yml (CodeQL analysis), stale.yaml (stale issues).

Project Layout

src/                  # TypeScript source (edit these files)
  main.ts             # Entry point — orchestrates the action (532 lines)
  schemas.ts          # Zod schemas & TypeScript types for all data structures
  config.ts           # Reads action inputs + external YAML config
  dependency-graph.ts # GitHub API client for dependency diff
  filter.ts           # Filters changes by severity, scope, allowed advisories
  licenses.ts         # License validation against allow/deny lists
  deny.ts             # Package/group deny-listing logic
  purl.ts             # Package URL (PURL) parser
  spdx.ts             # SPDX license expression handling
  scorecard.ts        # OpenSSF Scorecard integration
  summary.ts          # Summary/report generation (736 lines, largest module)
  comment-pr.ts       # Posts/updates PR comments with results
  git-refs.ts         # Resolves base/head git refs from event payload
  utils.ts            # Shared utilities (Octokit client, grouping helpers)
lib/                  # Compiled JS output (from `npm run build`). Gitignored.
dist/                 # Bundled action (from `npm run package`). Committed but do NOT include changes in normal PRs - only pull requests which are creating new releases should have these files changed.
__tests__/            # Jest test files (*.test.ts)
  test-helpers.ts     # setInput()/clearInputs() helpers for test env vars
  fixtures/           # YAML config samples and factory helpers
    create-test-change.ts       # Factory for mock Change objects
    create-test-vulnerability.ts # Factory for mock vulnerability objects
scripts/              # Dev/debug utilities (scan_pr for manual testing, create_summary.ts for preview)
action.yml            # Action metadata — inputs, outputs, and `runs.main: dist/index.js`

Configuration Files

FilePurpose
tsconfig.jsonBase TypeScript config (ES6 target, CommonJS, strict mode)
tsconfig.build.jsonBuild config — extends base, includes only src/, outputs to lib/
jest.config.jsJest config — uses ts-jest, matches **/*.test.ts
.eslintrc.jsonESLint — plugin:github/recommended, strict TS rules, no semicolons
.prettierrc.jsonPrettier — no semis, single quotes, no bracket spacing, trailing comma: none
.prettierignoreIgnores dist/, lib/, node_modules/

Key TypeScript/Style Rules

  • No semicolons (enforced by ESLint and Prettier)
  • Single quotes, no trailing commas
  • @typescript-eslint/no-explicit-any: error — never use any
  • @typescript-eslint/explicit-function-return-type: error — all functions need return types (expressions exempt)
  • Unused function parameters/args must be prefixed with _ (e.g. _unused); unused variables should be removed
  • Use Zod schemas (in src/schemas.ts) for all data validation and type definitions
  • Config option defaults belong in Zod schemas, NOT in action.yml

Testing Patterns

  • Tests use Jest with ts-jest transform — no build step needed before running tests
  • Use __tests__/test-helpers.ts setInput(name, value) to mock action inputs (sets INPUT_* env vars)
  • Use __tests__/fixtures/create-test-change.ts and create-test-vulnerability.ts for test data factories
  • Test files follow __tests__/<module>.test.ts naming convention
  • Tests run directly against TypeScript source (not compiled JS)

Important Notes

  • The action runs on node24 (declared in action.yml)
  • Source imports often use relative ../src/ paths (e.g. import {readConfig} from '../src/config')
  • Adding a new action input requires changes in: action.yml (input definition), src/schemas.ts (Zod schema with default), src/config.ts (reading the input), and relevant source/test files
  • dist/index.js is committed for GitHub Actions but PR contributors should NOT include dist/ changes — maintainers handle rebuilding
  • The lib/ directory is gitignored
  • Scorecard tests make real HTTP calls to api.securityscorecards.dev and deps.dev

Download now (ZIP)

  • Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.

    Of the Copilot instructions files we read, the 2,297 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.