Refuses to normalize projects without name/description

[guilliamxavier]

I'm starting a private project that won't be published so doesn't have a name (nor a description); here's its composer.json (minimal for now):

{
    "type": "project",
    "license": "proprietary",
    "require": {
        "php": "^7.2"
    }
}

It is valid for non-public use:

$ composer validate --no-check-publish
./composer.json is valid for simple usage with composer but has
strict errors that make it unable to be published as a package:
See https://getcomposer.org/doc/04-schema.md for details on the schema
name : The property name is required
description : The property description is required
$ echo $?
0

but impossible to normalize as-is:

$ composer normalize
Original JSON is not valid according to schema "file:///home/gx/.composer/vendor/ergebnis/composer-normalize/src/../resource/schema.json".
./composer.json is valid for simple usage with composer but has
strict errors that make it unable to be published as a package:
See https://getcomposer.org/doc/04-schema.md for details on the schema
$ echo $?
0

(note: the message doesn't say what the strict errors are, and the command doesn't return an error code despite not being successful).

To work around, I have to run the sequence:

1. composer config name a/a (dummy but valid name)
2. composer config description ""
3. composer update --lock (if I have a composer.lock)
4. composer normalize
5. composer config --unset name
6. composer config --unset description
7. composer update --lock (if I have a composer.lock)

Would it be feasible to mimic --no-check-publish (possibly opt-in)?

Maybe related to #297

[guilliamxavier]

Also I have a question (not sure deserves opening a new issue): Does this package really require being a plugin (and thus, being installed as project dependency and run as composer normalize)? Would it be possible to provide a composer-normalize bin (and/or a PHAR), like e.g. https://github.com/composer-unused/composer-unused (which can also be installed globally and then run from all projects)?

PS: Thanks!

[kubawerlos]

being installed as project dependency

this is not needed, you can install it globally and run composer normalize.

I've just checked and I'm surprised it is not the default/recommended way in README.

[guilliamxavier]

Duh, how did I miss the Phar section in the README 😫
And you say you can also do a composer global require ergebnis/composer-normalize and then run composer normalize from any project?
Then I guess a bin/composer-normalize is not needed after all 😅

(Sorry for the digression from the main issue)

[guilliamxavier]

Update on the issue:

Compare with the first commands:

$ composer validate --no-check-publish --strict
./composer.json is valid for simple usage with composer but has
strict errors that make it unable to be published as a package:
See https://getcomposer.org/doc/04-schema.md for details on the schema
$ echo $?
0

=> with the --strict option, the lines

name : The property name is required
description : The property description is required

are no longer present (because otherwise it would return 1, like for a missing/invalid license). That's arguably a bug in Composer (I will open a ticket there).

And indeed, if I remove the --strict option in NormalizeCommand::validateComposerFile(), then those lines appear in the output of composer normalize (and still returns 0).

But the normalization is still not successful (OriginalInvalidAccordingToSchemaException thrown from SchemaNormalizer::normalize()).

From #175 (comment):

The problem is the following:

• in Localheinz\Json\Normalizer\Validator\SchemaValidator::isValid() we validate according to the original JSON schema

• in Composer\Json\JsonFile::validateSchema a lax validation (no fields are required, additional properties are ok) is performed

I should probably perform a lax validation as well.

(which was closed for inactivity, not fixed).

Indeed, does the normalization really depend on the JSON being strictly valid according to the schema?

[localheinz]

@guilliamxavier

Apologies for the delay!

Unfortunately I will not be able to sort this out this week or next week. Is that going to work for you?

[guilliamxavier]

@localheinz: No worry, no urgency at all on my side, the workaround sequence (at the end of my first post) can actually be easily turned into a shell script 😉 (Moreover I would not want to be the cause of a side-effect break/regression in the json-normalizer package...)

[ergebnis-bot]

Since this issue has not had any activity within the last sixty days, I have marked it as stale.

I will close it if no further activity occurs within the next five days.

[localheinz]

@guilliamxavier

Can you take a look at 2.5.0 and let me know if this works for you?

Again, apologies for the delay!

[guilliamxavier]

I have downloaded the latest PHAR and I confirm that the issue is resolved.

Thank you!

[localheinz]

Thank you, @guilliamxavier!