Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preserveMiro option not working properly with de-duplicated references #152

Closed
dlouzan opened this issue Feb 18, 2019 · 2 comments
Closed
Assignees
Labels

Comments

@dlouzan
Copy link

dlouzan commented Feb 18, 2019

Checklist

  • [ X] Resolver issue

Detailed Description

I arrived here because of wework/speccy#268.

In my case, this happens only with internal references setup by the resolver to avoid duplicating the resolved content of other references.

I assumed that speccy was doing something wrong while setting up the library, but it doesn't seem so, in fact it just plainly doesn't pass any value to oas-resolver, so the default must apply (false). Sadly, I still end up with x-miro values in the final resolved output of our multi-file OpenAPI 3 spec.

To double check, I forced the value in my local checkout of speccy and did some manual logs in the imported node_modules, and made sure that the options.preserveMiro option was being set as false in oas-resolver.

A sample that shows this behaviour:

openapi.yaml:

openapi: 3.0.0
info:
  version: 1.0.0
  title: API
tags:
  - name: test
    description: a test tag
paths:
  /foo:
    post:
      operationId: postFoo
      summary: Super post op
      tags:
        - test
      responses:
        '201':
          $ref: 'responses.yaml#/components/responses/Post201'
  /bar:
    post:
      operationId: postBar
      summary: Super post op
      tags:
        - test
      responses:
        '201':
          $ref: 'responses.yaml#/components/responses/Post201'

responses.yaml:

openapi: 3.0.0
info:
  version: '1.0'
  title: Common Response schemas
  description: Response definitions commonly used in API-docs in a separate reference file
paths: {}
components:
  responses:
    Post201:
      description: Success post
      content:
        application/json:
          schema:
            $ref: 'schemas.yaml#/components/schemas/xyz'

schemas.yaml:

openapi: 3.0.0
info:
  version: '1.0'
  title: Common Message/JSON schemas
  description: Message schemas / JSON datatypes commonly used in API-docs in a separate reference file
paths: {}
components:
  schemas:
    xyz:
      title: XYZ
      description: this is xyz
      type: object
      properties:
        id:
          description: the local identifier (not necessarily globally unique) 
          type: string

Resolved output (notice the resolved content of the /bar path):

openapi: 3.0.0
info:
  version: 1.0.0
  title: API
tags:
  - name: test
    description: a test tag
paths:
  /foo:
    post:
      operationId: postFoo
      summary: Super post op
      tags:
        - test
      responses:
        '201':
          description: Success post
          content:
            application/json:
              schema:
                title: XYZ
                description: this is xyz
                type: object
                properties:
                  id:
                    description: the local identifier (not necessarily globally unique)
                    type: string
  /bar:
    post:
      operationId: postBar
      summary: Super post op
      tags:
        - test
      responses:
        '201':
          $ref: '#/paths/~1foo/post/responses/201'
          x-miro: 'responses.yaml#/components/responses/Post201'
@MikeRalphson
Copy link
Contributor

Many thanks for taking the time to put this together. Will add as a test-case and investigate.

@MikeRalphson
Copy link
Contributor

Successfully published:

  • oas-resolver@2.2.2
  • oas-validator@3.2.2
  • swagger2openapi@5.2.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants