Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Somake Laravel Package

soyhuce/laravel-somake

A small Laravel package from Soyhuce that adds handy Artisan make commands, streamlining code generation so you can scaffold classes and boilerplate quickly and keep new files consistent with your project's conventions.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Framework upgrade timing ("can we move to Laravel 12?"): The 3.1.0 release explicitly runs its test suite against Laravel 12, which is the signal you need before committing Laravel 12 as a roadmap milestone for any product depending on this package. Without a tested minor release, a Laravel 12 upgrade would carry a "unverified dependency" risk item; with it, that risk can be closed.
  • Build vs. buy for scaffolding/code-generation conventions: laravel-somake (Soyhuce's "So...make" wrapper around Laravel's make: commands) exists to enforce an opinionated directory/structure convention for generated classes. This is a classic build-vs-buy call: the alternative is writing your own custom make: commands or adopting a different scaffolding package. A healthy, maintained release cadence (now with L12 CI coverage) supports buying/adopting rather than maintaining bespoke Artisan scaffolding.
  • Adoption gating on a new Laravel major: If the product roadmap says "start new services on Laravel 12," this release is the green light to include laravel-somake in the base project template / starter kit rather than deferring it to the next minor.
  • Dependency hygiene as a product-risk input: The dependabot/fetch-metadata bump is a CI/tooling-only change. It is evidence of an actively maintained supply chain, which is relevant when scoring third-party packages in a dependency-risk register, but it is not a feature your users will see — do not let it inflate the package's perceived value in a build-vs-buy scorecard.
  • Explicit non-impact: This is a minor bump with no new user-facing features and no deprecations. It should not move the needle on feature roadmaps, pricing, or user-facing release notes. The PM-relevant delta is compatibility confidence, not capability.

When to Consider This Package

Consider adopting laravel-somake when:

  • You want opinionated, consistent scaffolding. Your team has (or wants) a fixed convention for where generated classes land and how they're named, and you're tired of every developer hand-editing files after php artisan make:*. This package's whole reason for existing is to encode that convention as commands.
  • You are standardizing on Laravel 12 and need a "tested against L12" signal. Release 3.1.0 adds Laravel 12 to its test matrix. If your base image or starter template pins Laravel 12, this is the version to pin (^3.1), and prior 3.0.x versions are the ones to avoid on L12 unless you're willing to run the test suite yourself.
  • You're on Laravel 11 or earlier and just want stability. The 3.1.0 changes are additive compatibility work plus a CI tooling bump; there are no breaking changes from 3.0.2, so upgrading is low-risk. Note that running on an older Laravel than the tested matrix is not what this release validates — check the package's composer.json constraints rather than assuming backward coverage from the changelog.
  • You already maintain custom Artisan commands for this. If you have in-house make: extensions and they're working, the migration cost is real and the payoff is mostly consistency, not capability. Deprioritize.

Look elsewhere when:

  • You need active feature development. This release is a maintenance release: two dependency/CI changes, no features, no fixes, no deprecations. If your roadmap depends on this package gaining capability (new generators, config options, integrations), the changelog gives you no evidence of near-term investment. Evaluate it as a stable utility, not an evolving platform.
  • You have zero opinion on code layout. If your team doesn't want enforced conventions, the wrapper adds indirection over vanilla php artisan make: for no benefit.
  • You can't take a new dependency for scaffolding alone. The cost of an extra Composer dependency in every project — security review, upgrade cadence, license/compliance checks — may exceed the value of a thin convention wrapper, especially since Laravel's native make: commands support custom stubs natively in recent versions.
  • You're on a Laravel version outside the supported range. Version 3.1.0 targets current Laravel lines up through 12. If you're pinned to an older major, verify constraints first; this changelog doesn't claim support for anything below the tested matrix.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated soyhuce/laravel-somake, a small open-source Laravel package that standardizes how our engineers generate boilerplate code. The new 3.1.0 release is a maintenance release — it adds automated test coverage against Laravel 12 and refreshes a CI tooling dependency. There are no new features and no breaking changes. The practical business value is that it removes a blocker from our Laravel 12 upgrade path: we can now certify this piece of our stack for the newer framework version instead of carrying it as an open risk. The cost is one lightweight, freely licensed dependency; the maintenance signal (recent, tested releases) is healthy. Recommendation: approve pinning ^3.1 in our Laravel 12 templates, and treat the package as a stable utility rather than a strategic bet — it is not receiving feature investment, so we should not build roadmap commitments on top of it.

For engineering leads (the short version):

  • Upgrade from 3.0.2 to 3.1.0 is safe: no breaking changes, no deprecations, no API surface changes. Changes are (a) Laravel 12 added to the test matrix and (b) a Dependabot bump of dependabot/fetch-metadata 2.2.0 → 2.3.0, which affects only our CI metadata automation, not runtime code.
  • The 3.1.0 CI run is the evidence we need to clear the "does it work on Laravel 12?" checkbox. Treat it as tested against L12, not guaranteed on every L12 minor — pin the version and keep it in the upgrade regression suite.
  • No migration work required; bumping the constraint and running the existing test suite is sufficient validation.
  • Set expectations: this is a maintenance-only release. If a roadmap item depends on new generators or configuration from this package, that dependency is currently unfunded upstream — plan to implement it ourselves or choose an alternative rather than waiting.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox