#3031367: Generate JSON schema for content entity types introduces core generation of content entity schema in JSON Schema format. This means the bulk of the heavy lifting in this module is unnecessary. However, we must still map the JSON Schema to entities exposed over JSON:API and provide routes, hypermedia links, etc.

This is a meta issue for migrating the module to do just this, while shedding much of the now-unnecessary schema generation logic.

In addition, I'd like to consider making this module a library for creating top-level JSON:API document schemas, and share that logic with openapi_jsonapi module. That would mean we have a single place to maintain that shared code. The schema-specific routes could be enabled through a submodule.

Comments

bradjones1 created an issue. See original summary.

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
Related issues: +#3431487: Add support for Drupal 11

This is a meta issue for migrating the module to do just this, while shedding much of the now-unnecessary schema generation logic.

@bradjones1 Can we rename this issue so that it is more specifically about this refactor, instead of generally about "Version 2.0"?

I think we will need to put out a 2.0.0 release to support Drupal 11 first, before tackling larger refactors.

See: #3431487: Add support for Drupal 11

m.stenta’s picture

m.stenta
he/him
Primary language English
commented

Nevermind! #3431487: Add support for Drupal 11 will not require a breaking change after all. Disregard my last comment. :-)

m.stenta’s picture

m.stenta
he/him
Primary language English
commented

Once we have support for Drupal 11 (see: #3431487: Add support for Drupal 11), we'll be able to run PHPStan tests via GitLab CI. I've already started working on fixing the existing issues. There aren't many, but some of them should be considered breaking changes. Specifically, replacing \Drupal:: calls with dependency injection requires changing the constructor arguments of DataDefinitionNormalizer, which would break any downstream classes that extend it. I would like to suggest we do that in 2.x and document it in the release notes as a breaking change. I may add an exception for that particular PHPStan rule so we can make everything else pass in the meantime.

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
Related issues: +#3524246: Fix PHPStan errors
m.stenta’s picture

m.stenta
he/him
Primary language English
commented

Specifically, replacing \Drupal:: calls with dependency injection requires changing the constructor arguments of DataDefinitionNormalizer, which would break any downstream classes that extend it. I would like to suggest we do that in 2.x and document it in the release notes as a breaking change. I may add an exception for that particular PHPStan rule so we can make everything else pass in the meantime.

Update: I've added a phpstan-baseline.neon file in #3524246: Fix PHPStan errors that ignores the \Drupal calls in 8.x-1.x, so all PHPStan tests pass moving forward and we can avoid introducing any new errors. I opened a follow-up issue that removes phpstan-baseline.neon and replaces the \Drupal calls with dependency injection, which can be reviewed and considered for merging into 2.x as a breaking change: #3524925: \Drupal calls should be avoided in classes, use dependency injection instead.