mirror of
https://github.com/renovatebot/renovate.git
synced 2026-11-05 20:06:35 +00:00
Sebastian Poxhofer
2dbfd85506
* ci(linter): add renovate/no-sync-io rule Flags calls to a fixed list of Node.js sync I/O APIs (readFileSync, writeFileSync, mkdirSync, rmSync, readdirSync, statSync, existsSync, copyFileSync, execSync, spawnSync, execFileSync) in tools/** and **/*.spec.ts only; production lib code is not targeted. Set to "warn" instead of "error": the repo has 40 pre-existing violations, exceeding the agreed fix threshold of 30, so violations are left in place for follow-up rather than mass-fixed here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(linter): enforce renovate/no-sync-io at error Promote the rule from warn to error now that the codebase has been migrated off synchronous I/O in tools/ and spec files. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(tools): migrate synchronous fs calls to async equivalents Replace *Sync fs calls with their async/promise-based counterparts in tools/ scripts (generate-imports, check runner, utils, cwdchanged hook) now that renovate/no-sync-io is enforced at error there. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * test: migrate synchronous fs calls in specs to async equivalents Replace *Sync fs calls (readdirSync, writeFileSync, existsSync, etc.) with their async/promise-based counterparts across affected spec files, making the enclosing it()/module-scope initializers async as needed, to satisfy renovate/no-sync-io now enforced at error. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(linter): replace custom no-sync-io rule with built-in node/no-sync The oxc built-in covers a superset of the custom fixed-name list. Migrate the additionally flagged sites: async glob in test-shards, async execa in prepare-deps, promisified gzip/generateKeyPair in rpm/hex specs, and rename the misleading execSync mock alias (it mocks the async rawExec). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Datasources
Datasources are used in Renovate primarily to fetch released versions of packages.
Follow the class-based programming style
New datasources must follow the class-based programming style.
Use the java-version datasource as a reference.
Add the datasource to the API in api.ts so that the new datasource is usable.
If you find Unused HTTP mocks errors in the Vitest tests and your mocked URLs are correct, make sure the datasource is correctly registered.
getReleases
The minimum exported interface for a datasource is a function called getReleases that takes a lookup config as input.
The config has:
packageName: the package's full name including scope if present (e.g.@foo/bar)registryUrls: an array of registry URLs to try
getReleases should return an object having:
releases: an array of strings of matched versions. This is the only mandatory fielddeprecationMessage: a string description of the package's deprecation notice, if applicablesourceUrl: a HTTP URL pointing to the source code (for example on GitHub)homepage: a HTTP URL for the package's homepage. Ideally should be empty if the homepage andsourceUrlare the samechangelogUrl: a URL pointing to the package's changelog (could be a Markdown file, for example). If not present then Renovate will search thesourceUrlfor a changelog filetags: an object mapping tag → version, for exampletags: { latest: '3.0.0' }. This is only used by thefollowTagsfunction
getDigest
Datasources that support digests (like Docker digests and Git commit hashes) can export a getDigest function.
The getDigest function has two inputs:
config: the Renovate config for the package being updated, has the same fields asgetReleasesnewValue: the version or value to retrieve the digest for
The getDigest function returns a string output representing the digest value.
If no digest is found, the getDigest function should return null.