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.
Extracts dependencies from the Deno's projects deno.json and deno.jsonc files.
The deno manager also supports the package.json file for Deno's node-compat as long as a deno.lock file is placed next to the package.json file. It could support another lock filename that specified in deno.json or deno.jsonc.
Supported Dependency Types
The following depTypes of deno.json or deno.jsonc are currently supported by the deno manager:
importsscopes.<mapping>.<specifier>tasks.<name>,tasks.command.<name>: Renovate will not update any lock files.compilerOptions.types,compilerOptions.jsxImportSource,compilerOptions.jsxImportSourceTypeslint.plugins
Additionally, an import map JSON file containing imports and scopes.<mapping>.<specifier> like the examples above is supported.
The deno manager also supports some depTypes that supported by npm manager.
!!! note Deno cli supports private npm compatible registries itself, however the deno managaer is not yet ready to support Private npm module.
!!! note In source dependencies are not supported.
import { assert } from 'jsr:@std/assert@1.0.0';