Azure / APICenter-Analyzer

Analyze your API Specs with Azure API Center (Preview)
MIT License
22 stars 23 forks source link

Using functions in the ruleset #8

Open UniperMaster opened 7 months ago

UniperMaster commented 7 months ago

Do you have an example of using function in the workset

I tried with the following ruleset and function but it fails to run

 # Source: https://docs.stoplight.io/docs/spectral/4dec24461f3af-open-api-rules
extends:
  - spectral:oas
functionsDir: "./functions"
functions:
  - consistent-response-body
rules:
  info-contact: off
  no-$ref-siblings: off
  oas2-api-host: off
  oas2-api-schemes: off
  openapi-tags: off
  operation-description: off
  operation-tags: off
  operation-tag-defined: off

  # Note: The Spectral VSCode extension will not display "hint" messages, so
  # use "info" rather than "hint".
  # just a note here

  az-additional-properties-and-properties:
    description: Don't specify additionalProperties as a sibling of properties.
    severity: warn
    formats: ["oas2", "oas3"]
    given: $..[?(@object() && @.type === 'object' && @.properties)]
    then:
      field: additionalProperties
      function: falsy

  az-consistent-response-body:
    description: Ensure the get, put, and patch response body schemas are consistent.
    message: "{{error}}"
    severity: warn
    formats: ["oas2"]
    given: $.paths.*
    then:
      function: consistent-response-body

and function

// If put or patch is a create (returns 201), then verify that put, get, and patch response body
// schemas are consistent.

// path Item should be a [path item object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#pathItemObject).
// This function assumes it is running on a resolved doc.
module.exports = (pathItem, _opts, paths) => {
  if (pathItem === null || typeof pathItem !== 'object') {
    return [];
  }
  const path = paths.path || paths.target || [];

  const errors = [];

  // resource schema is create operation response schema
  const createResponseSchema = ((op) => op?.responses?.['201']?.schema);
  const resourceSchema = createResponseSchema(pathItem.put) || createResponseSchema(pathItem.patch);
  if (resourceSchema) {
    ['put', 'get', 'patch'].forEach((method) => {
      const responseSchema = pathItem[method]?.responses?.['200']?.schema;
      if (responseSchema && responseSchema !== resourceSchema) {
        errors.push({
          message: 'Response body schema does not match create response body schema.',
          path: [...path, method, 'responses', '200', 'schema'],
        });
      }
    });
  }

  return errors;
};

This is based upon the azure ruleset azure-api-style-guide

Ive also attached the azure fucntions logs query_data.csv log

juliajuju93 commented 7 months ago

@UniperMaster : Thank you so much for reaching out. Functions will work with the ruleset.

You are currently using the SimpleJS syntax and in order for our linter to work, it needs ES syntax. Our current recommendation is for you to transition from SimpleJS to ES syntax.

Transitioning from SimpleJS syntax (which is similar to CommonJS) to ES Modules (ESM) involves a few steps. Let’s explore how you can make this transition:

  1. Understand the Differences:
    • CommonJS uses require() for importing modules and module.exports or exports for exporting.
    • ESM introduces the import and export syntax natively to JavaScript.
    • ESM offers better performance, compatibility, and static analysis benefits.
  2. Update Your Code:
    • Start by converting your module syntax from require to import.
    • Rename files to use the .mjs extension (or adjust thetype property in package.json if you prefer.js for ESM).
  3. Package.json Configuration (optional):
    • Set "type": "module" in your package.json to enable ESM. Ensure backward compatibility by specifying .jsor .mjs extensions for ESM files.
juliajuju93 commented 7 months ago

For the future: we are currently having conversations about supporting this in the future. In the mean time, I will add a note to the readme file