How Forest Compares to pesde

pesde  is a package manager for the Luau language, supporting multiple runtimes (Roblox, Lune, and standalone Luau), with design cues from npm, pnpm, Wally, and Cargo. It goes deep on one toolchain. Forest is built for something else: teams shipping games. One registry and one CLI serve Roblox (Luau) and UEFN (Verse), with hosted private packages, team management, enforced licensing, and a verifiable delivery pipeline built in.

If you maintain Luau libraries that also run under Lune, pesde’s multi-target manifest earns its complexity. If you ship games and share code across a team, the comparison below is the one that matters, and it is where Forest pulls away.

At a glance

Built for shipping games

pesde’s manifest exposes targets, engine declarations, scripts, and workspace tooling: real power for toolchain authors, paid for in configuration that every user carries. Forest optimizes for the team shipping a game. Each package targets exactly one platform, the CLI walks you through init and publish with prompts instead of configuration, and versioning is guided: the CLI asks whether a change is a bugfix, feature, or breaking change and bumps SemVer accordingly. A developer who has never touched a package manager publishes correctly on the first try, and what they publish is correct by construction: license present, dependencies exactly as recorded, integrity hash pinned in every consumer’s lockfile.

A registry with services behind it

This is where the gap is widest. Forest’s registry is a hosted product, not only an index:

• Private packages are built in: mark a package private at publish time and it never appears in search, downloads require an authenticated account with access, and tarballs are served through short-lived signed URLs. No Git submodule wrangling or deploy keys to share internal code.
• Studios give teams collective ownership: packages belong to the organization, with ranks, custom roles, per-package permission grants, and an audit log. Members can come and go without orphaning a package.
• Accounts are Forest-native with two-factor authentication on every account, managed on the web rather than through a third-party identity.

Licensing is enforced, not assumed

On pesde, a license is optional metadata; for a commercial team, an unlicensed dependency is a legal question mark. Forest requires a license (an SPDX identifier or a LICENSE file) on every published package, and every version carries a license safety rating, so that question mark cannot enter the registry in the first place.

A pipeline you can verify yourself

Every component that touches package bytes on Forest is open source: the CLI, the publish/download gateway, and the CDN worker. A tarball’s SHA-256 is its storage key, its URL, and the integrity value in your lockfile; the CLI recomputes it on every download and refuses to install on a mismatch. The gateway deploys only from its public repository through GitHub Actions with signed build-provenance attestations. Trust in the registry is checkable, not assumed.

The existing ecosystem, first-class

pesde consumes Wally packages through a separate dependency source type in your manifest. Forest mirrors the open-source Wally catalog directly into its registry, unmodified and automatically updated, with authors’ scopes reserved for them to claim. On Forest a mirrored package is simply a package: same search, same lockfile, same integrity verification, nothing special to declare.

Types and tooling

Forest packages install as real ModuleScripts required by instance path, so Luau types and requires resolve natively in Studio and luau-lsp, with relative link modules generated only where nesting requires them. pesde reaches types through its own generated link-module layer. Both beat the old workflows; Forest just gets there with less machinery between your code and the package.