Extend Laravel's scaffolding commands to generate in a certain module about l5modular HOT 25 CLOSED

I'll just use my Ubuntu workstation when running the test for now. I'm just starting on writing the bunch of tests for generator commands. I couldn't find the time to do it in past couple of days due to my workloads. The best I could have it is by next week hopefully.

from l5modular.

Hi @juliomotol

I like the Idea and many thanks for the contribution so far.
The only thing I would miss here is a list command. But it is not crucial. I would otherwise implement it myself someday.
Besides that I'm curious about the Request and Resource classes. In which cases do you need custom Requests / Resources in a module.

The automated tests is something I still have on my ToDo list for this project.
So far there hasn't been much to test, so in my opinion it was negligible. But since this project is growing now, I'll setup Jenkins and write some tests as soon as possible so you can take them as reference.

from l5modular.

BTW. For the sake of simplicity I'm using snippets for new classes. I have no Idea about other editors, but in nvim you can write custom snippets which automatically expands to classes with correct namespace, etc. However, I see the benefints of the CLI commands and would be happy about this PR.

from l5modular.

Hi, Thanks for the timely response. As for your questions:

• By list command do you mean php artisan list? If so, since we are overriding the existing commands they will still be there and when we php artisan help make:controller, the --module option will also show up.
• Request - there are cases that a FormRequest class is only used in a certain module and our team find it more organized to put the request in there designated module.
• Resource - a resource directly relates to a model and since we have a model directory inside a module, I thought we'd place them there too.

The only problem that I see here is that if there are other packages that overrides Laravel's scaffolding commands depending on the order how the service provider is registered, one or the other extended command may not be implemented.

For writing tests, I've tried using orchestral/testbench, though I'm still pretty new to writing tests.

from l5modular.

By "list" I mean php artisan list:modules. I think it's more convenient to get the module names through the cli while you're working in it anyway.
The Request / Resource points are comprehensible.

I like the regular "make" syntax with flags for the modules, but if there is no way around the drawback that other packages will possibly not work, then that is not a suitable solution.
One alternative would be something like php artisan make:module-controller [controller name] [module name] but it's clearly not that nice

FYI
You can use the regular make command in a way that it generates directly into a module with the correct namespace. Like php artisan make:model "Modules\FooBar\Models\[model name]"

from l5modular.

I think I can squezee php artisan list:modules in. Seems pretty simple to do.

What about php artisan make:module:controller SomeController --module=SomeModule. They can also do php artisan make:module:controller SomeController then they'll be asked what module they want to generate the class.

Yes I'm aware that I can snake my way with php artisan make:model "Modules\FooBar\Models\[model name]" but I know there could be a better way than this 😄

Let me know your thoughts so I can get into it right away.

from l5modular.

Both variants sounds good to me.

from l5modular.

Quick update on this.

from l5modular.

Nice. Looks promising :)

from l5modular.

Hi @juliomotol,

after a closer look (and with your additions in mind) I decided to rewrite large parts of this package. It can be done much better than it currently is and I'm making pretty good progress.
Since there will be (sort of) breaking changes, I will roll out a major release. But no worries, the package will be configurable to work with v1 modules.

To give you a little glimpse in the changes / new features..

1. The module structure will not (necessarily) be determined by the package. Developers will have the possibility to configure the default structure and/or explicitly different structures for every module.
2. All generators will be configurable as well. I.e. it will be possible to decide which components of a module shall be generated by the make command.
3. The generated migration (or module migrations in general) will be in the module itself
4. I'll add two more generators: seeds, factories
5. The package will be tested (unit/acceptance) and I'll setup Travis CI
   ...

I think I'm 70% through the mentioned stuff.

from l5modular.

I've finished some make command acceptance tests.
Unfortunately I could not get the http request tests running correctly. But I think there will be no need for them as soon as I get the unit tests for the service provider done.

from l5modular.

I'm done. Feel free to create a PR into the release/2.0.0 branch. :)

from l5modular.

Hi! This is great! I'll get in to it as soon as I can 😄

from l5modular.

I'm still fairly new to using test scripts, I can't seem to fix this:

from l5modular.

The last one fails because of the directory separators. I didn't thought about windows having backslashes as such.
The other one needs to be debugged. But I think the cause is the OS too.
Unfortunately I have no possibility to run the tests on a Windows.
Could you run the tests in a Linux VM or Vagrant or Docker?

If you're familiar with Docker, I could send you a docker-compose.yml which I used to run the tests with code coverage analysis. The output will look like in the Travis build and you will get a build directory with an interactive index.html on top, which is pretty handy.

from l5modular.

I'm still setting up and starting to migrate to Ubuntu. I'll keep you posted on that, but for the mean time I'll work with what I have.

I've heard of Docker but our team is yet to implement it. I could look into it so that I could apply what I learn here for our team.

from l5modular.

Here is the docker-compose.yml which I used to run the tests with code coverage (my local php does not have the tools).
Docker and Docker Compose are obviously required.

version: "3"
services:

  # docker-compose run php vendor/bin/phpunit
  # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  php:
    image: clover/php:7.3
    working_dir: /var/www
    volumes: &appvolumes
      - ./L5Modular:/var/www:delegated

  # docker-compose run --rm composer install
  # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  composer:
    restart: 'no'
    working_dir: /var/www
    image: composer
    command: install
    volumes: *appvolumes

Your code has to be in a folder named src on the same level as the docker-compose.yml.
The following steps should then get you the tests executed in a linux environment:

1. docker-compose up starts the containers
2. docker-compose run --rm composer install installs all dependencies
3. docker-compose run php vendor/bin/phpunit runs the tests

However, I will check the code for possible pitfalls in relation to Windows. It has to be possible to run the package on any OS.

from l5modular.

Hey @juliomotol, how is it going?
According to the blog post the directory separator should be accepted regardless of its direction.

from l5modular.

Hi, I got this working on my Ubuntu workstation. but the Mockery_0_ArrayAccess error still persists

Will now start writing tests for the extended commands. Also, I installed Docker on my Windows workstation but I'll still need to read up on how to use Docker. Theres an error saying "composer.json not found". I have my project tree like below:

L5Modular
├── src/
    ├── ...
├── tests/
    ├── ...
├── docker-compose.yml
├── ...

from l5modular.

Hm.. This is strange.
Would you please tell me the output of composer show and php -v?
Also it would help to see what error you get if you comment out the should receive singleton statement and run the test.

Docker:
I think my example was a little confusing.
Your docker-compose.yml sits in the wrong directory. It has to be one level up.
Also if the directory, which contains the contents of this repo, is named "L5Modular", the docker-compose.yml needs to be slightly changed. See updated answer.

To make it a little more understandable;
The php container has a mounted volume:

volumes: &appvolumes
  - ./L5Modular:/var/www:delegated

The part before the colon points to a folder on your machine, the part after the colon points into the container. So everything from the directory L5Modular will be available inside the php container at /var/www/. So since there is no composer.json inside the src directory, you're getting the error.

My projects are normally structured like this:

SomeProject
├── docker-compose.yml
└── src
    ├── index.php
    └── ...

In most cases there is no other src folder in the one containing the actual project.

from l5modular.

Hi, I understand the problem with the it_registers_the_package test. I made a minor change on how commands a registered. I removed the $this->app->singleton() and used $this->commands() to load the commands. The dependencies are automatically injected this makes the code much concise.

As for the it_bootes_module test, I'm back on my Windows workstation and tried changing the directory separator, the problem still persists.

Then comes Docker. I'm biting more than I could chew. I placed it a level above as you've said and changed the docker-compose.yml as mentioned.

from l5modular.

Hi, I understand the problem with the it_registers_the_package test. I made a minor change on how commands a registered. I removed the $this->app->singleton() and used $this->commands() to load the commands. The dependencies are automatically injected this makes the code much concise.

That makes sense.

As for the it_bootes_module test, I'm back on my Windows workstation and tried changing the directory separator, the problem still persists.

I thought so. I will try to narrow down the cause of the problem in your repo in a few hours.

Then comes Docker. I'm biting more than I could chew. I placed it a level above as you've said and changed the docker-compose.yml as mentioned.

Strange. If have the time and the will to tackle this, I could help you as far as I can. But I think the issue tracker isn't the right place. Slack or some other chat would be better.

from l5modular.

All tests run green on OSX and Arch Linux when I comment the should receive exists back in.

from l5modular.

Hi @Artem-Schander,

Im almost done with the test. Do you still plan to enable/disable modules? I can't seem to find that option in the config file. I actually added that to the module:list command.

Also there could be a problem with the /Resources directory.

Let me know so I could do the adjustments. Almost close to making a PR 😄

from l5modular.

Depending on the filesystem it could be a problem indeed. I would say, lets put Controllers, Requests and Resources into a Http folder by default.

'structure' => [
    'controllers' => 'Http/Controllers',
    'events' => 'Events',
    'factories' => 'database/factories',
    'jobs' => 'Jobs',
    'listeners' => 'Listeners',
    'mails' => 'Mail',
    'migrations' => 'database/migrations',
    'models' => 'Models',
    'notifications' => 'Notifications',
    'observers' => 'Observers',
    'requests' => 'Http/Requests',
    'resources' => 'Http/Resources',
    'routes' => 'routes',
    'seeds' => 'database/seeds',
    'translations' => 'resources/lang',
    'views' => 'resources/views',
    'helpers' => '',
],

BTW. I would not sort them alphabetically. Its pure chaos ^^

You can still disable modules, but the setting is now in the specific config part.

from l5modular.