fix: lint

admin/components.md

@@ -218,6 +218,7 @@ export default App;
 | dataProvider | object              | dataProvider | no       | hydra data provider to use   |
 
 \* `false` to explicitly disable, `true` to enable with default parameters or an object with the following properties:
+
 - `hub`: the URL to your Mercure hub
 - `jwt`: a subscriber JWT to access your Mercure hub
 - `topicUrl`: the topic URL of your resources
@@ -268,6 +269,7 @@ export default App;
 | mercure       | object|boolean | *     | no       | configuration to use Mercure |
 
 \* `false` to explicitly disable, `true` to enable with default parameters or an object with the following properties:
+
 - `hub`: the URL to your Mercure hub
 - `jwt`: a subscriber JWT to access your Mercure hub
 - `topicUrl`: the topic URL of your resources

admin/real-time-mercure.md

@@ -39,6 +39,7 @@ const dataProvider = baseHydraDataProvider({
 ```
 
 The `mercure` object can take the following properties:
+
 - `hub`: the URL to your Mercure hub (default value: null ; when null it will be discovered by using API responses)
 - `jwt`: a subscriber JWT to access your Mercure hub (default value: null)
 - `topicUrl`: the topic URL of your resources (default value: entrypoint)

core/filters.md

@@ -1281,6 +1281,7 @@ class Offer
 ```
 
 When creating a custom filter you can specify multiple properties of a resource using the usual filter syntax:
+
 ```php
 <?php
 // api/src/Entity/Offer.php
@@ -1300,7 +1301,9 @@ class Offer
     public int $cost;
 }
 ```
+
 These properties can then be accessed in the custom filter like this:
+
 ```php
 //App/Filter/CustomAndFilter.php
 protected function filterProperty(string $property, $value, QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator, string $resourceClass, Operation $operation = null, array $context = []) {  

core/migrate-from-fosrestbundle.md

@@ -37,7 +37,6 @@ You can use them as you migrate from FOSRestBundle, but you should consider [swi
 
 See [General Design Considerations](design.md).
 
-
 ### Routing system (with native documentation support)
 
 **In FOSRestBundle**

core/operations.md

@@ -115,7 +115,6 @@ App\Entity\Book:
 
 </code-selector>
 
-
 The previous example can also be written with an explicit method definition:
 
 <code-selector>

core/subresources.md

@@ -97,22 +97,23 @@ use ApiPlatform\Metadata\ApiResource;
 use ApiPlatform\Metadata\Link;
 use Doctrine\ORM\Mapping as ORM;
 
-#[ORM\Entity]
-#[ApiResource]
-#[ApiResource(
-    uriTemplate: '/questions/{id}/answer', 
+# [ORM\Entity]
+# [ApiResource]
+# [ApiResource(
+    uriTemplate: '/questions/{id}/answer',
     uriVariables: [
         'id' => new Link(
             fromClass: Question::class,
             fromProperty: 'answer'
         )
-    ], 
+    ],
     operations: [new Get()]
 )]
 class Answer
 {
     // ...
 }
+
 ```
 
 </code-selector>

core/upgrade-guide.md

@@ -168,6 +168,7 @@ When updating we advise to first resolve the deprecations then to set this
 flag to `false` to use the new metadata system.
 
 When `metadata_backward_compatibility_layer` is set to `false`:
+
 - there's still a bridge with the legacy `ApiPlatform\Core\Annotation\ApiResource` and old metadata will still work
 - the deprecated Symfony services will have their interface changed (for example `ApiPlatform\Core\Api\IriConverterInterface`
 will be `ApiPlatform\Api\IriConverterInterface`) and it may break your dependency injection.

schema-generator/configuration.md

@@ -448,6 +448,7 @@ doctrine:
 ```
 
 The default mapping file format is XML, but you can change it to YAML with the following option:
+
 ```yaml
 doctrine:
     resolveTargetEntityConfigPath: path/to/doctrine.yaml