Open Diwoka opened 5 years ago
How would you configure host
@Diwoka?
I'd rather have test
(remove tu
and tf
), or could be test:all
, test:unit
and test:acceptance
in the worst case. I personally would keep just the one, and add it to QA.
Can we change php
in code-style
or just cs
? At some point, we will (or we already do) have javascript, typescript, css, sass, less and whatnot, and cs will include prettier as well as phpcs or php-cs-fixer
install Install and start the project
uninstall stop the project and uninstall project
vendor run composer install
db make full db
db.migrations rub db migrations
db.fixtures run db fixtures
test Run all tests stack
test.unit Run unit tests
test.acceptance Run functional tests
cs Run all code Style analysis
cs.php Run all code Style PHP analysis
cs.prettier Run all code Style JS and Style analysis
logs Show logs
I would rather rename clean
to destroy
as it is a much strong word for this action, as I understand it's an equivalent of docker-compose down
Also for the command db
, I would change the name to db.reload
while keeping your first help phrase "Reset the database and load fixtures" rather than "make full db" which seems not very clear
Also, I would keep in the setup part :
start Start the project
stop Stop the project
they are clear and simple :)
I'd prefer to have less make commands. Many of your make commands are just Symfony commands that can be executed with bin/console ...
.
There is already make bash
to enter in the php container, and you can do bin/console
inside. So no need to put all Symfony commands in make, except maybe these we use to install project because it's important to have a quick and simple startup.
I think there should be make commands only to help in install/start/update/tests commands.
I am personally in favour of removing make bash
, as developers should never get in the container to do stuff (we all know it's opening Pandora's box, they'll do whatever actions in there...) and have a few interesting commands directly opened (some of them might even be run
rather than exec, allowing us to remove containers once used.
We are supposed to develop with docker, not on docker. Docker provides a php environement, we can then run bin/console, composer require, phpunit... when going inside
Also docker should be optional, not required to run a project, that's why in any way we should use Symfony commands
I couldn't disagree more 😄
Even though you are using docker, the base idea is to have a parity with your production environment as much as possible. This means that for instance, there should not be composer in the php-fpm container, as this won't be the target setup. Only exceptions to the above: xdebug (configurable, disabled by default) and opcache.
for me Makefile is also to help junior developper to do things when he dont have the knowledge and if he want improve itself go in makefile and see command. (sorry if my english is not so good)
Ok so in any case we should be able to use Symfony commands easily, instead of creating a make shortcut for all sf commands
true but you need docker to execute this command
Description
Discussion about what tools or commands should be included in the
Makefile
Scenarios
$> make
Output:
Tools
Database
Tests
Quality assurance