format

docs/comparisons.md

@@ -2,28 +2,29 @@
 
 zod-openapi was created while trying to add a feature to support auto registering schemas to ### [@asteasolutions/zod-to-openapi](https://github.com/asteasolutions/zod-to-openapi). This proved to be extra challenging given the overall structure of the library so I decided re-write the whole thing. I was a big contributor to this library and love everything it's done, however I could not go past a few issues.
 
-1. __**Inaccurate**__ schema generation. This is because the library is written without considering that Zod Types can produce different schemas depending on if they are an `input` or `output` type. This means that when you use a `ZodTransform`, `ZodPipeline` or `ZodDefault` it may generate incorrect documentation.
+1.  \***\*Inaccurate\*\*** schema generation. This is because the library is written without considering that Zod Types can produce different schemas depending on if they are an `input` or `output` type. This means that when you use a `ZodTransform`, `ZodPipeline` or `ZodDefault` it may generate incorrect documentation.
 
-2. No input/output validation on components. Registered schema for inputs and outputs should __NOT__ be used if they contain a ZodEffect such as `ZodTransform`, `ZodPipeline` or `ZodDefault` in both a request and response schema. This is because they will be inaccurate for reasons stated above.
+2.  No input/output validation on components. Registered schema for inputs and outputs should **NOT** be used if they contain a ZodEffect such as `ZodTransform`, `ZodPipeline` or `ZodDefault` in both a request and response schema. This is because they will be inaccurate for reasons stated above.
 
-3. No transform support or safety. You can use a `type` to override the transform type but what happens when that transform logic changes? We solve this by introducing `effectType`.
+3.  No transform support or safety. You can use a `type` to override the transform type but what happens when that transform logic changes? We solve this by introducing `effectType`.
 
-4. No lazy/recursive schema support.
+4.  No lazy/recursive schema support.
 
-5. Wider and richer generation of OpenAPI types for Zod Types.
+5.  Wider and richer generation of OpenAPI types for Zod Types.
 
-6. The underlying structure of the library consists of tightly coupled classes which require you to create an awkward Registry class to create references. This would mean you would need to ship a registry class instance along with your types which makes sharing types difficult.
+6.  The underlying structure of the library consists of tightly coupled classes which require you to create an awkward Registry class to create references. This would mean you would need to ship a registry class instance along with your types which makes sharing types difficult.
 
-7. Previosuly, zod-to-openapi did not support auto-registering schema, however, more recently they added a solution which is less clear.
+7.  Previosuly, zod-to-openapi did not support auto-registering schema, however, more recently they added a solution which is less clear.
+
+        ```ts
+        z.string().openapi('foo')
+        z.string().openapi('foo', { description: 'foo' });
+        // vs
+
+        z.string().openapi({ ref: 'foo' });
+        z.string().openapi({ description: 'foo', ref: 'foo' });
+        ```
 
-    ```ts
-    z.string().openapi('foo')
-    z.string().openapi('foo', { description: 'foo' });
-    // vs
-
-    z.string().openapi({ ref: 'foo' });
-    z.string().openapi({ description: 'foo', ref: 'foo' });
-    ```
 Did I really rewrite an entire library just for this? Absolutely. I believe that creating documentation and types should be as simple and as frictionless as possible.
 
 #### Migration