Closed lastzero closed 8 years ago
Those two arent supposed to be used for running your own composer install. Those are for installing third party blocks
for bldr.
But right now they uninstall existing project dependencies without asking. Are you sure, this is what you want?
Its not actually bldr code: https://github.com/bldr-io/bldr/blob/master/src/Application.php#L118
Its embedded composer
Maybe you want to rename the arguments to install-blocks
and update-blocks
then, as a quick fix? We're using Bldr as a task runner / automation tool. If bin/bldr build
works and executes a project build, any sane person would expect bin/bldr update
to execute a project update!? (Most devs don't read the docs, when they are in a hurry.)
I can't change that command. It's not my command to change.
And i have to disagree. A developer should know what executable they are executing.
I understand, but it worries me a bit. Bldr seems like a hack to me now. Bldr is not just a random executable, but a configurable task runner. Nothing you want to be surprised of. Think of Murphy’s Law.
@aequasi You can change the command names. The argument you pass to the constructor on those commands sets the prefix for the command name, which you're setting as empty (''
).
Maybe blocks-install
and blocks-update
would be a good compromise.
While all build profiles work without using "run", update still doesn't work as expected:
# bin/bldr update
[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "run" is not defined.
Might be due to
$nonContainerCommands = ['install', 'update', 'dumpautoload', 'help'];
in src/Application.php
?
Bldr comes with predefined
install
andupdate
commands that can not be overwritten in.bldr.yml.dist
. Those commands executecomposer install
/composer update
, but don't seem to findcomposer.json
:Basically, Bldr removes itself, which doesn't seem to be the intended behaviour. It probably looks for
composer.json
inbin
instead of the main directory?My
composer.json
looks like this (only the important parts):