Allow 6.x version of justinrainbow/json-schema

As it's a dev dependency we could consider bumping the lockfile version to 6.x in 11.2 (while still allowing downgrades to 5.x), similar to us upgrading from PHPStan 1 to 2.

I believe this is also blocking composer to be updated past 2.8.7

What would be the issue with allowing either on earlier Drupal versions? I'm trying to use 6.x in a module now and this would mean we'd basically have to wait until 11.1 is EOL to ship these features safely, right? I imagine Experience Builder would have the same issue...

Because justinrainbow/json-schema is currently added as a core-dev (11.6) dependency and pinned to the 5.x version, it causes updating composer from 2.8.6 to 2.8.8 to fail.

Composer -v wrongly reports composer version 2.8.8 (after composer self-update), using the "composer update composer/composer" command gives the message you're already using the latest version.

Running the command "composer outdated "still reports 2.8.6.
Version 2.8.6 is of course still mentioned in composer.json en -lock files.

I hope the next drupal/core-dev update allows to run justinrainbow/json-schema ^6.4 to resolve the issue.

Bumping to critical as this is preventing Composer from being updated.

This needs a rebase.

Rebased.

Seems it has an undocumented change:

https://github.com/jsonrainbow/json-schema/issues/822

BaseContraint:

public function addError(?JsonPointer $path, $message, $constraint = '', ?array $more = null)

to

public function addError(ConstraintError $constraint, ?JsonPointer $path = null, array $more = []): void

Went through the changes, these look good.

For a small moment i thought, why wouldnt we not just update the baseline? But that might be a hassle when switching between 5 and 6.

And in regards to contrib, it is pretty easy to support 5 and 6 for now, change is not that bad as you can see in this mr.

Anyways, all good, cool ^^

Don't think we need a change record, but we should add a line for this to the 11.2.0 release notes.

rebased after 📌 Update Composer dependencies for 11.2.0 Active

Seems we have an issue left here after rebase:

------ ------------------------------------------------------------------------- 
  Line   core/tests/Drupal/Tests/Core/Theme/Component/ComponentValidatorTest.php  
 ------ ------------------------------------------------------------------------- 
  351    Call to an undefined static method                                       
         JsonSchema\ConstraintError::FORMAT_URL().                                
         🪪  staticMethod.notFound                                                
  355    Method JsonSchema\Constraints\BaseConstraint::addError() invoked with    
         4 parameters, 1-3 required.                                              
         🪪  arguments.count                                                      
 ------ ------------------------------------------------------------------------- 

Never mind me, all good, that is the branch which uses 6.x to test. Adding ignore so tests run, but nothing to worry about. Keeping RTBC

All green and happy after the rebase.

+1 🤯 until I got to https://github.com/jsonrainbow/json-schema/blob/b209eb8f203fd36284b2c747....

the only question when we can drop 5.x of it

@andypost Probably not until Drupal 12.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Updated lock file hash.

Given #17 we should add a release note snippet for 11.2.0 - probably pointing to https://github.com/jsonrainbow/json-schema/blob/master/UPGRADE-6.0.md to be helpful.

Can be set to RTBC when done and I will prioritise.

Added a note.

Committed and pushed 656836718c4 to 11.x and 4eb755b42fc to 11.2.x. Thanks!

Can this be applied to 10.4.x?

Re #36 as a custom patch for sure

andypost → closed merge request !11685

andypost → closed merge request !12020

Discussed with @catch, as this is a development dependency only and the compatibility changes are minor we think this could be backported to 10.5.x.

backported

No weird changes, actual green tests in main MR and also the test mr with updates package. Nice :)

Committed f6a3149 and pushed to 10.5.x. Thanks!