sala/framework
Sala Framework is a Laravel/PHP package that offers a structured foundation for application development, with reusable conventions and Laravel-friendly integrations to help streamline building and maintaining web projects.
The v1.2.0 release is primarily a packaging and namespace migration, not a feature drop. Before anything else, get the new coordinates right — everything below assumes sala/framework.
New project:
composer create-project sala/framework my-app
The README now documents sala/framework (the old salaab/framework typo and abraaosala/tchiowa are dead names).
Existing project — rewrite requires and repositories:
{
"require": {
"sala/framework": "^1.2",
"sala/console": "^1.0"
}
}
Delete any repositories entries pointing at file:../mcp or a local mcp/sala path — both packages are now consumed from their registries.
Refresh the lock file, don't hand-edit it. composer.json edits alone won't drop the stale name:
rm -rf vendor composer.lock
composer install
First use case: run the console entrypoint (sala/console provides bin/console) to confirm the framework boots against the extracted package:
php vendor/bin/console list
Where to look first: docs/packages.md in the framework repo. The ecosystem map was deliberately moved out of the README, so the README no longer tells you the full story — docs/packages.md is the canonical list of sala/console, @salasolucoes/mcp, and anything added later.
If you use the MCP server, install the Node side separately — it is not a Composer dependency:
npm i -D @salasolucoes/mcp@^1.0.0
Pin the trio together. sala/framework ^1.2, sala/console ^1.0, and @salasolucoes/mcp ^1.0.0 are now independently versioned but were developed in lockstep. Treat them as a cohort: bump them in one PR, commit composer.lock and package-lock.json together. A framework bump with an old console package is the most likely source of confusing CLI failures post-extraction.
Console as the single entrypoint. Since sala/console ships bin/console, standardise on one invocation path across local, CI, and containers. Don't mix php bin/console in one script and php vendor/bin/console in another — post-split they resolve the same code but different bootstrapping paths, and only one will pick up your project root correctly.
Agent-assisted workflows via MCP. The npm package exposes project context over the Model Context Protocol, so the day-to-day pattern is: register the MCP server with your client (Claude Code, Cursor, or any MCP-compatible editor), point it at the project, and let it read the codebase/console surface. Combined with sala/console, this gives you a loop of agent proposes console command → you run it → agent reads result — useful for scaffolding and repetitive refactors.
Explicit project root in monorepos and CI. findProjectRoot() is now "universal", which is convenient but heuristic. Where the heuristic can be wrong — nested apps in a monorepo, CI checkouts at non-standard paths, containers with a bind-mounted subdirectory — set it explicitly instead of hoping:
SALA_PROJECT_ROOT=$(pwd) php vendor/bin/console <command>
Mirror the same env var in your MCP client config so both halves of the toolchain agree on which app they're talking about.
Namespace refactor as a codemod, not a find-and-replace. The salaab/framework → sala/framework fix is a typo correction, so anything that string-matched the old typo (salaab/framework in an import, a config array, a Dockerfile, a CI cache key, a composer.json in a sibling package) will silently stop resolving. Grep the whole org for salaab, abraaosala, and tchiowa — including README fragments, .github/workflows, and Makefiles — rather than just the root project.
Treat docs/ in the framework repo as private. The new .gitignore rule is /docs/* with only !/docs/packages.md re-included. That's the framework's own convention; don't copy it into your application. If you vendor or fork the framework, be aware that adding a file under docs/ will be ignored unless you add your own negation.
replace of abraaosala/tchiowa, no alias for salaab/framework. Old manifests will fail resolution outright, which is loud, but stale lock files and CI caches will fail more quietly. Invalidate Composer caches in CI when you cut over.file:../mcp removal bites local setups. If anyone was developing against the in-repo MCP package, their node_modules and package-lock.json still point at a path that no longer participates. Full reinstall of the JS side, not just an install.abraaosala/tchiowa, salaab/framework, sala/framework. Anything you read online predating v1.2.0 may reference the first two. Verify against docs/packages.md before trusting a blog post or an old issue thread.install step, and a CI pipeline that only runs composer install will leave MCP missing (and vice versa — npm ci alone won't get you a working console).SALA_PROJECT_ROOT is a debugging lever. When findProjectRoot() disagrees with reality — MCP reading the wrong app, console writing to the wrong path — set the env var and re-test before filing anything upstream. If it works with the var and fails without, that's a root-detection bug worth reporting with your directory layout.bin/console actually executed (which/console --version), then confirm the project root the process resolved. Most post-migration CLI confusion is one of those two facts, not the command itself.docs/packages.md is the intended integration surface for the ecosystem — the release explicitly frames it as the map, and the README link is deliberately "discreet". If you're building on top of the framework, read that file as the contract for which packages exist and at what versions; a new package appearing there is your early signal of where the framework is heading.How can I help you explore Laravel packages today?