Why
The mobasi-ai/lab repo vendors this project as a submodule at tools/hankweave/src and uses it as a shipped runtime.
We currently get image-level package coverage for Hankweave, but not direct transitive dependency coverage in dependency scanners like Socket, because the repo exposes bun.lock / bun.lockb but not an npm-compatible lockfile such as package-lock.json.
Request
Please add a committed Socket-supported JS lockfile for the shipped package metadata, ideally package-lock.json, alongside the existing Bun workflow.
Acceptance criteria
- root
package.json remains the source of truth for shipped dependencies
- a committed
package-lock.json (or npm-shrinkwrap.json) is present next to the shipped package.json
- the lockfile stays in sync with dependency updates
- existing Bun-based development workflow can remain in place if needed
Context
This would let downstream repos like mobasi-ai/lab expose direct transitive JS dependency coverage for Hankweave in repo-native dependency scanners, instead of relying only on image/SBOM scanning.
Why
The
mobasi-ai/labrepo vendors this project as a submodule attools/hankweave/srcand uses it as a shipped runtime.We currently get image-level package coverage for Hankweave, but not direct transitive dependency coverage in dependency scanners like Socket, because the repo exposes
bun.lock/bun.lockbbut not an npm-compatible lockfile such aspackage-lock.json.Request
Please add a committed Socket-supported JS lockfile for the shipped package metadata, ideally
package-lock.json, alongside the existing Bun workflow.Acceptance criteria
package.jsonremains the source of truth for shipped dependenciespackage-lock.json(ornpm-shrinkwrap.json) is present next to the shippedpackage.jsonContext
This would let downstream repos like
mobasi-ai/labexpose direct transitive JS dependency coverage for Hankweave in repo-native dependency scanners, instead of relying only on image/SBOM scanning.