Repository navigation
feat: validate the root package.json against the repository's kind - #49
Merged
Merged
Conversation
Add ValidatePackageJsonModule, an opt-in pipeline step, and a standalone `purview-build package-validate` command that checks the root package.json against the content a best-in-class package of the repository's kind should declare: a .NET repository that packs NuGet packages, one that packs nothing, a published npm package, or a web application. Fourteen permanent PKG0nn rules cover the name, version, description, licence, repository, author, homepage/bugs, keywords, the `private` flag, engines, entry points, the scripts the run drives, the publish allow-list, and repository-configured additional fields. Severity is profile-dependent: a four-part version is fatal for a published npm package, because npm requires SemVer 2.0, and merely advisory for a .NET repository, while the npm-only rules are skipped outright for .NET. The module is category Build and depends only on VersionModule, so enabling it can never reorder pack or publish. A file that cannot be read or parsed is reported as PKG000 in the same shape as any other finding, never thrown. The declarative fixture src/tests/fixtures/package-json-scenarios.json holds 32 cases and drives both the TUnit suite and `just package-matrix`, which runs each case through the real CLI, so the shipped binary and the in-process runner are held to one specification. Documented in docs/wiki/Package-Json-Validation.md, the Configuration Reference, the Pipeline Modules page and a new skills/purview-build-package-json skill; the configuration schema is regenerated and the check is enabled for this repository.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds an opt-in
package.jsonvalidation step, plus a command that runs it in its own right.purview-build package-validate [--format=json]— builds no pipeline, exits0when the file passes and1when it does not. Needs no configuration.PackageJson:Enabled=true— addsValidatePackageJsonModule(categoryBuild, depends only onVersionModule) to the pipeline. Enabled for this repository.Why
Every consuming repository has a root
package.json, even a .NET one — it is where the release version lives — but nothing checks what else it declares. This holds it to the content a best-in-class package of the repository's kind should have: a name, a version, a description, a licence, and the details a consumer, a registry and a maintainer need.How the project type changes the rules
Rules are not one list. The profile decides which apply and how severe a miss is:
Auto)DotNetNuGetProjectType=DotNet,RunPack=trueDotNetSolutionProjectType=DotNet,RunPack=falseWebPackageProjectType=Web, notprivateWebAppProjectType=Web,private: trueSo a four-part version is fatal for a published npm package (npm only accepts SemVer 2.0) and merely advisory for a
.NETrepository, whereVersion:Strictness=NuGetdeliberately allows it. The npm-only rules —engines, entry points,files, keywords — are skipped outright for.NET, and every skipping is reported rather than hidden.Fourteen permanent
PKG0nnrules: name, version, description, licence, repository, author, homepage/bugs, keywords,privateintent, engines, entry points, the scripts the run drives, the publish allow-list, plusPackageJson:AdditionalRequiredFieldsas the per-organisation escape hatch. A file that cannot be read or parsed is reported asPKG000in the same shape as any other finding, never thrown.Verification
--warnaserror: 0 warnings, 0 errors;just lint-checkpasses.Build.UnitTests1122 passed,Build.IntegrationTests184 passed,Repository.UnitTests18 passed (including the skill conformance suite for the new skill).just package-matrix: 32 scenarios, 0 failed through the real CLI.src/tests/fixtures/package-json-scenarios.jsonis the single specification: the TUnit suite and the CLI matrix read the same file, so the shipped binary and the in-process runner cannot drift apart.AllScenarios_ExerciseEveryRulefails if a rule has no case.Docs
docs/wiki/Package-Json-Validation.md(new), the Configuration Reference, Pipeline Modules, Architecture, Local Development, Home/Sidebar, README,AGENTS.md(extending the permanent-rule-ID invariant toPKG0nn), the regenerated configuration schema, and a newskills/purview-build-package-jsonskill.No version bump, so merging this does not release.