composer -n init can easily trap itself

[ktomk]

(I did some explorative testing)

given an empty directory, when executing

composer -n init --name "foo"

the world is fine. executing it again, does not init, but complains about some issue in the composer.json that at that state is:

{
    "name": "foo",
    "require": {}
}

so instead of applying init over it - as earlier - composer(1) complains about the future:

 [Composer\Json\JsonValidationException]
 "./composer.json" does not match the expected JSON schema:
  - name : Does not match the regex pattern ^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]?|-{0,2})[a-z0-9]+)*$

but it's too late, the initial composer(1) init should (could) have complained earlier before writing the $COMPOSER file.

Output of composer diagnose: same as above for composer init.

When I run this command:

composer -vvv init -name foo

I get the following output:

  [Composer\Json\JsonValidationException]
  "./composer.json" does not match the expected JSON schema:
   - name : Does not match the regex pattern ^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]?|-{0,2})[a-z0-9]+)*$


Exception trace:
 () at phar:///home/ktomk/bin/composer.phar/src/Composer/Console/Application.php:418
 Composer\Console\Application->getComposer() at phar:///home/ktomk/bin/composer.phar/src/Composer/Console/Application.php:527
 Composer\Console\Application->getPluginCommands() at phar:///home/ktomk/bin/composer.phar/src/Composer/Console/Application.php:187
 Composer\Console\Application->doRun() at phar:///home/ktomk/bin/composer.phar/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///home/ktomk/bin/composer.phar/src/Composer/Console/Application.php:122
 Composer\Console\Application->run() at phar:///home/ktomk/bin/composer.phar/bin/composer:63
 require() at /home/ktomk/bin/composer.phar:24

And I expected this to happen:

composer init. again.

or: with the first composer(1) init to exit non-zero and not creating ${COMPOSER:-composer.json}.

---

if its not more robust, composer tends to catch itself and into its own errors. so either fail at the initial composer init or allow to re-init in the good meaning of a reset.

it shifts into compser(1) self-update which should work regardless if the composer.json validates or not to at least offer an up/downgrade path.

---

Workaround:

1. drop world: COMPOSER=/dev/null composer self-update --rollback (the --rollback switch is obviously superfluous in this example and there might not be any version to rollback to)
2. remove $COMPOSER, always if it exists, before init: rm -f -- "${COMPOSER:-composer.json}" && composer -n init --require "php:*"
3. do not use composer(1) to initialize: rm -f -- "${COMPOSER:-composer.json}" && printf "{\n}\n" > "${COMPOSER:-composer.json}"

number 3 has the benefit that it does not make composer stumble over json schema validation for the next operation.

for a more general workaround, init a composer.json file in tmp and only if composer accepts it, move it into the non-temporal space.

by-catch: the output of composer(1) init tells the wrong path to composer.json if it is different.

[Seldaek]

Alright, fixes 4 different issues (see the above commits), I hope this tackles all things you mentioned.

[ktomk]

Wow, didn't expect this @Seldaek, but won't complain ;)

A tendency in mine grew over the days towards a fix like in a5efbbc - I might have looked to enable verification in memory perhaps so that the file would not be persisted on disk if considered invalid.

So thanks you've left at least something to tinker with!

And thanks a lot again!

[Seldaek]

Hehe, yes I figured in memory would be nicer but could not be bothered to extract it cleanly out of JsonFile.. for such an edge case situation I think the unlink is fine.