v3.1.0

A plugin can now keep its own stubs: every make:* command reads stubs/ first, and php bones stub:publish copies the framework's there to start from.

bones

• Your own stubs come first (#133, #134). Up to 3.0.0 every make:* command read its template from vendor/wpbones/wpbones/src/Console/stubs, so changing what the generators write meant editing vendor/, and the next composer update put it back. Now a stub in the plugin's stubs/ folder wins, and the command says so (Using stubs/controller.stub). The placeholders ({Namespace}, {ClassName}, {Path} and each stub's own) are filled as before.
• php bones stub:publish [<stub> ...] [--force] copies the framework's stubs into stubs/: all of them, or the ones you name. A stub already there is kept unless you pass --force, since it is usually one you have edited; an unknown name lists the stubs there are and writes nothing.
• deploy leaves them out. The .stub files in stubs/ never reach the package. A stubs/ folder that also holds other files keeps them.
• A stub found nowhere now stops the command before anything is written.

Upgrading

composer update wpbones/wpbones. Nothing to change: without a stubs/ folder every command writes what it wrote in 3.0.0. A published stub no longer follows the framework's: after an update, compare it with vendor/wpbones/wpbones/src/Console/stubs/, or take the new one with php bones stub:publish <stub> --force (your edits go).

Docs: Customizing the stubs

Full Changelog: v3.0.0...v3.1.0