based/sugar
based/sugar adds convenient syntactic sugar to Laravel, offering fluent helpers and small utilities that cut boilerplate and make everyday PHP and Eloquent code cleaner and more expressive. A lightweight package for developers who value concise, readable code.
Sugar is a one-shot scaffolder rather than a runtime dependency — you install it, run an Artisan command, and from that point on you own the generated code. Treat it like laravel/breeze with a Vue 3 + TypeScript + Vite bias and no Inertia layer.
Minimal path:
composer require based/sugar --dev
php artisan sugar:install
npm install && npm run dev
The install command is the important artifact. It publishes authentication routes, controllers (app/Http/Controllers/Auth/*), Vue components under resources/js, a Blade root layout, and it patches vite.config.ts, tailwind.config.js, and tsconfig.json so Vue/TS work without you wiring them up.
Where to look first:
routes/web.php (and any published routes/auth.php) — the contract for what got wired up.app/Http/Controllers/Auth — LoginController, RegisterController, ForgotPasswordController, ResetPasswordController. These are plain web controllers returning views; there is no JSON API here.resources/js — app.ts entry, the Vue components (Login.vue, Register.vue, ForgotPassword.vue, ResetPassword.vue), and a shared types.ts if present. This is where the TypeScript surface lives.resources/views/auth.blade.php (or similar) — the mount point that boots Vue on each auth page.First use case: get the stock login/register/forgot-password flow building and working end-to-end, then adapt. Do not customize before npm run dev succeeds cleanly — you want a known-good baseline before touching config.
Extend the published controllers, don't wrap them. Because Sugar ships editable code and no facade, the day-to-day pattern is: open RegisterController, add a field, update the Vue form, add the column via a migration. There is no override hook to fight.
// RegisterController@store
$data = $request->validate([
'name' => ['required', 'string', 'max:255'],
'email' => ['required', 'email', 'max:255', 'unique:users'],
'password' => ['required', 'confirmed', Password::defaults()],
'company' => ['required', 'string', 'max:255'], // added
]);
User::create([...$data, 'password' => Hash::make($data['password'])]);
Form submission pattern. Sugar's Vue components post to named web routes via axios (not Inertia visits) and handle 422 validation errors by hydrating a reactive errors object. Keep that shape when you add forms — mixing in a fetch-based API call against the same route will break CSRF handling.
const errors = ref<Record<string, string[]>>({});
async function submit() {
try {
await axios.post('/register', form);
window.location.href = '/home';
} catch (e: any) {
errors.value = e.response?.data?.errors ?? {};
}
}
TypeScript discipline. Sugar's selling point is typed props and form state. Define interfaces next to components (resources/js/types/auth.ts) rather than leaning on any in catch blocks — the whole scaffold loses value if you do.
Tailwind ownership. Sugar configures Tailwind with a content glob for ./resources/js/**/*.vue. If you move components into subfolders or add a design system, extend content explicitly; otherwise classes silently vanish from the build in production.
Integration with an existing app. Run Sugar on a fresh Laravel install, then cherry-pick: copy the Auth controllers, the route group, and the Vue components into your app, and merge its vite.config.ts bits into yours. Running sugar:install on a non-empty app will overwrite vite.config.ts, tsconfig.json, and tailwind.config.js — back them up first or diff carefully.
Blade + Vue per page. Each auth page is a Blade view that mounts a Vue app to a #app element. For multi-page auth flows this is fine; for a larger SPA, wrap each page in its own mount or migrate to Inertia (Sugar deliberately doesn't ship it).
The 2022 date is the headline risk. Last release was April 2022 and it targets Laravel 9 + Vue 3.2 + Vite 2. Laravel 10/11 + Vite 5 changes (defineConfig shape, laravel-vite-plugin versions, Vite 3+ ESM behavior) mean you should expect to hand-fix vite.config.ts and possibly package.json peer conflicts. Budget 30–60 minutes on dependency reconciliation. The scaffolding patterns still transfer; the pinned versions do not.
No community to lean on. 73 stars, 0 dependents, last release two years back. There is no StackOverflow trail for Sugar-specific errors — debug it as plain Laravel + Vue, which is exactly how it's built. The upside: nothing is hidden behind a black box.
Publishing is destructive. sugar:install writes files. If app/Http/Controllers/Auth/LoginController.php already exists it will either skip silently or overwrite depending on the command flags. Check for --force behavior in vendor/based/sugar/src/Console before rerunning on a project with customizations.
CSRF and Axios defaults. Sugar's components rely on the XSRF-TOKEN cookie being present — the Laravel web middleware group handles it, but if you mount Vue outside a Blade view served through web, POSTs will 419. Make sure resources/js/app.ts doesn't strip Axios defaults.
Route namespace collisions. If you have Auth::routes() or Breeze already installed, you'll get duplicate route names (login, register). Delete the old set before publishing Sugar's, or override with ->name('sugar.login') etc.
Password reset mail is config, not code. ForgotPasswordController will call Password::sendResetLink against config/auth.php. If mail is log in local (default), the reset link lands in storage/logs/laravel.log — this is the #1 "reset isn't working" report. Check the log, not the database.
npm run dev vs build mismatch. During dev, Vite serves over the dev server and @vite in Blade points at it; in build, missing Tailwind content globs or wrong vite.config.ts input paths surface only at build time. Always run npm run build before merging an auth change.
Extension points are file edits. There is no container binding, config file, or event to hook into Sugar itself — the extension point is the generated code. That's a feature for readability and a liability for upgrades: nothing will tell you a newer Sugar version changed a controller, because there is no runtime coupling. Version-lock it in composer.json and treat the scaffold as a one-time codemod.
Where it's still worth it. Greenfield Laravel + Vue 3 + TS project, small team, no Inertia requirement, willing to pin 2022-era tooling and own the maintenance. Where it isn't: existing Laravel 11 app, or anything needing Sanctum/API tokens — Sugar ships session auth only.
How can I help you explore Laravel packages today?