Feature Request: optionally type vendor models

[robverhoef]

A model may use vendor provided models. Or sometimes you just need those models in the front end. I currently don't see an easy way of generating interfaces for these models.
Automagically following related (vendor-) models might become messy quickly. I get that.
But even the option to manually point to specific vendor models, for instance: ./vendor/spatie/laravel-permission/src/Models/Permission.php could also be a great time saver.

[acidjazz]

PR's are more than welcome!

[tcampbPPU]

@robverhoef How does the output look for a vendor model like that using the internal Laravel model:show command?

[robverhoef]

@robverhoef How does the output look for a vendor model like that using the internal Laravel model:show command?

It will look like this:

php artisan model:show "Spatie\Permission\Models\Permission"

Output:

  Spatie\Permission\Models\Permission .......................................
  Database ........................................................... sqlite
  Table ......................................................... permissions

  Attributes .................................................... type / cast
  id increments, unique ....................................... integer / int
  name fillable ..................................................... varchar
  guard_name fillable ............................................... varchar
  created_at nullable, fillable ......................... datetime / datetime
  updated_at nullable, fillable ......................... datetime / datetime

  Relations .................................................................
  roles BelongsToMany ......................... Spatie\Permission\Models\Role
  users MorphToMany ......................................... App\Models\User
  permissions MorphToMany ............... Spatie\Permission\Models\Permission

  Events ....................................................................

  Observers .................................................................
  deleting ................................................. Closure, Closure
  saved ............................................................. Closure
  deleted ........................................................... Closure

[tcampbPPU]

it's because we use laravels app directive i'm not sure i want to avoid using that but maybe a flag to allow full (slow) search of models to pick all them in the vendor directory up. or perhaps a way to add the known vendor models into the config and we can read and map from there

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Livijn]

I think the best solution would be to add a config options to include som files. Today we have included_models in the config, but there are lots of scenarios where you want to add a file - without removing those included by default.

#60 Could be solved by this #87 As well

My proposed solution is to add an option which forces some models & enums to be parsed. At first glance, the included_models is a confusion config option as well. A more proper name would be only_models, then included_models could be those that are "forced". However, changing this would be a breaking change so maybe just come up with another config name in that case.

[RyanSchaefer]

Hey, I think we could use composers autoloader directly instead of relying on laravels proxy to it. Something like this? https://github.com/fumeapp/modeltyper/compare/master...RyanSchaefer:modeltyper:master

This is just a PoC (I don't know if this would slow things down and how exactly is best to incorporate this into the config) but it seems to work. Might be more reliable than the name generation previously used.

[tcampbPPU]

@RyanSchaefer thanks for the suggestion and poc! i didn't know about that util, its something i can look into.

[RyanSchaefer]

@tcampbPPU Going to take a crack at formalizing this tonight.

Any advice for what could potentially be replaced?

Is that change touching too much of core functionality?

Would an "additional_paths" config variables make sense here?

[tcampbPPU]

@tcampbPPU Going to take a crack at formalizing this tonight.

Any advice for what could potentially be replaced?

Is that change touching too much of core functionality?

Would an "additional_paths" config variables make sense here?

I like the idea of a "additional_paths" config variable.

For what to change it should just pretty much be the GetModels action, this part:

collect(File::allFiles(app_path()))

thats where a config or additional path config would work for when there are cases outside of the traditional scope to locate models

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.