Monorepo Publishing Woes: OIDC Trusted Publishing Fails for Nested Packages, Impacting Engineering Productivity
Modern software development often leverages monorepos for streamlined code management and OpenID Connect (OIDC) for secure, token-based authentication in CI/CD pipelines. While these technologies significantly enhance engineering productivity metrics, a recent GitHub Community discussion highlights a critical bug that can disrupt this efficiency: OIDC Trusted Publishing failing for packages located in monorepo subdirectories.
The Monorepo Publishing Blocker: "Package Not Found"
User CarlosEduJs reported a persistent issue where `npm publish` with OIDC Trusted Publishing consistently fails for packages nested within a monorepo structure. Despite correct OIDC configuration and successful initial validation, the process halts with an `ENEEDAUTH` / E404 error, specifically "package not found."
The core of the problem appears when a package's `package.json` uses the `repository.directory` field to specify its location within the monorepo, like so:
"repository": {
"type": "git",
"url": "git+https://github.com/carlosedujs/ikihs.git",
"directory": "packages/ikihsjs"
}
This setup, common in monorepos, seems to confuse npm's OIDC token exchange mechanism, particularly at the `/-/npm/v1/oidc/token/exchange/package/{name}` endpoint.
Deep Dive into the Technical Details
CarlosEduJs meticulously verified the setup, ruling out common misconfigurations:
- Trusted Publisher Configuration: Deliberate typos were introduced and corrected, confirming that the OIDC validation itself passed. The issue occurs after OIDC successfully verifies the identity.
- npm Version: Updated to the latest `npm@latest` without resolving the problem.
- Authentication: `NODE_AUTH_TOKEN` was intentionally unset, relying solely on OIDC.
- Workspace Command: Even attempting `npm publish --workspace packages/ikihsjs` from the repository root yielded the same error.
- Workflow Permissions: The necessary `id-token: write` and `contents: write` permissions were correctly configured in the GitHub Actions workflow:
permissions: contents: write id-token: write
The verbose log clearly shows the GitHub Actions ID Token request succeeding (status 200) and the Provenance Statement being signed. The failure point is specifically the npm token exchange endpoint returning a 404:
npm http fetch POST 404 https://registry.npmjs.org/-/npm/v1/oidc/token/exchange/package/ikihsjs
npm verbose oidc Failed token exchange request with body message: OIDC token exchange error - package not found
npm error code ENEEDAUTH
npm error need auth This command requires you to be logged in to https://registry.npmjs.org/
This indicates that npm is unable to correctly resolve the package name (`ikihsjs`) in the context of the OIDC token exchange, likely due to its nested location within the monorepo's `repository.directory` configuration.
Impact on Development Workflow and Engineering Productivity
This bug directly impacts automated publishing workflows, a cornerstone of efficient software project goals and robust engineering productivity metrics. When secure, token-based publishing fails, developers are forced to resort to less secure or more manual methods, introducing friction, increasing the risk of human error, and slowing down release cycles. For teams relying on monorepos and OIDC for their supply chain security, this issue creates a significant roadblock, hindering continuous delivery and potentially delaying critical updates.
What's Next?
The discussion points to existing, related issues in the npm CLI repository (e.g., npm/cli#8730, npm/cli#8678, npm/cli#8976), suggesting a known pattern of difficulty with monorepo package resolution during OIDC token exchange. As of now, no immediate workaround or solution has been provided. Teams encountering this issue are encouraged to monitor these linked GitHub issues for updates and potential fixes from the npm team.
