Skip to content

Pin mutable direct dependencies and correct build-time placement #12

Description

@seonghobae

Problem

At PolicyWeave PR #11 exact head b8171c9019dfbbd92c5d6ad71a0160bd8bfb11ee, both package.json and the root package entry in package-lock.json declare 15 direct dependencies as latest. The current lock makes npm ci reproducible for this one tree, but the manifest leaves future lock regeneration open to unreviewed major-version and license/provenance changes.

The manifest also places @vitejs/plugin-react, typescript, and vite in runtime dependencies, even though they are build/toolchain responsibilities for this static browser product.

Current locked resolutions for the mutable declarations are:

  • runtime: @vitejs/plugin-react@6.1.1, lucide-react@1.38.0, react@19.2.8, react-dom@19.2.8, vite@8.2.2
  • development: @eslint/js@10.0.1, @testing-library/jest-dom@7.0.1, @testing-library/react@16.3.3, @types/react@19.2.18, @types/react-dom@19.2.5, eslint@10.9.1, eslint-plugin-react-hooks@7.1.1, eslint-plugin-react-refresh@0.5.5, globals@17.11.0, jsdom@30.0.1, vitest@4.1.11

The repository-level MIT grant does not relicense npm dependencies. The lock already contains other license families such as BlueOak-1.0.0, so the release provenance/attribution inventory must stay dependency-specific.

Canonical repair contract

Repair this on the existing PR #1#10 product writer stack; do not create a competing main-based product tree or retire #11.

  1. Add a RED manifest contract that rejects latest and rejects build-only packages in runtime dependencies.
  2. Replace each mutable declaration with an explicit reviewed version/range, using the current locked versions as the starting evidence rather than silently upgrading.
  3. Move @vitejs/plugin-react, typescript, and vite to devDependencies; verify whether any other direct package is build-only before changing it.
  4. Regenerate package-lock.json from the corrected manifest and prove npm ci, lint, unit tests, PostgreSQL contracts, production build, and browser E2E at the same exact head.
  5. Produce/reconcile exact-head SBOM and license/provenance evidence. Fail closed on GPL/LGPL/AGPL, noncommercial, research-only, unknown, or incompatible inbound components; do not replace license review with a root MIT label.
  6. Update README, CHANGELOG, architecture/TRD, and docs/product-technical-gap-baseline.md only where the verified package and release boundary changes.

Exit evidence

The issue is complete only after the owner-side repair is integrated through ordinary protection with exact-head checks, independent review, zero unresolved threads, immutable dependency/provenance evidence, and a consumer/release statement that distinguishes application code from third-party obligations.

Current exact-head evidence

PR #13 exact head eff7ec19f511cc5850f4fd1254f0a20d9c47fc9e pins and classifies the direct declarations, and CI 34251045288 is terminal GREEN with separate browser and CycloneDX artifacts.

The exact package-lock.json contains 267 installed package entries. Its declared-license inventory is MIT 200, Apache-2.0 21, MPL-2.0 14, ISC 13, BSD-2-Clause 8, BlueOak-1.0.0 4, BSD-3-Clause 3, MIT-0 2, CC-BY-4.0 1, and CC0-1.0 1. String-level screening found no GPL, LGPL, AGPL, SSPL, BUSL, Commons Clause, noncommercial, or CC-BY-NC declaration.

This is inventory evidence, not a compatibility approval. All MPL-2.0 entries and the CC-BY-4.0 caniuse-lite@1.0.30001810 entry are development-toolchain transitive packages in this lock; distribution/NOTICE/attribution obligations and the contents of shipped artifacts still require review before this issue can be completed. PR #13 remains Draft and stacked on #11; protected integration, independent review, and organization checks are outstanding.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions