Sebastian Poxhofer
4220c0fe36
* refactor(manager): share the .npmrc host-rule wrapper between bun, deno and npm Adds `withNpmrcHostRules()` to the npm manager utils: it injects the host-rule lines into a directory's `.npmrc`, runs the callback, and restores the original `.npmrc` from a `finally` block. bun, deno, the corepack `updateArtifacts()` and the three lock file loops in `post-update/index.ts` now share it instead of repeating getNpmrcContent / updateNpmrcContent / resetNpmrcContent. Adds `readUpdatedBinaryLockFile()` to the shared manager utils for the `Buffer.compare` plus file-addition block that bun and deno both carried. Behaviour changes: - bun and deno now restore `.npmrc` when `exec()` throws. The reset previously ran only after a successful install, so a failed lock file update left the injected registry credentials in the working tree. Covered by "restores .npmrc when the install fails" in `bun/artifacts.spec.ts` and `deno/artifacts.spec.ts`. - The npm, yarn and pnpm loops in `post-update/index.ts` now restore `.npmrc` when the loop body throws an `ExternalHostError`, for the same reason. - deno reads `config.isLockFileMaintenance` instead of deriving the flag from `config.updateType === 'lockFileMaintenance'`. Grouped branches overwrite `updateType` while `isLockFileMaintenance` is set explicitly, so the flag is the reliable source. The deno specs were updated to set it. * refactor(manager): let updateLockFile() compare binary lock files A Buffer as the existing content makes the skeleton read, compare and return the new lock file as bytes, so bun and deno use it instead of a separate readUpdatedBinaryLockFile() helper. * refactor(manager/devbox): update the lock file through updateLockFile() devbox kept the same Buffer compare as bun and deno; the trace log before returning the lock file goes away with it. * fix(manager/devbox): type the command list explicitly The list is now only read inside the run() closure, where TypeScript cannot resolve an evolving array type, so tsc reported an implicit any.
npm problems and workarounds
Invalid lock file (npm ci fails)
Unfortunately, npm itself sometimes generates invalid lock files which fail npm ci.
Try adding "postUpdateOptions": ["npmInstallTwice"] to tell Renovate run any npm install command (which is used to update lock files) twice.
This is less efficient than running npm once, but has been known to fix most problems of this type.
Renovate already runs npm install twice during lock file maintenance, because regenerating a lock file from scratch is known to need a second pass.
If this npm bug remains unfixed, and it becomes too frequent for Renovate users, then we may need to modify Renovate to do this by default. Please post feedback to the Renovate repository "Discussions" if you're needing to use this feature frequently or widely.
Yarn
Version Selection / Installation
If Renovate detects a packageManager setting for Yarn in package.json then it will use Corepack to install Yarn.
HTTP Proxy Support
Yarn itself does not natively recognize/support the HTTP_PROXY and HTTPS_PROXY environment variables.
You can configure RENOVATE_X_YARN_PROXY=true as an environment variable to enable configuring of Yarn proxy (e.g. if you cannot configure these proxy settings yourself in ~/.yarnrc.yml).
If set, and Renovate detects Yarn 2+, and one or both of those variables are present, then Renovate will run commands like yarn config set --home httpProxy http://proxy prior to executing yarn install.
This will result in the ~/.yarnrc.yml file being created or modified with these settings, and the settings are not removed afterwards.
Configuration/conversion of NO_PROXY to Yarn config is not supported.