Context: REES (review-enrichment service, `review-enrichment/`, now named `@loopover/rees` in package.json but kept `private: true`) has ~60 real, reusable analyzers — secret detection, license/EOL checks, dependency CVE scanning, supply-chain checks, and more (see `REES_ANALYZERS` in `.env.example`). Today the ONLY way to use any of it is to run the whole thing as a standalone Hono HTTP server (`node dist/server.js`, self-hosted via `docker compose --profile rees up -d`). There is no importable API surface — no `exports` map, no `bin`, nothing a consumer could `import` or `npx`.
The idea (deliberately not fully scoped yet): there's real, currently-untapped value in the analyzer logic itself, separate from the HTTP-service wrapper around it. Publishing the service as-is to npm would produce a non-functional package (source tree, nothing to import). The interesting version of this is restructuring so the analyzers are usable as a genuine building block — e.g. `import { scanForSecrets, checkLicenses } from '@loopover/rees'` directly, without standing up a separate service.
Open questions to figure out, not answer here:
- Library-first (importable analyzer functions, HTTP server becomes a thin wrapper around the same exports) vs. keep the HTTP service as the primary interface and add a separate thin client/SDK package on top?
- Would this become a portable CLI tool too (`npx @loopover/rees scan .`) for one-off local runs outside the full review pipeline?
- Versioning: analyzer behavior changes are currently free to make since nothing external depends on them: an importable library means real semver discipline going forward.
- Any self-host-only config/secrets currently reachable from analyzer code paths that must never leak into a public import surface.
- Whether this is purely a give-away-the-building-blocks / brand-visibility play, or could support a hosted-REES-API product line later.
Deliberately out of scope right now: actually building any of this. Sidelined per explicit product decision — capturing the idea so it isn't lost, not committing to a design or timeline.
Related to the LoopOver npm-org rename (#4769, #5601) — surfaced while deciding review-enrichment's publish visibility.
Context: REES (review-enrichment service, `review-enrichment/`, now named `@loopover/rees` in package.json but kept `private: true`) has ~60 real, reusable analyzers — secret detection, license/EOL checks, dependency CVE scanning, supply-chain checks, and more (see `REES_ANALYZERS` in `.env.example`). Today the ONLY way to use any of it is to run the whole thing as a standalone Hono HTTP server (`node dist/server.js`, self-hosted via `docker compose --profile rees up -d`). There is no importable API surface — no `exports` map, no `bin`, nothing a consumer could `import` or `npx`.
The idea (deliberately not fully scoped yet): there's real, currently-untapped value in the analyzer logic itself, separate from the HTTP-service wrapper around it. Publishing the service as-is to npm would produce a non-functional package (source tree, nothing to import). The interesting version of this is restructuring so the analyzers are usable as a genuine building block — e.g. `import { scanForSecrets, checkLicenses } from '@loopover/rees'` directly, without standing up a separate service.
Open questions to figure out, not answer here:
Deliberately out of scope right now: actually building any of this. Sidelined per explicit product decision — capturing the idea so it isn't lost, not committing to a design or timeline.
Related to the LoopOver npm-org rename (#4769, #5601) — surfaced while deciding review-enrichment's publish visibility.