Swiftpack.co - Swift Packages by mattpolzin

Swiftpack.co is a collection of thousands of indexed Swift packages. Search packages.

Packages published by mattpolzin

mattpolzin/OpenAPIKit 4.0.0-alpha.3
Codable Swift OpenAPI implementation.
⭐️ 261
πŸ•“ 4 weeks ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Null Happens (4)
4 weeks ago
## What's Changed * fix "nullable" decoding by @brandonbloom in https://github.com/mattpolzin/OpenAPIKit/pull/356 Technically `nullable` decoding was not broken for v3.1 documents, but this patch version introduces some leniency which allows decoding documents that contain the `nullable` keyword. This keyword was _the_ way of specifying nullability in v3.0 of the spec but in v3.1 the keyword was removed entirely. OpenAPIKit will now warn but automatically translate the `nullable` keyword into a valid v3.1 representation. ## New Contributors * @brandonbloom made their first contribution in https://github.com/mattpolzin/OpenAPIKit/pull/356 **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/4.0.0-alpha.2...4.0.0-alpha.3
Null Happens
4 weeks ago
## What's Changed * fix "nullable" decoding by @brandonbloom in https://github.com/mattpolzin/OpenAPIKit/pull/356 Technically `nullable` decoding was not broken for v3.1 documents, but this patch version introduces some leniency which allows decoding documents that contain the `nullable` keyword. This keyword was _the_ way of specifying nullability in v3.0 of the spec but in v3.1 the keyword was removed entirely. OpenAPIKit will now warn but automatically translate the `nullable` keyword into a valid v3.1 representation. ## New Contributors * @brandonbloom made their first contribution in https://github.com/mattpolzin/OpenAPIKit/pull/356 **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/3.1.2...3.1.3
Stronger Inference? (4)
15 weeks ago
## Bug fixes * Retain `inferred` property when updating any other property of a core context using a helper function (https://github.com/mattpolzin/OpenAPIKit/pull/352) **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/4.0.0-alpha.1...4.0.0-alpha.2
Stronger Inference?
15 weeks ago
## Bug Fixes * Retain `inferred` property value when updating any other property of a core context using a helper function (https://github.com/mattpolzin/OpenAPIKit/pull/352) **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/3.1.1...3.1.2
Early Equality
16 weeks ago
## Non-breaking Changes * Improvements to `AnyCodable` equality and ability to encode any `Encodable` (https://github.com/mattpolzin/OpenAPIKit/pull/351) ## Breaking Changes * Drop support for Swift versions prior to 5.8 (https://github.com/mattpolzin/OpenAPIKit/pull/339) * Fix typos for `serverVarialbeEnumIsValid` and `serverVarialbeDefaultExistsInEnum` (https://github.com/mattpolzin/OpenAPIKit/pull/348) ## New Contributors * @PARAIPAN9 made their first contribution in https://github.com/mattpolzin/OpenAPIKit/pull/348 **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/3.1.1...4.0.0-alpha.1
Allowed but not seen
18 weeks ago
## What's Changed * Simply ensure that `jsonSchemaDialect` at document root and the `$schema` keyword within JSON Schemas do not fail to parse (https://github.com/mattpolzin/OpenAPIKit/pull/349) Full support for these keywords will come with https://github.com/mattpolzin/OpenAPIKit/issues/202. **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/3.1.0...3.1.1
Explicitly Inferred
19 weeks ago
## What's Changed * Differentiate propertyless requirements (https://github.com/mattpolzin/OpenAPIKit/pull/343) / (https://github.com/mattpolzin/OpenAPIKit/pull/347) * Fix bug with conversion dropping explode property of parameters (https://github.com/mattpolzin/OpenAPIKit/pull/346) ### Identifying `required` entries that do not refer to `properties` in the immediate JSON Schema Take the following two schema snippets: ```yaml Foo: type: object properties: a: type: string required: - b ``` and ```yaml Foo: type: object properties: a: type: string b: {} required: - b ``` Prior to this version, both of those snippets would have been represented identically within `OpenAPIKit`. After this version, the first schema’s β€œb” property will answer `true` to the new `JSONSchema` `inferred` property and the second schema’s β€œb” property will answer `false`. In fact, the _only_ current situation where a JSON Schema is considered "inferred" is when a `.fragment` schema is produced by an entry in an object's `required` array that has no matching `properties` entry on the same object; we say that the existence of such a property is _inferred_ from the fact that such a property being required by name. **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/3.0.1...3.1.0
Maximize Goodness
20 weeks ago
## Bug Fixes * Fix integer max/min parsing and improve inconsistency errors (https://github.com/mattpolzin/OpenAPIKit/pull/342) **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/3.0.0...3.0.1
A Whole New World
20 weeks ago
This release of OpenAPIKit brings support for OpenAPI 3.1 in addition to numerous other improvements and a fair number of breaking changes (hopefully all worth their weight!). The biggest thing to know up front is that you will need to choose between one of two modules: `OpenAPIKit30` is a new module that continues to support the OAS 3.0 (OpenAPI 3.0 standard). `OpenAPIKit` is the module that supports the OAS 3.1 (OpenAPI 3.1 standard). I suggest migrating your code to the `OpenAPIKit` module if possible. You will need to do a bit more work (in some cases, not all) but this will set you up for the broadest support of OpenAPI Documents. OpenAPIKit 3.0.0 ships with another module named `OpenAPIKitCompat` that allows you to turn an `OpenAPIKit30.OpenAPI.Document` into an `OpenAPIKit.OpenAPI.Document` (i.e. convert from OAS 3.0 to OAS 3.1). There is not yet support for converting from OAS 3.1 to OAS 3.0, though that is a desirable (if not planned) addition. There is documentation on how to use this conversion to write your code against the `OpenAPIKit` module but support loading in both OAS 3.0 and OAS 3.1 documents [here](https://github.com/mattpolzin/OpenAPIKit/tree/main#supporting-openapi-30x-documents). There are two ways to explore the changes between OpenAPIKit v2.x and OpenAPIKit v3.0.0: 1. Read the release notes for each v3.0.0 pre-release (best way to see new features added, most granular information on changes including breaking changes). 2. Read the [migration guide](https://github.com/mattpolzin/OpenAPIKit/blob/main/documentation/v3_migration_guide.md) (fastest way to get yourself going against the new version).
Formats on Formats (release candidate)
20 weeks ago
## What's Changed * Adds missing `contentMediaType` and `contentEncoding` properties to `JSONSchema.string()` convenience constructor functions (https://github.com/mattpolzin/OpenAPIKit/pull/334) * Adds a few more builtin content types I was surprised to have not included already (https://github.com/mattpolzin/OpenAPIKit/pull/335) * JSON Schema String Format Updates (https://github.com/mattpolzin/OpenAPIKit/pull/337) ### Breaking Changes There are _no_ breaking changes to the `OpenAPIKit30` module. The following all apply to the `OpenAPIKit` module. - There is no longer `.extended` formats for `.string` JSON Schemas. Instead, all existing `.extended` formats are now just regular .`string` formats (e.g. you can just replace `.extended(.uuid)` with `.uuid`). - There are no longer `.byte` or `.binary` formats for `.string` JSON Schemas. Instead, use the `contentEncoding`s of `.base64` and `.binary`, respectively. - The `.uriReference` `.extended` JSON Schema `.string` format used to serialize to `uriref` whereas the new `.uriReference` JSON Schema `.string` format serializes to `uri-reference`, per the JSON Schema standard. - The new builtin `ContentType`s will not compare equally to custom types created previously (e.g. `ContentType.gif` is not equal to `ContentType.other("image/gif")`. If you need such things to compare equally, compare their `.rawValue` properties. **Full Changelog**: https://github.com/mattpolzin/OpenAPIKit/compare/3.0.0-rc.3...3.0.0-rc.4
iOS macOS
mattpolzin/JSONAPI 5.3.0
Swift Codable JSON:API framework
⭐️ 75
πŸ•“ 8 hours ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Include15 support
16 hours ago
Add support for including 15 different types of resources on one document.
Include14 support
20 hours ago
Support for 14 includes on one document.
New Include12 and Include13 types
1 year ago
Adds the ability to work with 12 or 13 include types on a single document.
Loosen Poly requirement in Podspec
2 years ago
The Cocoapods spec file was unnecessarily restricting the `Poly` dependency to patch version bumps instead of minor version bumps. This release simply loosens that requirement.
Fix compilation under Swift 5.4 pre-release (Xcode 12.5 betas)
3 years ago
This minor change with no source compatibility ramifications fixes compilation under the newest version of Swift's compiler.
5.0 - The More Meta The Merrier
3 years ago
See the release candidate notes for more information on the following: https://github.com/mattpolzin/JSONAPI/releases/tag/5.0.0-rc.1 ### Features & Improvements #### Better error reporting When there is a failure to decode `includes` in a JSON:API document, version 5 will give you a much more concise error message. Where before it would always tell you all the possible ways the include might have failed to decode, it will now attempt to determine which failure is relevant using a couple of simple heuristics about very common cases. If an include does not have a JSON:API type matching any of the types allowed to be included, the error will just tell you what type it found and what types it was looking for. If an include that failed to decode matches one of the expected JSON:API types, the error will report specifically the reason why _that_ type of resource could not be decoded. #### Resource Identifier Object metadata Previously, you could decode metadata that was found in the Relationship Object but not metadata that was found in the Resource Identifier Object nested within a Relationship Object. This gap in what the JSONAPI library can express has been fixed. See the [release candidate notes](https://github.com/mattpolzin/JSONAPI/releases/tag/5.0.0-rc.1) or the [JSON:API specification](https://jsonapi.org/format/#document-resource-object-relationships) for more information on the distinction. You can see more on using this new metadata location in this library's [relationship metadata documentation](https://github.com/mattpolzin/JSONAPI/blob/5.0.0-rc.1/documentation/usage.md#relationship-metadata). ### ⚠️ Breaking Changes ⚠️ `ToOneRelationship` and `ToManyRelationship` both gained an additional generic type parameter named `IdMetaType`. This means that any code that uses them directly or typealiases them will need to be updated. ```swift // before ToOneRelationship<Identifiable: JSONAPI.JSONAPIIdentifiable, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> // after ToOneRelationship<Identifiable: JSONAPI.JSONAPIIdentifiable, IdMetaType: JSONAPI.Meta, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> //before ToManyRelationship<Relatable: JSONAPI.Relatable, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> //after ToManyRelationship<Relatable: JSONAPI.Relatable, IdMetaType: JSONAPI.Meta, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> ``` if you don't need to take advantage of this new metadata location, you can do away with it just like with any other option your relationship does not need. Here are two examples of typealiases that do away with all of the various auxiliary information: ```swift typealias ToOne<T: JSONAPIIdentifiable> = JSONAPI.ToOneRelationship<T, NoIdMetadata, NoMetadata, NoLinks> typealias ToMany<T: JSONAPI.Relatable> = JSONAPI.ToManyRelationship<T,NoIdMetadata, NoMetadata, NoLinks> ```
Version 5.0.0 Release Candidate 1
3 years ago
This version has drastically clearer error reporting around failures to decode `includes` in a JSON:API document (thanks @mlomeli for the help in designing a better experience). This version also adds support for metadata within Resource Identifier Objects. You were already able to represent metadata in Relationship Objects, but now metadata support for relationships should be complete. The difference is subtle. Here's metadata in the Relationship Object: ```json { "data": { "type": "people", "id": "88223", "attributes": { ... }, "relationships": { "pet": { "data": { "type": "dogs", "id": "123" }, "meta": { "nickname": "Sparks" } } } } } ``` Here's metadata in the Resource Identifier Object (look for it _one level deeper_ next to the `id`/`type` of the related resource): ```json { "data": { "type": "people", "id": "88223", "attributes": { ... }, "relationships": { "pet": { "data": { "type": "dogs", "id": "123", "meta": { "nickname": "Sparks" } } } } } } ``` In order to support this new metadata location, the following breaking change was made. ⚠️ Breaking Changes ⚠️ `ToOneRelationship` and `ToManyRelationship` both gained an additional generic type parameter named `IdMetaType`. This means that any code that uses them directly or typealiases them will need to be updated. ```swift // before ToOneRelationship<Identifiable: JSONAPI.JSONAPIIdentifiable, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> // after ToOneRelationship<Identifiable: JSONAPI.JSONAPIIdentifiable, IdMetaType: JSONAPI.Meta, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> //before ToManyRelationship<Relatable: JSONAPI.Relatable, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> //after ToManyRelationship<Relatable: JSONAPI.Relatable, IdMetaType: JSONAPI.Meta, MetaType: JSONAPI.Meta, LinksType: JSONAPI.Links> ``` if you don't need to take advantage of this new metadata location, you can do away with it just like with any other option your relationship does not need. Here are two examples of typealiases that do away with all of the various auxiliary information: ```swift typealias ToOne<R> = ToOneRelationship<R, NoIdMetadata, NoMetadata, NoLinks> typealias ToMany<R> = ToManyRelationship<R, NoIdMetadata, NoMetadata, NoLinks> ``` If you do need to use the new metadata location, it is really just `JSONAPI.Meta` like any other metadata -- that is, it really just needs to be `Codable` and `Equatable`. if you've got a resource with a relationship containing metadata inside the Resource Identifier Object, see the [new documentation](https://github.com/mattpolzin/JSONAPI/blob/release/v5/documentation/usage.md#relationship-metadata) for information on getting at that metadata!
Version 4.0.0 Stable Release
3 years ago
### Additions & Fixes Release 4.0.0 has changed in the following ways since version 3.x. The following list includes changes for all 4.0.0 alpha and release candidates. There are no functional changes between the latest release candidate and this stable release. βž• `ResourceObject` is now `Hashable` when it is not `Unidentified`. βž• `ResourceObject` now conforms to `Swift.Identifiable` when it is not `Unidentified`. βž• `CompoundResource` and new `Document` initializers make document creation more ergonomic. βž• Modify `Document.SuccessDocument` to guarantee non-optional properties where appropriate. βž• `SucceedableJSONAPIDocument` and `FailableJSONAPIDocument` improve generic abstraction story. βž• `MetaRelationship` added for relationships with only links and metadata. 🐞 Fix/Improve errors during decoding caused by malformed ResourceObject relationships. ### Breaking Changes ⚠️ Bump minimum Swift version to 5.2 πŸ“› Renames `Identifiable` to `JSONAPIIdentifiable` to avoid confusion and conflict with `Swift.Identifiable`. πŸ“› Renames `JSONAPIIdentifiable`'s `Identifier` associated type to `ID` to match that of the Swift `Identifiable` type. πŸ—‘ Remove deprecated subscript access to ResourceObject attributes. ### Suggested approach to migrating code: - Find `JSONAPI.Identifiable` or `Identifiable` (careful not to pick up any uses of Swift `Identifiable` in your codebase) and replace with `JSONAPIIdentifiable`. - Anywhere you are using `Identifier()` in the context of a `ResourceObject` to construct its ID, replace with `ID()`. - Anywhere you are using subscript access on `ResourceObject` to access an attribute, switch to using dynamic member access (i.e. `widget[\.cog]` changes to widget.cog`).
Bugfix for typealias/associatedtype conflict.
3 years ago
One protocol's `typealias` will collide with another protocol's `associatedtype` in very ugly ways. This is why for now we will have `ResourceObject.ID` and `ResourceObject.Id` (both equally valid ways of referring to a `ResourceObject`'s Identifying type.
Bugfix for ResourceObjectProxy
3 years ago
Attempt to fix a bug that only shows up in edge cases where `ResourceObjectProxy.ID` is used directly and must be equal to `ResourceObject.ID`.
iOS macOS
mattpolzin/swift-test-codecov 0.13.0
Simple executable to produce code coverage numbers from the output of `swift test --enable-code-coverage`
⭐️ 48
πŸ•“ 1 year ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Support floating point minimum coverage numbers.
1 year ago
## What's Changed * Allow floating point minimum code coverage numbers. by @mattpolzin in https://github.com/mattpolzin/swift-test-codecov/pull/21 **Full Changelog**: https://github.com/mattpolzin/swift-test-codecov/compare/0.12.0...0.13.0
Fixes, a new print format, and regex file exclusion
1 year ago
## What's Changed * Add `print-format` for unformatted total coverage result by @edelabar in https://github.com/mattpolzin/swift-test-codecov/pull/14 * Add `--exclude-path` option to filter files based on path with a regex by @edelabar in https://github.com/mattpolzin/swift-test-codecov/pull/15 * Fix test file identification. by @mattpolzin in https://github.com/mattpolzin/swift-test-codecov/pull/18 **Full Changelog**: https://github.com/mattpolzin/swift-test-codecov/compare/0.11.3...0.12.0
Added a Makefile
1 year ago
Thanks to @edelabar there is now a Makefile that includes a sensible default `make install` path for MacOS.
Support GitHub CI local dependencies
1 year ago
Support specifying a project name for local dependency detection rather than relying on the current working directory being the source-code root of the target project.
Fix recognition of local path dependencies
1 year ago
Previously, dependencies in a project that were created with local file paths rather than references to remote repositories would not be recognized as dependencies when calculating coverage numbers. This PR fixes that issue, though it is now important to run the swift-test-codecov tool from the root folder of a project.
Omit test files (with option to include)
2 years ago
This release adds the ability to include/exclude test files in the calculation of code coverage (thanks @ravitripathi!). Breaking Changes: - By default, test files will be excluded from coverage report. Use the `--tests` flag to include them. - The `-d` shorthand for the `--dependencies` flag has been removed.
More useful output
3 years ago
Without changing the actual aggregation features, adds the ability to print a JSON representation of results containing all the information used in building out the table output and the summary. Breaking: - There is no longer a `-t`/`--table` option; use `--print-format=table` instead now. - All output options used to short-circuit on failure and just print a message about the test coverage not meeting the minimum requirements; now, the script will exit with code 1 in the same situations but it will always print out the desired format of output (JSON, table, or just the percentage).
Add option to sort coverage table.
3 years ago
Adds an option to sort the coverage table by filename (default) or ascending or descending coverage percent. Also moves to the latest version of Argument Parser.
Bumps Argument Parser dependency to latest version.
3 years ago
Thanks to @cgrindel for updating the executable to support the latest version of Argument Parser.
Fix compilation prior to Swift 5.2
3 years ago
I had used some Swift 5.2 syntax -- fixed in this release! Thanks to @justAnotherDev for the fix.
mattpolzin/Poly 2.8.0
A light-weight general-purpose library to help represent situations where the type of a value is one of a set of types. An alternative to type erasure.
⭐️ 18
πŸ•“ 10 hours ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Add Poly15 support
16 hours ago
Add Poly15 type.
Add Poly14 support
20 hours ago
Add support for the `Poly14` type.
Add Poly12 and Poly13 Types
1 year ago
Platformed
2 years ago
Introduce explicit iOS and MacOS platform minimums to the Swift package manifest.
(and again) error printout refinement
3 years ago
Another refinement to error printing
3 years ago
Add Hashable conformances
3 years ago
All Poly types gain `Hashable` conformance when all generic types upon which the `Poly` is specialized are also `Hashable`.
Add the `allTypes` accessor
4 years ago
This accessor can be useful for generating logging based on the types a particular `Poly` allows. ```swift let typeNames = Poly2<Int, Double, String>.allTypes .map { String(describing: $0) } .joined(separator: ", ") ```
Expose two previously internal properties on an error type.
4 years ago
Add `Poly.value` accessor
4 years ago
Add accessor on `Poly` that retrieves a type-erased value. ```swift let either = Either<Int, String>(10) let value = either.value // type is `Any` ```
iOS macOS
mattpolzin/OpenAPIReflection 2.0.0
Additional support for turning Swift Types into OpenAPISchema
⭐️ 17
πŸ•“ 20 weeks ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Support OpenAPI 3.1.0
20 weeks ago
This version requires OpenAPIKit 3.x and supports both OAS 3.0 and OAS 3.1. OpenAPIReflection now has two modules, mirroring the split in OpenAPIKit. `OpenAPIReflection` supports OAS 3.1 and `OpenAPIReflection30` supports OAS 3.0.
Fix Optional reflection
1 year ago
This fixes a bug where if a type that does not define its OpenAPI schema explicitly was wrapped in an `Optional` and then set as a property of some type for which a `genericOpenAPISchemaGuess()` was requested then the generic schema guess would result in the optional being represented as an explicit "some" key in the schema instead of just making the type it wraps optional.
First stable release.
3 years ago
First stable release. Uses OpenAPIKit v2.
Version 1.0.0 Release Candidate 1
3 years ago
Update to release candidate of OpenAPIKit, add a bit of test coverage, remove outdated "node" terminology with reference to JSON Schemas.
Version 1.0.0 Alpha 1
3 years ago
Building out first official release against OpenAPIKit v2.
Can you git me now?
3 years ago
Switch to Swift Package Manager dependency URLs that contain the `.git` extension. This is not required by SwiftPM, but if a project does not consistently use the `.git` extension on dependency URLs (or not) then SwiftPM can get into trouble. The majority of open source projects use or suggest using the `.git` extension, so this project will standardize in that direction as well.
Update to OpenAPIKit v1.0
3 years ago
⚠️ Breaking Changes ⚠️ Updates to OpenAPIKit v1.0 which introduced a number of breaking changes (although it will now be stable for duration of the v1 major version).
Bump OpenAPIKit version
3 years ago
⚠️ Breaking Changes ⚠️ In addition to the breaking changes in OpenAPIKit 0.29.x -> 0.30.x, this version removes support for pre-Swift 5.2 toolchains.
Update OpenAPIKit version
3 years ago
Fix date encoding bug
3 years ago
mattpolzin/JSONAPI-OpenAPI 0.32.0
A library that adds support for generating OpenAPI compliant documentation from JSON API compliant models.
⭐️ 9
πŸ•“ 5 weeks ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
More versatility
5 weeks ago
## What's Changed * Tweaks to better support Viz generation. by @mattpolzin in https://github.com/mattpolzin/JSONAPI-OpenAPI/pull/26 **Full Changelog**: https://github.com/mattpolzin/JSONAPI-OpenAPI/compare/0.31.0...0.32.0
Uses OpenAPIKit 3.0.0
20 weeks ago
OpenAPIKit 3.0.0 Swift 5.9
Fixes test namespaces when some reserved words are found in a route path
1 year ago
For example, the route `go/do/accept` would previously have resulted in a Swift code generated namespace of `go.do.accept` and the `do` component is a reserved word so it will fail to compile. This is fixed by escaping `do` with backticks in generated code.
Fix JSONAPI relationship gen for v5
1 year ago
The JSONAPI relationships generated will now successfully compile for v5 of the JSONAPI library.
Support anyOf structure generation
2 years ago
Rudimentary allOf structure generation (Swift code generation) support. This implementation is not accurate in the general case, but it supports `anyOf` at least a little by generating the same `Poly` structures as are generated for `oneOf`.
Support named examples
3 years ago
Support for multiple named example parse tests when named response examples are used in documentation.
Add support for oneOf in more places.
3 years ago
Now in some places, like JSON:API attributes, `oneOf` is supported to allow for polymorphic OpenAPI specs to be representable by Swift types generated by this library. The new support comes by way of the `Poly` type that was there all along to support JSON:API includes.
Add error when not all path parameters are defined
3 years ago
Update for OpenAPIKit v2
3 years ago
Note that OpenAPIKit v2 introduced breaking changes.
Update for JSONAPI v5 release.
3 years ago
Update to the JSONAPI library v5 and drop Swift 5.2 support (easiest way to keep using swift-format).
macOS
mattpolzin/OpenAPIDiff 0.7.0
Diffing Library for OpenAPI documentation.
⭐️ 7
πŸ•“ 20 weeks ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Support OAS 3.1
20 weeks ago
Update to OpenAPIKit 3.0.0 and support OAS 3.0 as well as OAS 3.1
Update for OpenAPIKit v2
3 years ago
Note that OpenAPIKit v2 introduced breaking changes.
Switch all dependencies to using .git extension
3 years ago
Switch to Swift Package Manager dependency URLs that contain the .git extension. This is not required by SwiftPM, but if a project does not consistently use the .git extension on dependency URLs (or not) then SwiftPM can get into trouble. The majority of open source projects use or suggest using the .git extension, so this project will standardize in that direction as well.
Fast JSON parsing option
3 years ago
Adds the `--fast` flag that uses a faster less battle-tested parser to get substantial speed gains in Linux environments (like the Dockerized app).
Stable schema property sorting.
3 years ago
Updates to OpenAPIKit make the sorting of schema object required properties stable. This will make the schema diffing of this library/tool much more useful.
Add a bit of Security Scheme support
3 years ago
Update OpenAPIKit
3 years ago
Update OpenAPIKit, Update CLI, Add option to print stats
4 years ago
Now you can print help with `openapi-diff --help`. You can print stats (additions, removals, changes) with a `--stats` option.
Updates to OpenAPIKit
4 years ago
Just updates OpenAPIKit to take advantage of bug fixes and improvements.
Big improvements to how flattening is done.
4 years ago
mattpolzin/jsonapi-openapi-test-server 0.21.0
Server that builds a OpenAPI/JSON:API Swift test suite and runs it.
⭐️ 5
πŸ•“ 12 hours ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Include15 support
16 hours ago
Support including 15 different resource on one document (regarding testing).
Include14 Support
19 hours ago
Adds support for 14 includes on one document (regarding generated Swift code used in testing).
0.19.1
20 weeks ago
## What's Changed * Update deps, specifically Vapor, to fix a precondition crash in NIO (https://github.com/mattpolzin/jsonapi-openapi-test-server/pull/32) **Full Changelog**: https://github.com/mattpolzin/jsonapi-openapi-test-server/compare/0.19.0...0.19.1
Big dependency updates
20 weeks ago
Updated Swift version to 5.9. Updated OpenAPIKit to 3.0.0 (still using OAS 3.0 document parsing, though). Removed `--parser` option without graceful migration; newer versions of Swift std json parser is faster so no need for a third party fast parser.
Fix bug with required-ness of `allOf` schemas
36 weeks ago
This release fixes a bug where the simplified schema resulting from an `allOf` schema would not have the correct `required`ness (it would be required when it should be optional.
Fix keywords in generated namespaces
1 year ago
For example, the route `go/do/accept` would previously have resulted in a Swift code generated namespace of `go.do.accept` and the `do` component is a reserved word so it will fail to compile. This is fixed by escaping `do` with backticks in generated code.
Support Include12 and Include13 JSONAPI types
1 year ago
Rudimentary support for anyOf schemas
2 years ago
This implementation is not accurate in the general case, but it supports `anyOf` at least a little by generating the same `Poly` structures as are generated for `oneOf`.
Multiple Named Examples
3 years ago
Supports generating multiple example parse tests when multiple named examples are provided on responses.
OneOf and multiline errors.
3 years ago
- Add support for `OneOf` JSON Schema in more places, namely JSON:API attributes. - Add support for multiline error messages in console logs.
iOS macOS
mattpolzin/VaporTypedRoutes 0.10.0
Typed Routes extension to the Vapor framework.
⭐️ 4
πŸ•“ 20 weeks ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Update Vapor version
20 weeks ago
Update to the newest Vapor version (4.86.0). This version broke storage of plain strings in route user info, so the fix requires that the new minimum Vapor version is now 4.86.0.
Required and Deprecated Query Parameters
1 year ago
Thanks to @TimAEllis we now have the ability to indicate query parameters are required or deprecated.
async/await support
1 year ago
Huge thanks to @tetraoxygen for adding async/await support _and_ doing a lot of code documentation!
Add `encodeEmptyResponse()`
2 years ago
Because `EmptyResponseBody` cannot be constructed, expose a special encode function for use in controllers needing to produce an empty response body.
Add `TypedPathComponent`
3 years ago
Add ability to track path parameter type & description in `Route` `userInfo`.
Add `JSONRouteContext`
3 years ago
Add a route context that has the default content type of application/json built in.
Require `RouteContext`s to explicitly specify (or explicitly not specify) a default content type.
3 years ago
⚠️ Breaking Change ⚠️ `RouteContext` gains a new requirement: `defaultContentType`. This can be `nil` to specify there is no default content type, or it can be set to an `HTTPMediaType` to specify a default content type. The benefit of having a default type is that APIs can still respond to requests that do not provide a `Content-Type` by assuming the default in cases where there is a reasonable default (perhaps most often `application/json`).
Fix for Vapor 4.5.0
3 years ago
Vapor 4.5.0 had a small but breaking change that is fixed in this version.
Move to requiring Vapor 4.x releases
3 years ago
Update to Vapor 4.0.0 release candidate 3
4 years ago
⚠️ Breaking Changes ⚠️ Vapor 4 now requires OS X 10.15+.
macOS
mattpolzin/TransformEncoder 0.2.0
A Swift Encoder that performs transformations on Codable hierarchies.
⭐️ 2
πŸ•“ 1 year ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Improve human readability of ValidationError type.
4 years ago
Initial Release
4 years ago
A little basic and somewhat preliminary support for transforming and validating using Codable conformance.
macOS
mattpolzin/OrderedDictionary 1.1.1
A Swift OrderedDictionary implementation based off of a Dictionary and an Array
⭐️ 1
πŸ•“ 3 years ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Ensure failure when key decoding cannot decode all keys.
4 years ago
Add a couple of Dictionary initializers and a defaultable subscript accessor.
4 years ago
Initial release of OrderedDictionary pulled out of OpenAPIKit
4 years ago
mattpolzin/JSONAPI-ResourceStorage 0.4.0
Two JSONAPI Resource storage modules.
⭐️ 1
πŸ•“ 1 year ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
`JSONAPIResourceStore` primary resource access on `Document`
1 year ago
See the new [example](https://github.com/mattpolzin/JSONAPI-ResourceStorage/blob/master/Tests/JSONAPIResourceStoreTests/SingleResponseExample.swift) test case for details. In short, `document.storedPrimaryResource()` for single resource documents and `document.storedPrimaryResources()` for many resource documents will access the document's primary resource(s) as `StoredResource`s. This means it is faster and more convenient to treat the response document as a coherent unit of primary resources with their related includes directly accessible.
Bump to JSONAPI v5
3 years ago
Note that JSONAPI v5 introduced breaking changes to relationship types. See the [release notes](https://github.com/mattpolzin/JSONAPI/releases/tag/5.0.0) for details. The short version of the story is that all things that are generic of the type of relationship being described gain an additional type parameter that specifies the type of metadata inside the Resource Identifier Object. This is named the `IdMetaType` and it is a `JSONAPI.Meta` just like any other metadata.
Specify platform minimums
3 years ago
Platform minimums inherited by dependance on `JSONAPI` are now explicit in this package's manifest.
Update to stable release versions of JSONAPI v4
3 years ago
Rename `materialize()` to `materialized()`
3 years ago
Update to latest JSON release candidate.
3 years ago
Add non-optional constructors for SuccessDocument.
3 years ago
Initial pre-release
3 years ago
iOS macOS
mattpolzin/JSONAPI-Arbitrary 6.0.0
JSONAPI+Arbitrary adds Arbitrary conformances for many JSONAPI types making it much easier to use JSONAPI and SwiftCheck together.
⭐️ 0
πŸ•“ 3 years ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Update for JSONAPI v5
3 years ago
Update for JSONAPI v4 release.
3 years ago
Update to latest release candidate of JSONAPI
3 years ago
Update to JSONAPI v4 alpha releases
3 years ago
Update to JSONAPI library version 3.0.0
4 years ago
⚠️ Breaking Changes ⚠️ Version 3.0.0 of the `JSONAPI` library has a number of breaking changes. This update adds and fixes arbitrary conformances where needed to support the 3.0.0 release.
Update dependencies
4 years ago
Update to latest mattpolzin/JSONAPI version
4 years ago
⚠️ Breaking change ⚠️ Updated to latest `mattpolzin/JSONAPI` version which includes some breaking name changes. Basically anything that used to have "Entity" in the name now has "ResourceObject" in the name to better align with the JSON:API spec naming.
Swift 5.0 / Swift Tools 5.0
4 years ago
⚠️ Breaking Change ⚠️ Requires Swift Tools version 5.0 (Shipped with Xcode 10.2)
5 years ago
mattpolzin/mapper 8.1.2
A JSON deserialization library for Swift
⭐️ 0
πŸ•“ 5 years ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Make Package.swift fully 4.2 compliant
5 years ago
Just bump package manager version
5 years ago
mattpolzin/JSONAPI-Combine 0.0.2
Combine Framework extensions for JSONAPI resource handling.
⭐️ 0
πŸ•“ 2 years ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Update to JSONAPI v5
3 years ago
Initial pre-release
3 years ago
iOS macOS
mattpolzin/JSONAPIViz 0.0.6
JSONAPI support for generating a GraphViz DOT format string.
⭐️ 0
πŸ•“ 3 years ago
πŸ”– Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
Update for JSONAPI v5 release
3 years ago
Update for JSONAPI v4 release.
3 years ago
Support latest JSONAPI release candidate.
3 years ago
Bumping JSONAPI version to 4.0.0 alpha
3 years ago
Modify dependency rule
4 years ago
Initial Pre Release
4 years ago

Swiftpack is being maintained by Petr Pavlik | @ptrpavlik | @swiftpackco | API | Analytics