Installing Apex Stem - Apex Stem Docs

Every Apex Stem framework ships two ways: as an Unlocked Package (2GP, no namespace) and as a git submodule. Both install the exact same source — pick per project, and you can even mix them across orgs.

Which path should I take?

	Unlocked Package (recommended)	Git Submodule
Best for	New projects, production orgs	Existing projects already on submodules, contributors
Framework tests in your deploys	Excluded from `RunLocalTests` — your validates never run (or fail on) framework tests	Run as local tests in every `RunLocalTests` deploy
Org coverage calculation	Framework code excluded	Framework code and tests included
Version visibility	`sf package installed list` shows the exact version	Read the submodule's git tag
Upgrade	Install the next version (in place)	`git submodule update --remote`
Directory layout	Flat right after a retrieve — restore it with `npx apex-librarian arrange` (see below)	Preserved by the submodule itself

The package path exists because framework tests that create real records (ApexBlueprint's integration suite, for example) can collide with org-specific validation rules and required fields. Installed as a package, those tests simply never run in your org — that entire failure class disappears.

Current versions

Framework	Version	Install command
ApexEloquent	v3.10.0	`sf package install -p 04tgK000000JQYHQA4 -o <your-org> -w 10`
ApexBlueprint	v2.1.0	`sf package install -p 04tgK000000HuDtQAK -o <your-org> -w 10`
ApexTrace	v1.5.0	`sf package install -p 04tgK000000HuAfQAK -o <your-org> -w 10`
ApexTools	v1.1.0	`sf package install -p 04tgK000000HuCHQA0 -o <your-org> -w 10`

The frameworks are fully independent — no install order, no cross-dependencies. Install only what you need.

To install from the browser instead, open https://login.salesforce.com/packaging/installPackage.apexp?p0=<install ID> (use test.salesforce.com for sandboxes). Install IDs for older versions are listed on each repository's GitHub Releases page:

ApexEloquent / ApexBlueprint / ApexTrace / ApexTools

Git submodule

BASH

cd /path/to/your/project
git submodule add https://github.com/krile136/ApexEloquent.git  force-app/main/default/classes/ApexEloquent
git submodule add https://github.com/krile136/ApexBlueprint.git force-app/main/default/classes/ApexBlueprint
git submodule add https://github.com/krile136/ApexTrace.git     force-app/main/default/classes/ApexTrace
git submodule add https://github.com/krile136/ApexTools.git     force-app/main/default/classes/ApexTools
git submodule update --init --recursive

sf project deploy start -d force-app/main/default/classes/<Name> deploys each one like any source folder. When cloning a project that uses submodules, remember git clone --recurse-submodules.

Restoring the directory layout

Salesforce orgs have no concept of folders for Apex classes, so classes installed as a package arrive flat in classes/ when you pull them down with sf project retrieve.

As of the versions in the table above (ApexEloquent v3.10.0 / ApexBlueprint v2.1.0 / ApexTrace v1.5.0 / ApexTools v1.1.0), every class declares its own location in an @directory doc-comment tag. After a retrieve, one run of the npm module ApexLibrarian restores the exact directory hierarchy a submodule install would give you:

BASH

npx apex-librarian arrange

Each .cls-meta.xml always moves together with its class. For how it works and the other commands (check / stamp), see the ApexLibrarian page.

Next steps

New to the stack? Start with Get Started with Apex Stem
Per-framework guides: ApexEloquent / ApexBlueprint / ApexTrace / ApexTools