@azure/avocado

中文文档
0.12.1发布于 2026/09/03MITTypeScriptES Module近 30 天下载 4.7万

A validator of OpenAPI configurations

原始使用文档
文档目录20 节
  1. Overview
  2. How to use
  3. Install
  4. Usage
  5. Example
  6. How to solve errors
  7. JSON_PARSE
  8. NO_JSON_FILE_FOUND
  9. UNREFERENCED_JSON_FILE
  10. MISSING_README
  11. NOT_AUTOREST_MARKDOWN
  12. INCONSISTENT_API_VERSION
  13. CIRCULAR_REFERENCE
  14. MULTIPLE_API_VERSION
  15. INVALID_FILE_LOCATION
  16. MISSING_APIS_IN_DEFAULT_TAG
  17. NOT_LATEST_API_VERSION_IN_DEFAULT_TAG
  18. MULTIPLE_DEFAULT_TAGS
  19. INVALID_TYPESPEC_LOCATION
  20. Contributing

Avocado

Another Validator of OpenAPI spec repository Configuration And Directories.

Build Status

NPM: https://www.npmjs.com/package/@azure/avocado

Overview

Avocado validates folder structure and configuration.

Avocado can be integrated into Azure pipeline to validate OpenAPI spec repository. For example, Avocado is used by Azure/azure-rest-api-specs now that will trigger automatically by azure DevOps pipeline when a new pull request is created.

Avocado major functions are listed below:

  • For a given directory validate whether exists specification and filter readme.md under the specification folder.
  • Validate whether readme.md is autorest specific file which must contain see https://aka.ms/autorest
  • Validate whether swagger file is valid json file, and check all referenced json file (referenced json file marked in json object has the key name "$ref").
  • Validate whether the folder has any files without being referenced. swagger file must be referenced by readme.md or other swagger file.
  • Validate whether swagger file has a circular reference and report a warning. For more detail, see CIRCULAR REFERENCE
  • Validate whether each RP folder contains readme file for SDK generation.

How to use

Install

npm install -g @azure/avocado

Usage

  • avocado -h show help message
  • avocado validate current directory
  • avocado -d <my-folder-path> validate <my-folder-path> directory
  • avocado -d <my-folder-path> --excludePaths 'common-types' validate folder and exclude errors from 'common-types'

Example

  • Run all specs: Clone the repo azure/azure-rest-api-specs and run "avocado" in folder azure/azure-rest-api-specs.
  • Run single service specs: create a folder specification. and move your service specs folder in specification. run "avocado"

How to solve errors

JSON_PARSE

Level: ERROR

To solve json parse error, you need make sure the json format is valid.

NO_JSON_FILE_FOUND

Level: ERROR

Readme file references a non-existing json file. To solve the error you need to check whether the json file is existing.

UNREFERENCED_JSON_FILE

Level: ERROR

Json file must be referenced by the readme input file section or other json files. Eg, example swagger file should be referenced by main swagger json and for SDK generation main swagger should be referenced by the readme input file section. To solve the error you need to place the non-referenced file to proper place.

MISSING_README

Level: ERROR

Each resource provider folder must have a readme file which is required by downstream SDK generation. To solve the error, you need create a readme file contains SDK generation config.

NOT_AUTOREST_MARKDOWN

Level: ERROR

Each readme in resource provider folder should follow autorest markdown format. To solve the error, you need check the readme block quote whether contains see https://aka.ms/autorest literally.

INCONSISTENT_API_VERSION

Level: ERROR

Swagger json file api version must consistent with its file path. Swagger can define swagger 2.0 basic-structure which contains api version. To solve the error, you need modify either your swagger file location or swagger file api version to make both of them consistent.

CIRCULAR_REFERENCE

Level: WARNING

To solve circular reference, you should break the circular chain.

Example: a.json -> b.json->c.json

// a.json
{ "$ref": "b.json" }
// b.json
{ "$ref": "c.json" }
// c.json
{ "$ref": "a.json" }
graph TD

A((a.json))-->B((b.json))
B-->C((c.json))
C-->A

MULTIPLE_API_VERSION

Level: ERROR

The default tag should contain only one API version.

To solve this error, you should add a new consistent version for all resource types within your service and copy the specs into the current version folder.

INVALID_FILE_LOCATION

Level: WARNING

The management plane swagger JSON file does not match its folder path. Make sure management plane swagger located in resource-manager folder

To solve this warning, you should make sure manager plane swagger located in resource-manager folder.

MISSING_APIS_IN_DEFAULT_TAG

Level: ERROR

The default API version tag (as seen in the Basic information section in the AutoRest configuration file (the README file)) should contain all API paths. The API path `${0}` is not present in any OpenAPI .json files enumerated in the list of paths included in the default tag, as seen in the relevant Tag: section in the AutoRest configuration file (the README file).

To fix this error include an OpenAPI .json file path in the list of the default API version tag paths (in the relevant Tag: section) that includes the missing API path.

IMPORTANT: The error may point to a previous API version. This does not mean this is a false positive! It means that the previous API version has an API path that is missing from the default API version.

Common scenarios where Avocado fails your PR correctly:

  • Often the API path is missing from the default API version due to casing mismatch; e.g. the path in the new API version has resourceGroups in it while the previous one has resourcegroups. See examples below.
  • If Avocado reports missing a path that you have intentionally deprecated or intentionally removed but the API version is publicly released (GA, generaly available, not in preview) first you need to get Breaking Change Board approval. Follow the breaking change process from step 1 in this diagram. If you already got such approval in a previous PR, follow the suppression guide. Mention the scenario you identified.

Known scenarios where Avocado reports false positive: Avocado may incorrectly report failures in following two scenarios:

  • Your API is deprecated/obsolete #6627 (example case in PR 24771)
  • Your API is using the service group folder #6201

If you are dealing with one of these scenarios, follow the suppression guide. Mention the scenario you identified.

When this error can be suppressed: If the missing API path is deprecated then you can suppress this error. Follow this [suppresion guide].

For example detailed analyses of occurrences of such errors, see these GitHub comments:

NOT_LATEST_API_VERSION_IN_DEFAULT_TAG

Level: ERROR

The default API version tag (as seen in the Basic information section in the AutoRest configuration file (the README file)) does not contain the latest API version of given OpenAPI .json file.

To fix this error, please make sure the .json file at the latest API version path is included in the list of paths for the default tag, in the relevant Tag: section in the AutoRest configuration file (the README file). Alternatively, change the default API version tag to a valid one by editing the Basic information section.

For an example detailed analysis of an occurrence of such error, see this GitHub comment.

MULTIPLE_DEFAULT_TAGS

Level: ERROR

The readme file has more than one default tag.

The expectation is there is only one default tag, which leads to one SDK package. To release separate SDK packages upon different service resources of the same RP, may consider adopting Folder Structure for Service Group, which supports a readme configuration file under each sub folder.

INVALID_TYPESPEC_LOCATION

Level: ERROR

TypeSpec file is not allowed in resource-manager or data-plane folder.

To fix this error. You should move TypeSpec file to TypeSpec folder.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

版本与发布记录

@azure/avocado 共发布 59 个版本,首次发布于 2019/03/06;过去 12 个月发布了 5 个版本。

版本发布日期距今
0.12.1latest2026/09/032 个月前
0.12.02026/08/202 个月前
0.11.02026/03/257 个月前
0.10.52025/11/2011 个月前
0.10.42025/11/2011 个月前
0.10.32025/10/081.1 年前

关于 @azure/avocado 的常见问题

@azure/avocado 是什么?

A validator of OpenAPI configurations

如何安装 @azure/avocado?

在项目目录运行 npm install @azure/avocado,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 avocado,可以用 npx avocado 直接运行。

@azure/avocado 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@azure/avocado 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@azure/avocado 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=22.0.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@azure/avocado 可以商用吗?

@azure/avocado 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@azure/avocado 的下载量有多少?

根据 npm 官方下载统计,@azure/avocado 在 2026/10/08 – 2026/11/06 这 30 天内被下载 47,466 次,日均约 1,582 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@azure/avocado 还在维护吗?

最新版本 0.12.1 发布于 2026/09/03(2 个月前);至今共发布 59 个版本,其中过去 12 个月发布了 5 个;首次发布于 2019/03/06。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。