Repository navigation
Conversation
npm-compatible (package.json) and Deno (deno.json) projects are judged by prettier, biome, deno fmt or dprint; branch coverage from c8, nyc, jest, vitest, deno test or node's test runner; *.test.*, *.spec.* and __tests__/ files run by any common runner; eslint, biome or deno lint as the linter, failing on warnings with --max-warnings 0; npm, pnpm, yarn or bun audits; eslint-plugin-security or semgrep; eslint's max-lines-per-function; tsc (strict in tsconfig.json) or deno check; committed lockfiles; package.json's license; an ignored node_modules/; and the Node.js, Deno and Bun versions CI runs. A package.json alone is the tooling of many projects in other languages, so it makes a JavaScript project only when it names entry points (main, module, exports, bin); JavaScript and TypeScript sources do too. JavaScript tooling mostly runs through package scripts, so the scripts and Deno tasks that CI or a pre-commit hook runs (npm run lint, pnpm lint, deno task fmt, with their pre/post scripts and the scripts they run) count as CI configuration. For that, the Formatter rule gets an optional texts, CI configuration by default, which code-formatting reads; no other check changes. The JSON-with-comments reader moves from data-wellformed to text.py, so profiles can read tsconfig.json and deno.jsonc with evidence.json_value. Closes cpp-best-practices#65 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt
…adle) Maven and Gradle projects are judged by Spotless (or fmt-maven-plugin, google-java-format, ktfmt, ktlint); JaCoCo or Kover branch coverage; @test methods and Kotest specs under src/test run by mvn or gradle; javac's -Xlint:all (Kotlin warns by default); -Werror or Kotlin's allWarningsAsErrors; OWASP dependency-check; Find Security Bugs or PMD's security rules; Checkstyle MethodLength or detekt LongMethod; Error Prone, SpotBugs, PMD, Checkstyle or detekt; Gradle dependency verification, a gradle.lockfile or Maven's --strict-checksums; ignored target/ (Maven) or build/ (Gradle); and the JDK versions CI runs. JVM builds wire their tools in: a Maven plugin binds a goal to a phase, a Gradle plugin adds its task to check. So the build files count as CI configuration when CI runs the build far enough: any compiling phase or task for compiler flags, mvn verify or gradle check/build for the verification plugins. A Maven plugin counts only when an execution binds the goal. Two language-agnostic changes support it: DependencyAudit gets the optional texts that Formatter got (dependency-check bound in pom.xml), and vcs-ignore judges the BuildOutputs of the build system a project uses, as committed-artifacts already did (judge_each_ecosystem). Tests look up checks by name (checks_named) and layouts by name (run_in_layout). Closes cpp-best-practices#66 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #125 +/- ##
==========================================
+ Coverage 98.51% 98.67% +0.15%
==========================================
Files 58 60 +2
Lines 2297 2564 +267
Branches 231 254 +23
==========================================
+ Hits 2263 2530 +267
Misses 28 28
Partials 6 6 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
Author
|
Moved to leftibot#1, stacked on |
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.
Closes #66. Phase 4 of #107. Stacked on #124: the branch lives on a fork, so this PR targets
mainand also contains #124's commit. Review only the last commit (3d67cae). Once #124 merges, this PR shows just that commit.project_validator/ecosystems/jvm.pyjudges Java (.java) and Kotlin (.kt) projects built with Maven (pom.xml) or Gradle (build.gradle(.kts),settings.gradle(.kts))..ktsand.gradlescripts add no language, because they are mostly builds.The build counts as CI configuration. JVM projects wire their tools into the build:
<goal>check</goal>runs inmvn verify).check.So the build files count as evidence when CI runs the build far enough:
mvn test,gradle build).mvn verify/install/deployorgradle check/build.jacoco-maven-pluginwith onlyprepare-agentreports nothing.tests-run@Testmethods (JUnit, TestNG) or Kotest specs undersrc/test/javaorsrc/test/kotlin, run bymvn test/verifyorgradle test/check/buildcoveragereportgoal bound,jacoco:report,jacocoTestReport) or Kover. Both report branches; neither reports path coverage, so there is no bonuscode-formattingspotless:checkbound,spotlessCheck, or thecom.diffplug.spotlessGradle plugin), fmt-maven-plugin,google-java-format --set-exit-if-changed,ktfmt --set-exit-if-changed, or ktlint (not-F, and also as the jlleitschuh Gradle plugin)compiler-warnings-Xlint:all(or-Xlint). A Kotlin-only project passes on Kotlin's default warnings, as #66 says; a mixed project still needs-Xlint:allwarnings-as-errors-Werror(javac or kotlinc) orallWarningsAsErrors = truedependency-auditdependency-check-mavenbound tocheck/aggregate,dependencyCheckAnalyze, the CLI or the action. Applying the Gradle plugin alone does not count, because it adds no task tochecksecurity-scanningcategory/java/security.xmlfunction-limitsMethodLength(it warns when the check is configured but Checkstyle never runs); or detekt runs, since itsLongMethodrule is on unless the config turns it offstatic-analysispmd cpd), Checkstyle or detekt runsdependency-management<dependency>entries inpom.xmlor Gradleimplementation/api/ ... are verified: a committedgradle/verification-metadata.xmlorgradle.lockfile, or Maven with--strict-checksums(in CI or.mvn/maven.config)vcs-ignore/committed-artifactstarget/, Gradle ignoresbuild/.*.classfiles, plustarget/orbuild/and.gradle/, must not be committedplatform-matrixjava-version, oreclipse-temurin:/openjdk:/amazoncorretto:/maven:…-21/gradle:…jdk21images)hardeningandci-build-typesdo not apply, because the JVM builds bytecode, not a native binary.type-checkingdoes not apply either, because both languages are statically typed. Thebuild-tool-versionrow is left for #21.target/beside apom.xmlandbuild/beside a Gradle build are treated as build output, so they are never inspected.Changes outside the profile (please review)
These follow the same idea as
Formatter.textsin #124: work with how the ecosystem is normally set up.DependencyAuditgets the same optionaltextsfield (default: CI configuration). Without it, dependency-check bound inpom.xmland run bymvn verifywould never count.dependency-auditreads it, a one-line change.vcs-ignorenow judges theBuildOutputsrule of the build system a project uses, ascommitted-artifactsalready did. Add a JVM ecosystem profile (Java and Kotlin, with Maven and Gradle) #66 asks for Maventarget/vs Gradlebuild/, and before thisvcs-ignoreread only an ecosystem's own rule. The shared helper isjudge_each_ecosystem, whichpracticenow uses too. Results for every existing ecosystem are unchanged, because none of them has a build-systemBuildOutputsrule.Notes
--strict-checksumsis weaker than Gradle's verification. It only makes Maven fail on a repository checksum mismatch, which is much weaker than Gradle's verification metadata. It is in because Add a JVM ecosystem profile (Java and Kotlin, with Maven and Gradle) #66 lists it.pom.xmlnames licenses in prose (Apache License, Version 2.0), not SPDX, so this profile has noDeclaredLicenserule.tests/support.pygainschecks_named, so tests don't repeat the same import block (jscpd flagged it), andrun_in_layout, which feat: add a JavaScript/TypeScript ecosystem profile #124's tests now use too.Tests
tests/fixtures/well_configured_jvmis a Maven project whose plugins are bound inpom.xmland run bymvn --strict-checksums verify. It passes every check that applies.tests/fixtures/bare_jvmfails or warns on every JVM practice. It commits atarget/directory.tests/test_jvm.pycovers lifecycle gating, the Gradle paths, Kotlin-only warnings, and per-build-system ignores. There are two new layouts: Maven Java and Gradle Kotlin.SKIPmessages change.Local gates all pass:
python -W error -m unittestjvm.py100%)lizard --length 30🤖 Generated with Claude Code
https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt