Weave Code
App Laravel Package
devdojo/app
DevDojo's Laravel application scaffold, intended as a starting point for apps built on the DevDojo stack. Adoption is minimal and documentation is sparse, so it suits experimentation and reference rather than production use.
This is the repo for the DevDojo products application package
Frequently asked questions about App
- What is devdojo/app used for?
- devdojo/app is a Composer package that provides the Laravel application layer for DevDojo-style projects. It bundles service providers, configuration, routes, and publishable views and assets so you can bootstrap a ready-to-use Laravel application. It is intended as a foundation that other DevDojo packages can be layered on top of, not as a general-purpose Laravel starter kit.
- How do I install devdojo/app with Composer?
- Run composer require devdojo/app inside a Laravel project, then register the package service provider if auto-discovery does not handle it. After installation you can publish the package's views, config, and assets using php artisan vendor:publish. The package also ships installer commands intended to set up the application in seconds, though documentation for them is sparse.
- Does devdojo/app support Laravel 10, 11, or 12?
- There is no declared support for modern Laravel. The last release was in October 2018, which points to the Laravel 5.6 or 5.7 and PHP 7.1 or 7.2 era. Composer will likely fail to resolve illuminate/* constraints on Laravel 10, 11, or 12, and even a forced install would hit removed helpers and container APIs at runtime. Check the package's composer.json constraints before assuming compatibility.
- Is devdojo/app safe to use in production?
- It is not recommended for production. The package has minimal adoption, no visible test suite or CI, and a single release from 2018, so there is no evidence of anyone maintaining it against current Laravel versions. The realistic use is source-level reference or experimentation, not a dependency in a live application.
- How do I publish devdojo/app views, config, and assets?
- Use Laravel's vendor:publish command, optionally scoped with the --provider or --tag flag, after the package service provider is registered. Publishing copies the package's config, views, and front-end assets into your app so you can customize them. Because documentation is sparse, inspect the service provider's publishes() calls to see the exact tags and destination paths.
- What Laravel and PHP versions does devdojo/app require?
- Based on the 2018 release date, expect Laravel 5.6 or 5.7 and PHP 7.1 or 7.2. The repository does not publish a compatibility matrix or CI badges, so the only reliable source is the composer.json in the tagged release. Do not assume support for PHP 8 or newer Laravel majors.
- Will devdojo/app conflict with my existing users table or auth setup?
- Possibly. An application-layer package of this kind often ships migrations, auth guards, and opinionated table names, and those assumptions are not documented in the repo. Before installing, check the package's migrations and config for tables like users, roles, or tenants. If they collide with your schema, you would need to rename or skip them, which usually means forking rather than requiring the package.
- Is devdojo/app still maintained?
- Signals point to no active maintenance: the last tagged release is from October 2018, the repo has around 2 stars, and there are zero dependents on Packagist. There are no CI badges, changelog, or visible test suite. Treat it as frozen unless the maintainer confirms otherwise.
- What are alternatives to devdojo/app for Laravel scaffolding?
- For a modern starter, use the official Laravel installer, Laravel Breeze, or Jetstream depending on whether you want minimal auth or a full stack. If you specifically want DevDojo-style product scaffolding, evaluate newer DevDojo packages or extract the domain design from devdojo/app and reimplement it on your current Laravel version.
- Can I fork devdojo/app and upgrade it to current Laravel?
- Technically yes if the license permits it, but verify the LICENSE file first because an absent license is more restrictive than a permissive one. The port would involve updating illuminate/* constraints, replacing removed helpers, and auditing container bindings and facades. Given the small codebase this is feasible, but it is a source-audit project rather than a drop-in dependency.
Weaver
How can I help you explore Laravel packages today?