redot / updater
Update your redot dashboard with ease
Maintainers
Requires
- php: ^8.1
- laravel/framework: ^10.0|^11.0|^12.0|^13.0
Requires (Dev)
- laravel/pint: ^1.23
README
🚨 Experimental Package - This package is currently in experimental status. Use with caution in production environments.
A Laravel package that provides seamless integration with Redot.dev dashboard scaffold. Keep your Redot-based Laravel project up to date with the latest scaffold improvements and features.
About
Redot Updater is a command-line tool designed to help you maintain and update your Redot dashboard scaffold. It connects to the Redot platform to sync the latest updates, preview changes, and manage your project's evolution over time.
Requirements
- PHP ^8.1
- Laravel ^10.0|^11.0|^12.0
Installation
Install the package via Composer:
composer require redot/updater
The package will automatically register its service provider via Laravel's package auto-discovery.
Usage
The package provides four main commands to manage your Redot dashboard:
1. Login to Redot
Authenticate with your Redot account and get your project token and slug:
php artisan redot:login
This command will prompt you for your credentials and store the necessary authentication tokens for subsequent operations.
2. Logout
Clear your stored authentication credentials:
php artisan redot:logout
3. Preview Changes
Generate a URL to preview the differences between your current project and the latest scaffold:
php artisan redot:diff
This command outputs a URL that you can visit on Redot.dev to review the changes before applying them.
4. Update Project
Update your project to the latest Redot scaffold:
php artisan redot:update
This command performs a git-style 3-way merge. It downloads two scaffold snapshots — your current commit (the "base") and the latest (the "incoming") — and merges each changed file against the version in your project using git merge-file. Files you have not touched update cleanly; files you have customized are merged with your changes preserved when possible.
Default behavior
By default the merge is applied to your project. When a file conflicts, the incoming changes are written with conflict markers in place (the same <<<<<<< / ======= / >>>>>>> markers git merge produces). Open each conflicted file, resolve the markers, and commit. You do not need to re-run redot:update afterwards — the merge is already applied.
Dry run
To preview the merge plan without modifying any files, pass --dry:
php artisan redot:update --dry
This prints what would be written, deleted, or conflicted and exits without touching your project. Re-run without --dry to apply the merge.
Resolving conflicts in your editor
When your project is a git repository, conflicted files are also recorded as unmerged entries in the git index (the same stage 1/2/3 state a real git merge leaves behind). This makes editors treat them as genuine merge conflicts rather than plain modified files:
- In VS Code they appear under Source Control → Merge Changes, and opening one launches the built-in 3-way Merge Editor with Accept Current / Accept Incoming / Accept Both actions.
git statusreports them as unmerged (UU, orDUwhen the file was deleted upstream).- The inline
<<<<<<</=======/>>>>>>>markers are still written to the file, so the CodeLens conflict bar works too — and editors without git integration fall back to those markers.
How it maps the three sides into the index:
| Stage | Side | Source |
|---|---|---|
| 1 | base | the scaffold version at your current commit |
| 2 | ours | your project's file before the merge |
| 3 | theirs | the latest incoming scaffold version (absent when the file was deleted upstream) |
Resolve each file as you normally would, then git add it to clear the unmerged state and commit. There is no need to re-run redot:update — the merge is already applied.
This step is best-effort: if the project is not a git repository (or a git command fails), the conflict markers in the files remain the source of truth and the update still completes.
Commit Changes
Even with the 3-way merge in place, it is still good practice to commit (or stash) your local changes before running the update command, so you can review the resulting diff and roll back if needed.
Limitations
⚠️ Requires git: The update command shells out to git merge-file for the 3-way merge, so the git binary must be on your PATH. Your project itself does not need to be a git repository — but if it is one, conflicts are additionally surfaced in your editor's Source Control view (see Resolving conflicts in your editor).
⚠️ Binary files are not merged: git merge-file only handles text. When a binary file changes upstream, the incoming version replaces your copy (logged as binary). Back up any binaries you have customized before updating.
Contributing
This is an experimental package. Contributions are welcome, but please note that the API and functionality may change significantly in future versions.
License
The MIT License (MIT). Please see License File for more information.
Disclaimer
This package is experimental and should be used with caution. Always backup your project before running update commands. The package maintainers are not responsible for any data loss or issues that may occur during the update process.