Swagger-editor: Missing warnings and errors

[rrberry]

I often use the online editor for validation against the Swagger spec, but I find that the new editor is too forgiving, and fails to show warnings and errors that the old editor flagged.

For example:

• Descriptions specified as peers of $ref; these generate warnings in the old error, but not in the new editor

• An enum that specifies a default value that is not part of the enum; this causes an error in the old error, but not in the new editor

Is this by design? It makes the editor less useful as a validation tool.

[webron]

We've tried to include all old validations, and new ones, but probably missed a few. The best approach would be to open tickets on those, and of course, if possible, submit PRs.

Properties alongside $ref are still provided as warnings. The difference is that we do not present the warnings in the view pane, to less clutter the UI. Warnings are still shown as a yellow triangle in the gutter left to the line in question.

As for the enum, that's an oversight. I don't know if it's right to consider it an error rather than a warning, but that's a different question.

[UncasRipley]

I noticed the following issue yesterday,

In my spec file I wrongly wrongly defined a parameter as "in: query" instead of "in: path". Swagger Editor v2.0 did not give a syntax error. But, older editor DID give the correct error.

[AlexandreDahman]

Version: editor.swagger.io, 3.1.0

According to the 3.0 Specification, for a Parameter where in is "path", the name field MUST correspond to the associated path segment from the path field in the Paths Object.

However, adding a parameter with a different name do not trigger any validation errors/warnings in the editor (ex., 'Parameter path xxx was defined but never used' or 'Declared path parameter xxx needs to be defined as a path parameter at either the path or operation level).

[AlexHolly]

only line 12 and 27 matter ( '/pet': and "in: path")
https://editor.swagger.io/

Path is checked properly in one way but not both.
This example is correct (shows an error).

openapi: 3.0.6
info:
  description: This is a sample server Petstore server.
  version: 1.0.0
  title: Swagger Petstore
  contact:
    email: [email protected]
servers:
  - url: 'https://petstore.swagger.io/v2'
  - url: 'http://petstore.swagger.io/v2'
paths:
  '/pet/{petId}':
     get:
      summary: Get a Pet.
      parameters:
        - $ref: '#/components/parameters/Pet'
      responses:
        '200':
          description: OK
components:
  parameters:
    Pet:
      name: petId
      schema:
        type: integer
      description: The identifier of the pet.
      in: query
      required: true

This is missing an error

openapi: 3.0.6
info:
  description: This is a sample server Petstore server.
  version: 1.0.0
  title: Swagger Petstore
  contact:
    email: [email protected]
servers:
  - url: 'https://petstore.swagger.io/v2'
  - url: 'http://petstore.swagger.io/v2'
paths:
  '/pet':
     get:
      summary: Get a Pet.
      parameters:
        - $ref: '#/components/parameters/Pet'
      responses:
        '200':
          description: OK
components:
  parameters:
    Pet:
      name: petId
      schema:
        type: integer
      description: The identifier of the pet.
      in: path
      required: true