blueprint
blueprint copied to clipboard
laravel-shift
Ability to publish and customize stubs, possibly align with Laravel stubs
Hey there,
I was wondering if it was possible we could get different stubs for the views other than blade. For example; Inertia.js, Livewire, Vue components perhaps?, other frameworks I probably don’t know about.
If this isn’t really feasible because you don’t want to maintain things like that, is it possible we could get some sort of way to define a custom stub? Perhaps provide a path where the files should be created in a config as well as the path to the stub we want to use?
Fairly new to this package but I’m a big fan and I feel like this is one of the features that will allow more developers of different frameworks to reap the benefits of this amazing package! (Especially since a lot of projects call for something other than blade SSR)
I like it.
Renamed and labelled the issue.
The primary focus of this issue will be for a developer to "publish" the stubs and modify them. Blueprint should attempt to read these first, then fallback to the package versions.
Laravel 7 does something similar. So ideally, we would publish to the same location. Possibly allowing devs to use the same stuff for both Blueprint code generation and artisan make generation.
Note this would require overlap in the placeholder names used to ensure compatibility. So this is not a requirement, but worth looking into.
I'd like to second this request. I believe it will add more flexibility to the package and make it way easier to integrate into existing projects.
Great. You, or future readers, please feel free to open PR with some work. Otherwise, I'll probably start working later next week.
@jasonmccreary I'm also looking for the ability to edit other stubs, like controller once and so on will there be the ability to doing something like this?
Hey @jasonmccreary
Just wanted to chime back in on this. Since I opened this I’ve been playing around with Livewire and noticed they use an artisan command for their stubs.
It might be cool not only to be able to define your own custom stubs, but also to disable those stubs completely and just execute an artisan command instead for frameworks that support that already.
Just another idea I thought of, not sure if you’ve already considered this. 😅
I'm not sure what Livewire does with its stubs or exactly what you're suggesting. Can you provide a real-world use case?
@jasonmccreary Sorry for the late reply, been busy with some stuff.
Well to explain Livewire has an artisan command artisan make:livewire <name> and then it will create a blade file here resources/views/livewire/<name.blade.php>, as well as a php class to app/Http/Livewire/<name>.php
Blade Stub: https://github.com/livewire/livewire/blob/master/src/Commands/livewire.view.stub
Class/Controller Stub: https://github.com/livewire/livewire/blob/master/src/Commands/livewire.stub
Obviously to support something like this would be pretty big maintenance that I'm sure you guys don't want to deal with, so in my suggestion above I was stating it might be cool to be able to disable stub generation completely on Blueprints end and instead be able to specify an artisan command that runs instead (that way you could easily use the make commands built into other packages to generate their stubs!)
Hi @jasonmccreary,
The view generator seems to be ready, but it's lacking some basic docs. It's also tagged with the v2 label. I don't see a v2 branch though.
What are the plans for officially supporting the view generator?
I'm new to Blueprint, but I'm loving it so far - such a wonderful tool. Thank you for creating it.
Yes, there is a very basic ViewGenerator which simply outputs templates. You are welcome to swap out that generator with your own.
"v2" has not been started yet. Maybe mid-2021. I would not wait though. ;)
@benjam-es, I am not sure. I don't think so though. The Blueprint stubs seem to still have their own placeholders.
I must have mis-read. Ignore me.
I thought the issue seemed to request the ability to simply publish blueprint stubs, then for the end used to modify their own view stub (which was already in place)
@jasonmccreary is the goal here still https://github.com/laravel-shift/blueprint/issues/164#issuecomment-621973749? If so I could work on that next week though it seems like the initial goal in this issue was resolved with https://github.com/laravel-shift/blueprint/pull/530.
Yes, in a nutshell, it would be awesome if Blueprint used the same stubs whenever they overlap with Laravel's. i.e. migrations, policies, etc.
Some may not be more difficult given the amount of code Blueprint injects. For example, a model or controller. So ideally start with what immediately overlaps and we'll go from there.
Alright, will take a look next week and see which ones are the fastest to test/integrate to see how feasible it is.