Problem/Motivation
The fixture model the scanner is asserted against is built from what core provides, because the pipeline builds this project without the modules it only suggests. Paragraph types are therefore not in it at all: not their fields, not how deeply they nest inside one another, not what happens when two of them nest in a loop.
That is a gap rather than a scope decision. The paragraphs module is optional to this project in the sense that nothing breaks without it, but a site that has a use for a decoupled API of this shape almost always has it, and the paragraph layer is where the deepest and least predictable part of a response comes from. The one thing the map says about paragraphs specifically - how many levels of them a site nests - is asserted today only against a map built by hand in a unit test. It has never been asserted against real paragraph types.
Proposed resolution
- A second fixture module, depending on the paragraphs module, holding paragraph types with fields of their own: one nesting inside another two levels deep, and a pair that nest in a loop.
- Kernel tests asserting the bundles, the fields and the nesting depth against those types, the same way the core fixture is asserted key by key.
- The test skips where the module is absent, so the pipeline stays green on a build that has no contributed modules, and the coverage is real everywhere the module is installed.
- The first fixture keeps no dependency on any of it: the core-only model has to go on installing on a build without paragraphs, which is what makes it the one the pipeline runs.
Remaining tasks
Everything.
Issue fork myrest-3620033
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
sergeydruua commentedComment #6
sergeydruua commented