Related files picker

[haringsrob]

Hey there!

Stumbled on your plugin by accident, will for sure give it a try.

One cool picker would be related files.

For example when you are on a Model :Laravel related could show:

• Filament resource
• Migrations
• Policy
• ...

This could be done based on the name of the model I guess?

[adalessa]

So your idea is base on the name of the file, have different rules to look for controllers, models, migration, factory.
I'ts an interesting idea.
It's doable, is necessary to define a map of relations that can both in all ways.

[haringsrob]

Yea, I often am in a model for example and I would quickly want to jump/look at the migrations or go to the policy etc.

[dorkster100]

Perhaps it makes sense to contribute this functionality to laravel core to show this info in php artisan model:show and then build off of that? Otherwise this seems a bit questinable.

[adalessa]

I see your point @dorkster100, not sure if the core team will approve something like that.
For sure if a command provides that will make it all easier. I've been thinkin to create a php package that can be installed as a dev-dependency to work along with the plugin.
This will allow the plugin to rely on that package and the package to use interfal framework resolutions and information.

[haringsrob]

@adalessa I have already been working on such package here: https://github.com/haringsrob/laravel-dev-tools

I made it there so you do not have to install it in your project but rather as a global composer package.

Perhaps we can join some efforts?

[adalessa]

@haringsrob I checked you package some time ago looking for the autocomplete for blade. I will check it out again, and see how can be integrated.

[dorkster100]

@adalessa I have already been working on such package here: https://github.com/haringsrob/laravel-dev-tools

I made it there so you do not have to install it in your project but rather as a global composer package.

Perhaps we can join some efforts?

I was also looking into your plugin, what stopped me was the This LSP is based on php in your runtime. I have not tested this with docker so for now assume it will not work from outside.. I assumed that the whole application has to be working locally, am i wrong? Having local php is fine to run LSP. There are many features that are interesting there.

I see your point @dorkster100, not sure if the core team will approve something like that. For sure if a command provides that will make it all easier. I've been thinkin to create a php package that can be installed as a dev-dependency to work along with the plugin. This will allow the plugin to rely on that package and the package to use interfal framework resolutions and information.

I created an Idea, in the discussion area of their github, will see. In general the idea to have some dev dependency create some artisan commands or something like that for it is very interesting and reusable.

[adalessa]

Agree that having inside the code base as package makes it easier to run in container environments because it can be as an artisan command. For the laravel-dev-tools makes sense trying to be outside since operates as lsp so you don't want an lps server per project.

[dorkster100]

Regarding policies, we should actually be able to get them from model:show according to code in https://github.com/laravel/framework/blob/c36812aad058f5c408f79331b8086c0f68f24ae4/src/Illuminate/Database/Console/ShowModelCommand.php#L20
It does not work for me though. I will debug later.

There are still issues with getting migrations.

Regarding supporting third party packages - it is another question in itself. We could probably start by just using the model:show command and display relations files, policies, observers, etc.

Is there anything else we are missing?

[dorkster100]

laravel/framework#47043 we got the policy thing fixed now, so we can fully depend on it