New package manager: LibMan (libman.json)

[mu88]

LibMan support (proposal + intent to implement)

Hi maintainers,

I'd like to propose adding support for Microsoft LibMan (libman.json manifests) as a new manager, and I'm willing to implement it myself. Filling out the questionnaire below as requested.

• I've read the adding a package manager documentation.

Basics

What's the name of the package manager?

LibMan (Library Manager), a lightweight client-side library acquisition tool for .NET/ASP.NET Core projects, maintained by Microsoft (source).

What language(s) does this package manager support?

Primarily .NET/ASP.NET Core projects, but the manifest itself only fetches client-side (front-end) assets: JS/CSS libraries such as Bootstrap, jQuery, Leaflet, Font Awesome, etc. It's not tied to any specific application language beyond ASP.NET Core tooling integration.

How popular is this package manager?

It ships built-in with Visual Studio and the ASP.NET Core SDK templates as the default client-side library acquisition tool since .NET Core 2.x (previously bower/npm were common alternatives). Adoption is real but niche compared to npm - I don't have hard usage numbers, but it's a first-party Microsoft tool bundled with the .NET SDK/Visual Studio tooling for years.

Does this language have other (competing?) package managers?

• Yes: npm, Yarn, pnpm, Bower (deprecated) are the general JS/CSS ecosystem alternatives. LibMan's differentiator is that it requires no Node.js toolchain at all - it fetches individual files from a CDN or local filesystem directly into the project, which fits pure .NET/ASP.NET Core projects that don't want a Node-based build pipeline.

What are the big selling points for this package manager?

No Node.js/npm toolchain dependency; integrated into the .NET SDK (dotnet tool install -g Microsoft.Web.LibraryManager.Cli) and Visual Studio UI; simple, declarative manifest; supports restoring only specific files from a package rather than the whole distributable.

Detecting package files

What kind of package files, and names, does this package manager use?

A single JSON manifest file, always named exactly libman.json, typically at the project root but can be nested in any subdirectory (multiple manifests per repo are possible).

Which managerFilePatterns pattern(s) should Renovate use?

/(^|/)libman\.json$/

Do many users need to extend the managerFilePatterns pattern for custom file names?

• No. The filename is fixed by the LibMan CLI/tooling and not configurable.

Is the managerFilePatterns pattern going to get many "false hits" for files that have nothing to do with package management?

No, libman.json is a fixed, LibMan-specific filename with no other common use.

Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

No, each libman.json is fully self-contained.

Package file parsing method

• Parsed independently.

Which format/syntax does the package file use?

• JSON

How should we parse the package files?

• Off the shelf parser (JSON.parse).

Does the package file have different "types" of dependencies?

• No, all dependencies are treated the same (a flat libraries array, each entry is one client-side library/asset set).

List all the sources/syntaxes of dependencies that can be extracted

Each entry in libraries[] has a library field encoded as "<name>@<version>" (single string), plus an optional provider field (falls back to a root-level defaultProvider). Known providers: cdnjs, jsdelivr, unpkg, filesystem.

• cdnjs: library is a plain cdnjs library name, e.g. spin.js@1.2.5.
• unpkg: library is an npm package name (unpkg only mirrors npm).
• jsdelivr: library is normally an npm package name, but LibMan's own jsDelivr provider also supports a GitHub-hosted mode: if the name part contains a / (and doesn't start with @, which is reserved for npm scoped packages), it's treated as owner/repo and resolved against jsDelivr's GitHub-backed endpoint instead of its npm-backed one (confirmed by reading the IsGitHub() check in JsDelivrCatalog.cs). So a jsdelivr entry isn't reliably "just npm" - I initially missed this and want to flag it here.
• filesystem: references a local path instead of a versioned package and has no version to track.

Describe which types of dependencies above are supported and which will be implemented in future

Initial implementation would support cdnjs (via the existing CdnjsDatasource) and skip filesystem entries (no version). I would need guidance on jsdelivr/unpkg, both for the plain-npm case and especially the jsDelivr GitHub-hosted case, since no matching datasource currently exists in Renovate for either - see below.

Versioning

What versioning scheme does the package file(s) use?

Semantic Versioning (semver) in practice, matching whatever the underlying provider serves. Correction to an earlier draft of this questionnaire: LibMan also supports the literal keyword latest in place of a version (library@latest, see ManifestConstants.LatestVersion in the LibMan source), which always resolves to the newest available version at restore time rather than a pinned version. Renovate would presumably treat that the same way it treats latest/*-style non-pinned values for other managers (i.e. nothing to bump, possibly worth a warning).

Does this versioning scheme support range constraints, like ^1.0.0 or 1.x?

• No. Only exact pinned versions (or the special latest keyword above) are supported - no ranges like ^1.0.0/1.x.

Lookup

Is a new datasource required?

• Yes, provide details: for the cdnjs provider, the existing CdnjsDatasource is a direct fit (confirmed by reading its source - it looks up api.cdnjs.com/libraries/<name> by plain library name, matching LibMan's cdnjs library naming exactly). For jsdelivr and unpkg providers, no matching datasource currently exists in Renovate (lib/modules/datasource/ has no jsdelivr/unpkg folder). I'd like to discuss with maintainers whether (a) a new jsdelivr/unpkg datasource should be built as part of this work - jsDelivr has a documented data API for both its npm-backed mode (https://data.jsdelivr.com/v1/package/npm/<name>) and its GitHub-backed mode (https://data.jsdelivr.com/v1/package/gh/<owner>/<repo>), while unpkg has no official metadata API and only mirrors npm - or (b) an initial version should only support cdnjs and treat jsdelivr/unpkg as a known follow-up limitation.

Will users want (or need to) set a custom host or custom registry for Renovate's lookup?

• No.

Where can Renovate find the custom host/registry?

• No custom host or registry is needed (each provider has a fixed, well-known endpoint).

Are there any constraints in the package files that Renovate should use in the lookup procedure?

• No constraints.

Will users need the ability to configure language or other constraints using Renovate config?

• No.

Artifacts

Does the package manager use a lock file or checksum file?

• No lock file or checksum.

Is the locksum or checksum mandatory?

• Package manager does not use locksums or checksums.

If lockfiles or checksums are used: what tool and exact commands should Renovate use to update one (or more) package versions in a dependency file?

N/A (no lockfile). The actual on-disk assets are not restored by Renovate itself; a separate CI step (libman restore, via the microsoft.web.librarymanager.cli .NET tool) fetches the files at build time based on the (updated) libman.json.

Package manager cache

Does the package manager use a cache?

• No (LibMan CLI fetches directly from the provider on each restore invocation; no local cache to manage).

If the package manager uses a cache, how can Renovate control the cache?

• Package manager does not use a cache.

Should Renovate keep a cache?

• No.

Generating a lockfile from scratch

• No, the package manager does not use lockfiles.

Other

What else should we know about this package manager?

I currently work around the lack of native support with a customManagers regex entry in my shared Renovate preset, targeting the "library": "name@version" string regardless of provider and mapping it to the npm datasource as an approximation (since most LibMan-tracked libraries I use are also published to npm under the same name). This is a known imprecise stopgap - it doesn't distinguish provider values, so cdnjs-provided entries (and any GitHub-hosted jsdelivr entries, see above) are also (inaccurately) resolved via npm, and I disable automerge for anything it produces as a mitigation. I'm opening this discussion because I'd rather contribute proper native support than rely on that workaround long-term, and I'm willing to do the implementation work (extraction logic, tests, docs) if maintainers are open to it. I'd appreciate early feedback on the jsdelivr/unpkg datasource scope question above (including the GitHub-hosted jsDelivr case I initially overlooked) before I start implementation.

[jamietanna]

Duplicate of #41893

[mu88]

sry, I somehow missed that one 🙈