Haxe haxelib¶

ID: haxelib
Links: Home page · Documentation · Repository
Upstream stars: ⭐ 196
Last commit: 2026-09-26
Version requirement: >= 4
Platforms: 🅱️ BSD · 🐧 Linux · 🍎 macOS · ⨂ Unix · 🪟 Windows
Operations: installed · search · install · upgrade · upgrade_all · remove
purl types: pkg:haxe/ · pkg:haxelib/
CLI name: haxelib
Issues and PRs: 📦 manager: haxelib
Source: haxelib.toml

haxelib is the Haxe language’s package manager (https://github.com/HaxeFoundation/haxelib).

Every invocation carries --global. Without it RepoManager.getPath walks the whole directory tree upwards looking for a .haxelib directory and silently switches to that project-local repository the moment it finds one, so any ancestor of the working directory can hijack the listing. --global calls Repository.getGlobal() instead, which never consults the working directory at all. HAXELIB_PATH is not a substitute: it only redirects which repository counts as the global one, and is consulted after the local lookup has already won.

--always answers every prompt yes. haxelib prompts on paths mpm must not block on: setting an already-downloaded version as current, and, for a VCS-installed library, resetting the checkout before updating. That second one discards uncommitted work in the user’s haxelib checkout, which is the cost of running unattended and is why the flag appears only on the mutating operations.

--quiet silences the download progress renderer, which writes erase-line control bytes to stdout unconditionally: haxelib performs no TTY detection anywhere, so a pipe gets them too. It does not silence Cli.print, so the data output every parser below reads is unaffected. There is no color to suppress: the only escape sequences in the whole client are those erase-line ones.

No outdated: haxelib ships no non-mutating way to list upgradable libraries. update interleaves the staleness check with the upgrade inside one loop, so there is no half of it to run. The upstream request for machine-readable output that would make one possible has been open since 2019 (https://github.com/HaxeFoundation/haxelib/issues/438), and no command emits JSON. upgrade --all still works.

No cleanup: haxelib has no cache to clear and no old-version pruning. Downloads land straight in the repository. No sync either: search queries the live registry, so there is no local index to refresh.

No escalation is declared. The default global repository is a root-owned system directory on Unix, but whether that applies is a property of the installation rather than of the invocation: haxelib setup records the path, and distribution and Homebrew packages commonly point it somewhere the user owns. haxelib has no user-install mode to switch to (https://github.com/HaxeFoundation/haxelib/issues/330, open since 2016), so a read-only repository surfaces as haxelib’s own error rather than as something mpm can escalate around.

What `mpm` adds to `haxelib`¶

Through mpm, haxelib gains --exact and --extended search, to narrow to exact names or match descriptions.

Bigger still, mpm reaches across every manager at once: mpm installed and mpm outdated cover haxelib alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Your `haxelib` commands, in `mpm`¶

You already know haxelib: each operation maps one-to-one onto mpm, in an interface shared by every manager.

To…	With `haxelib`	With `mpm`
List what’s installed	`haxelib --global list`	`mpm --haxelib installed`
Search for a package	`haxelib --global --quiet search <query>`	`mpm --haxelib search <query>`
Install a package	`haxelib --global --always --quiet install <package_id>`	`mpm install pkg:haxelib/<package_id>`
Upgrade one package	`haxelib --global --always --quiet update <package_id>`	`mpm --haxelib upgrade <package_id>`
Upgrade everything	`haxelib --global --always --quiet update`	`mpm --haxelib upgrade --all`
Remove a package	`haxelib --global remove <package_id>`	`mpm remove pkg:haxelib/<package_id>`

Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.

Operations¶

Operation	Supported	Notes
`installed`	✅
`outdated`
`orphans`
`search`	✅	Exact and extended search backfilled by `mpm`.
`install`	✅
`upgrade`	✅
`upgrade_all`	✅
`remove`	✅
`sync`
`cleanup`
`doctor`

Configuration¶

Ignore haxelib on the mpm CLI by passing the --no-haxelib option.
Ignore it for every run in your configuration:
```
[mpm]
haxelib = false
```
Raise the timeout of all haxelib calls:
```
[mpm.overrides.haxelib]
timeout = 900
```

Run mpm config-template haxelib to print all overridable settings for your configuration file:

[mpm.overrides.haxelib]
cli_names = [
    "haxelib",
]
cli_search_path = []
dry_run = false
ignore_auto_updates = true
plan = false
post_args = []
pre_args = []
pre_cmds = []
requirement = ">=4.0.0"
stop_on_error = false
unmaintained = false
version_cli_options = [
    "version",
]
version_regexes = [
    "^(?P<version>\\d+\\.\\d+\\.\\d+(?:-[a-z]+(?:\\.\\d+)?)?)",
]

Recipes¶

A few jobs you would otherwise script around haxelib, one mpm command each:

Snapshot and clone a machine: mpm --haxelib dump haxelib.toml, then mpm restore haxelib.toml on the next one.
Export a compliance SBOM: mpm --haxelib sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation¶

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

None of its operations is privileged.

See privilege escalation for the full policy.

Cooldown¶

State of Haxe haxelib’s release-age gating, from the cooldown support table:

Status: ❌ None

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

Registry: Haxe library registry (pkg:haxe)
Retraction: None client-side: the remoting API is submit-only, exposing processSubmit with no delete, unlisting or yank counterpart (SiteApi.hx), so withdrawing a release means Haxe Foundation intervention on the server
Publish date: ✅ server-set per-version release date, carried as VersionInfos.date (MetaData.hx)

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --cooldown best-effort opts back in.

Reference traces¶

A collection of raw native outputs captured from the manager’s own CLI and recorded in the bundled definition. If you know Haxe haxelib well and a transcript below looks wrong, or a newer release changed its output format, report it.

$ haxelib --global list
flixel: 5.8.0 [git]
format: [3.5.0]
hamcrest: [3.0.0]
hxcpp: [4.3.2]
thx.semver: 0.2.2 [git]

$ haxelib --global --quiet search {query}
flixel
flixel-addons
flixel-ui
3 libraries found

Version check¶

The version is probed by running:

$ haxelib version
4.2.0

and extracted with:

r"^(?P<version>\d+\.\d+\.\d+(?:-[a-z]+(?:\.\d+)?)?)"

Upstream project¶

Metrics	`HaxeFoundation/haxelib`
Activity
Popularity
Metadata

Changelog¶

8.0.0 (2026-09-20)
- Resolve the pkg:conda, pkg:golang, pkg:haxe and pkg:nuget pURL types to these managers, which raised instead of routing.
- Add the Haxe haxelib package manager with installed, search, install, upgrade and remove support, every call forced --global. It declares no outdated, haxelib computing staleness only while upgrading.