Setting for disables the check directory

[stolentine]

I don't use a standard directory structure in my projects, but I want to use your plugin to generate files.

Please add a setting that disables the check directory.

[NiclasvanEyk]

Hi @stolentine, I am afraid that even if such a setting would exist, the code generation would not work as expected.

Under the hood this plugin just executes the artisan make:* commands for you. These do not provide a way to generate files outside the default directory structure. See this part of the make:request command.

If you have an idea how to make this work please let me know!

[bfinlay]

I just installed the plugin because I discovered it in the marketplace.

Great plugin!

I have the same feature request as this.

At first I was confused why they were greyed out. I thought I had to restart PHPStorm. After fiddling I realized it was dependent on the directory. Some documentation would help clarify this. If the Marketplace description had a direct link to the github readme that would help as well. (I have never published a Marketplace plugin so I do not know what the limitations on description might be.)

A suggestion for how to implement this feature request:

1. run artisan make command
2. move generated file from default directory to new directory
3. (optional) ideally update the namespace of the file to match the target directory namespace

This is what I did manually, used your plugin to create the class and then moved it, and then updated the namespace.

In my case, at least, I still have the default directories so the make works, and then then I have additional "non-standard" directories to organize the project.

[NiclasvanEyk]

@bfinlay you raise some very good points and I am happy to see that you enjoy the plugin :). I totally agree that the documentation needs to be improved, especially for the marketplace. The Jetbrains plugin template, on which this repo is based on, supports the extraction of a certain part of the readme as the description for the marketplace. I will update this section to also include parts from the features.md file, which is where the current feature documentation lives to nut clutter up the readme.

Your second suggestion also seems to be a possible approach that I haven't considered yet. It seems to go a bit against the Laravel ethos of convention over configuration though. However I also had this problem, as the default Laravel structure is not perfect for every use case. Personally I have two suggestions on how to tackle this:

1. Implement a tooltip for the disabled/grayed out items that maybe explains why they are disabled (maybe even linking to this or another issue to have a place for discussions). This would at least save some people from searching why they cannot use these options and seems to be pretty easy to implement.
2. I would then explore a setting that enables you to do something like you describe. I think it could be quite complex to "fix" the namespace, but I see that this would be useful. I do have some concerns for the support for remote php interpreters, where it might not be so easy to just move a file after its creation.