Add LibMan as a new manager

[rm-code]

Tell us more.

I've been working on adding support for libman (Draft PR: #45160) and wanted to open this discussion to provide the "New Package Manager Questionnaire" as well as a clean slate for discussion.

LibMan uses a straight-forward file-format and the manager can be kept quite simple. I have a working version running locally against our ADO environment.

The biggest blocker for its implementation are the two new datasources we need:

• unpkg (already tracked as an issue here Support unpkg in html manager #38153, but this issue conflates the new datasource and the update of the html manager. Maybe a dedicated issue tracking the unpkg datasource should be opened instead). PR draft ready: feat(datasource/unpkg): add new unpkg datasource #45159
• jsdelivr (already tracked as an issue here jsDelivr datasource #26936): PR draft here (feat(datasource/jsdelivr): add new jsdelivr datasource #45015)
• cdnjs => already supported by renovate
• filesystem => afaict no sane way of supporting this properly. Instead I'd skip filesystem deps with reason dep.skipReason = 'local-dependency';.

Other discussions / issues tracking LibMan support

Support for LibMan has been discussed in several places. Apologies if I should've continued one of those:

• Discussion from Mar, 2026 (Support LibMan package manager #41893)
• Discussion from Sep, 2024 (Support LibMan package manager #31250)
• Discussion from Oct, 2023 (Microsoft Libman support #25227)
• Closed Issue from 2018 (Support LibMan package manager #2642)

---

New package manager questionnaire

Did you read our documentation on adding a package manager?

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

Basics

What's the name of the package manager?

LibMan (Library Manager for ASP.NET Core, Microsoft.Web.LibraryManager)

What language(s) does this package manager support?

LibMan isn't tied to a package language. Instead it fetches static client-side assets (JS, CSS, web fonts, source maps, etc.) as opaque files.

LibMan itself (CLI, MSBuild targets, Visual Studio integration) is part of the .NET ecosystem, and libman.json is what a .NET web project uses to declare which client-side libraries it wants to pull into the project files.

How popular is this package manager?

Moderately popular, specifically within the .NET/ASP.NET Core world:

• Microsoft.Web.LibraryManager.Cli (the standalone CLI): ~1.7 million downloads total / 560 per day (source)
• Microsoft.Web.LibraryManager.Build (the MSBuild integration): ~11.3 million downloads / 3700 per day (source)
• It ships as part of Visual Studio, so most ASP.NET Core web devs on Windows have it available even if they don't use it directly.
• It has no adoption outside the .NET ecosystem afaik. It's Microsoft/Visual-Studio-specific tooling, not a general web tool.

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

• Yes (give names).
• No.

LibMan explicitly positions itself as not a package manager and not a competitor to npm/yarn/pnpm.

See aspnet/LibraryManager wiki:

LibMan is not a package management system. If you're happily using npm/yarn/(or something else), we encourage you to continue doing so." It exists for projects that want to grab a handful of CDN-hosted files without adopting a full JS toolchain.

What are the big selling points for this package manager?

LibMan is a client-side library acquisition tool. Libraries are pulled from CDNs (or the filesystem) to be used in projects directly.

In other words it's a nicer way of manually copying client-side library into your project, with the (big) added bonus of helping you keep track of versions and updates. The biggest selling point is that you don't have to set up a full client-side library ecosystem, if you just want to enrich your server-side applications with a bit of client-side code / libraries.

Detecting package files

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

The package file is a json file with a well-defined schema (https://json.schemastore.org/libman) and must be named libman.json, located at the project root (sibling to the .csproj).

Which managerFilePatterns pattern(s) should Renovate use?

["/(^|/)libman\\.json$/"]

This matches a libman.json file at the repo root or in any subdirectory (multi-project repos commonly have one per web project).

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

• Yes, provide details.
• No.

The filename libman.json is fixed by the tooling itself.

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 distinctive filename and (imo) very unlikely to collide with unrelated files.

Parsing and Extraction

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

No. Each libman.json is self-contained.

Package file parsing method

The package files should be:

• Parsed together (in serial).
• Parsed independently.

Not sure if I understand this section correctly, but libman works on a "single-file-per-project" basis. No cross-project references. So we only need to parse one file per project.

Which format/syntax does the package file use?

• JSON
• TOML
• YAML
• Custom (explain below)

Strictly speaking it's JSON (validated against the libman JSON schema. But afaict Visual Studio's editor also tolerates // comments (JSONC) despite that not being in the schema, so the extractor should probably parse it as JSONC to avoid extraction failures for users who've added comments.

{
  "version": "1.0",
  "defaultProvider": "jsdelivr",
  "libraries": [
    {
      "library": "@fortawesome/fontawesome-free@6.7.2",
      "destination": "wwwroot/lib/fortawesome/fontawesome-free/",
      "files": [
        "css/fontawesome.min.css",
        "css/solid.min.css",
        "webfonts/fa-solid-900.ttf",
        "webfonts/fa-solid-900.woff2"
      ]
    },
    {
      // Example comment that isn't supported by schema
      // but doesn't seem to break libman.
      "library": "htmlhint@1.5.1",
      "destination": "wwwroot/lib/codemirror/htmlhint/"
    },
    {
      "provider": "cdnjs",
      "library": "codemirror@6.65.7",
      "destination": "wwwroot/lib/codemirror/"
    },
    {
      "provider": "jsdelivr",
      "library": "tom-select@2.4.3",
      "destination": "wwwroot/lib/tom-select/",
      "files": [
        "dist/css/tom-select.min.css",
        "dist/js/tom-select.complete.min.js"
      ]
    }
  ]
}

How should we parse the package files?

• Off the shelf parser.
• Using regex.
• Custom-parsed line by line.
• Other.

JSONC is already supported by Renovate.

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

• Yes, production and development dependencies.
• No, all dependencies are treated the same.

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

Each entry in the top-level libraries array has a library field of the form:

"library": "[provider-specific-library-name]@[version]"

Example:

{
  "library": "htmlhint@1.5.1",
  "destination": "wwwroot/lib/codemirror/htmlhint/"
},

This is true for all supported providers, except filesystem, which points to a local path and therefore shouldn't / can't be supported by renovate.

Scoped/namespaced names are supported and contain their own @:

"library": "@fortawesome/fontawesome-free@6.7.2",

Extraction must split on the last @, not the first.

If provider is omitted on an entry, it falls back to the file's top-level defaultProvider.

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

I assume this means supported by libman, not renovate:

• cdnjs
• jsdelivr
• unpkg
• filesystem

There doesn't seem to be any active development for other implementations at the moment.

Versioning

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

semver

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

• Supports range constraints (for example: ^1.0.0 or 1.x), provide details.
• No.

Lookup

Is a new datasource required?

• Yes, provide details.
  • cdnjs: supported already. Renovate already has a datasource.
  • jsdelivr: unsupported, but already tracked
  • unpkg: unsupported, but already tracked
  • filesystem: unsupported / no support needed: I don't think it's realistic to support this via Renovate, as a local file store won't have a proper / common registry behind it.
• No.

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

• Yes, provide details.
• No.

Where can Renovate find the custom host/registry?

• No custom host or registry is needed.
• In the package file(s), provide details.
• In some other file inside the repository, provide details.
• User needs to configure Renovate where to find the information, provide details.

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

• Yes, there are constraints on the parent language (for example: supports only Python v3.x), provide details.
• Yes, there are constraints on the parent platform (for example: only supports Linux, Windows, etc.), provide details.
• Yes, some other kind of constraint, provide details.
• No constraints.

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

• Yes, provide details.
• No.

Artifacts

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

• Yes, uses lock file.
• Yes, uses checksum file.
• Yes, uses lock file and checksum file.
• No lock file or checksum.

libman.json is both the manifest and the "lock file" in one. It always records an exact, pinned version per library, so there's no separate lock file.

Is the locksum or checksum mandatory?

• Yes, locksum is mandatory.
• Yes, checksum is mandatory.
• Yes, lock file and checksum are mandatory.
• No mandatory locksum or checksum.
• 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 (see above)

Package manager cache

Does the package manager use a cache?

• Yes, provide details.
• No.

The LibMan CLI does maintain a local disk cache of previously-downloaded library files, but this is purely a CLI-side performance cache for the restore/install commands.

I don't think, that this is relevant for Renovate.

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

• Package manager does not use a cache.
• Controlled via command line interface, provide details.
• Controlled via environment variables, provide details.

libman cache list / libman cache clean

Should Renovate keep a cache?

• Yes, ignore/disable the cache.
• No.

Generating a lockfile from scratch

Renovate can perform "lock file maintenance" by getting the package manager to generate a lockfile from scratch.
Can the package manager generate a lockfile from scratch?

• Yes, explain which command Renovate should use to generate the lockfile.
• No, the package manager does not generate a lockfile from scratch.
• No, the package manager does not use lockfiles.

Other

What else should we know about this package manager?

• As already stated in another discussion, the development of LibMan is slow, but not stale and I can't find any info, that it is being phased out anytime soon. Since it's deeply embedded inside of the VS ecosystem, there should be support for multiple years to come.
• If libman would be sundowned, renovate would still benefit from adding the datasources for jsdelivr and unpkg. These have been requested as datasources for the html manager

[rm-code]

Decided to go ahead with a PR that only adds libman with cdnjs support for now.

[jamietanna]

Duplicate of #41893