Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@pactflow/swagger-mock-validator

Package Overview
Dependencies
Maintainers
6
Versions
22
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@pactflow/swagger-mock-validator - npm Package Compare versions

Comparing version 11.2.0 to 11.3.0

19

CHANGELOG.md

@@ -0,1 +1,20 @@

<a name="11.3.0"></a>
# [11.3.0](https://github.com/pactflow/swagger-mock-validator/compare/11.2.0...11.3.0) (2022-07-07)
### Bug Fixes
* fix linting errors ([007c76c](https://github.com/pactflow/swagger-mock-validator/commit/007c76c))
* fix the build ([f98715b](https://github.com/pactflow/swagger-mock-validator/commit/f98715b))
### Features
* add pact v4 e2e test ([c6b6418](https://github.com/pactflow/swagger-mock-validator/commit/c6b6418))
* filter requests by type to support v4 ([923f241](https://github.com/pactflow/swagger-mock-validator/commit/923f241))
* update pact parser to filter out all unsupported interaction types ([343647d](https://github.com/pactflow/swagger-mock-validator/commit/343647d))
* Update pact-parser.ts ([a200bf0](https://github.com/pactflow/swagger-mock-validator/commit/a200bf0))
<a name="11.2.0"></a>

@@ -2,0 +21,0 @@ # [11.2.0](https://github.com/pactflow/swagger-mock-validator/compare/11.1.0...11.2.0) (2022-06-14)

12

dist/swagger-mock-validator/mock-parser/pact/pact-parser.js

@@ -79,4 +79,4 @@ "use strict";

};
parsedInteraction.getRequestBodyPath = (path) => getBodyPath(interaction.request.body, `${parsedInteraction.location}.request.body`, path);
parsedInteraction.getResponseBodyPath = (path) => getBodyPath(interaction.response.body, `${parsedInteraction.location}.response.body`, path);
parsedInteraction.getRequestBodyPath = (path) => { var _a; return getBodyPath((_a = interaction === null || interaction === void 0 ? void 0 : interaction.request) === null || _a === void 0 ? void 0 : _a.body, `${parsedInteraction.location}.request.body`, path); };
parsedInteraction.getResponseBodyPath = (path) => { var _a; return getBodyPath((_a = interaction === null || interaction === void 0 ? void 0 : interaction.response) === null || _a === void 0 ? void 0 : _a.body, `${parsedInteraction.location}.response.body`, path); };
parsedInteraction.parentInteraction = parsedInteraction;

@@ -114,6 +114,12 @@ parsedInteraction.requestBody = {

};
const filterUnsupportedTypes = (interaction) => {
if (!(interaction === null || interaction === void 0 ? void 0 : interaction.type) || interaction.type === 'Synchronous/HTTP') {
return interaction;
}
return null;
};
exports.pactParser = {
parse: (pactJson, mockPathOrUrl) => ({
consumer: pactJson.consumer.name,
interactions: pactJson.interactions.map((interaction, interactionIndex) => parseInteraction(interaction, interactionIndex, mockPathOrUrl)),
interactions: pactJson.interactions.filter(interaction => filterUnsupportedTypes(interaction)).map((interaction, interactionIndex) => parseInteraction(interaction, interactionIndex, mockPathOrUrl)),
pathOrUrl: mockPathOrUrl,

@@ -120,0 +126,0 @@ provider: pactJson.provider.name

@@ -69,8 +69,4 @@ # Contributing

This project is versioned using [Semantic Versioning](http://semver.org/).
See [Releasing](RELEASING.md)
- `npm run release-patch` - Publishes a patch version to npm, e.g. 1.0.0 -> 1.0.1
- `npm run release-minor` - Publishes a minor version to npm, e.g. 1.0.0 -> 1.1.0
- `npm run release-major` - Publishes a major version to npm, e.g. 1.0.0 -> 2.0.0
## Bumping project dependencies

@@ -77,0 +73,0 @@

@@ -41,7 +41,8 @@ # Releasing

- Make sure master contains the code you want to release
- Run one of the following, depending on the class of change
- `npm run release-patch`
- `npm run release-minor`
- `npm run release-major`
- Run one of the following, depending on the class of change. These scripts send the custom repository_dispatch event `release-triggered`, kicking of the release workflow.
- `./scripts/trigger-release-patch` - Publishes a patch version to npm, e.g. 1.0.0 -> 1.0.1
- `./scripts/trigger-release-minor` - Publishes a minor version to npm, e.g. 1.0.0 -> 1.1.0
- `./scripts/trigger-release-major` - Publishes a major version to npm, e.g. 1.0.0 -> 2.0.0
Then wait for github to do its magic. It will release the current head of master.

@@ -48,0 +49,0 @@

@@ -113,2 +113,69 @@ # Frequently Asked Questions

- If possible, always set additional properties to false on all response schema objects. This avoids the false negative case completely.
- Using a tool to detect backward incompatible changes to the swagger file. We have been working on a tool called openapi-diff that will detect breaking changes between two swagger/openapi files that may help, although it is still a work in progress.
- Using a tool to detect backward incompatible changes to the swagger file. We have been working on a tool called openapi-diff that will detect breaking changes between two swagger/openapi files that may help, although it is still a work in progress.
## Pactflow fails my contract verification, stating that the 'Response Body Contains Unknown Information'. My OpenAPI specification is valid and matches the expectations in my consumer contract. How come?
Here's one reason that this error occurs when verifying your bidirectional contracts.
The current OpenAPI specification supports wildcards for the `content` field defining the media type of a response payload. See [this section in the OpenAPI 3.1.0 specification](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#fixed-fields-15) for more details.
It allows developers to support different media types (e.g., JSON and XML) for the response payloads without having to define separate specifications.
So, for example, this snippet defining responses for an operation is valid, according to the OpenAPI specification:
```json
"responses": {
"404": {
"description": "Not Found"
},
"400": {
"description": "Bad Request"
},
"200": {
"description": "OK",
"content": {
"*/*": {
"schema": {
"$ref": "#/components/schemas/Address"
}
}
}
}
}
```
where `Address` is an [OpenAPI Schema Object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#schemaObject).
However, these wildcards are not supported by the swagger mock validator. Using an OpenAPI specification containing these wildcards will result in the aforementioned error, with Pactflow reporting:
```text
Response Body Contains Unknown Information.
No schema found for response body
```
The recommended solution is to replace the wildcards with the applicable specific content type, such as `application/json`:
```json
"responses": {
"404": {
"description": "Not Found"
},
"400": {
"description": "Bad Request"
},
"200": {
"description": "OK",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/Address"
}
}
}
}
}
```
If there are indeed no mismatches between expectations in the consumer bidirectional contract and the provider specification contract, Pactflow will upon reverification no longer fail the bidirectional contract verification.
{
"name": "@pactflow/swagger-mock-validator",
"version": "11.2.0",
"version": "11.3.0",
"description": "A CLI tool to validate mocks against swagger/OpenApi specs.",

@@ -5,0 +5,0 @@ "bin": {

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc