Skip to content

Releases: disneystreaming/smithy4s

v0.17.6 : bug fixes and minor maintainer-facing improvements

02 May 10:28
@Baccata Baccata
v0.17.6
7a60eb7
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.17.6 : bug fixes and minor maintainer-facing improvements

This release is backward binary-compatible with the previous releases from the 0.17.x lineage.

Bug fixes

  • Fixes a bug related to swagger-ui redirects that would occur with empty paths.
  • Fixes a bug related to the undocumented "dynamic" module not respecting the order of fields specified in smithy models

What's Changed

Full Changelog: v0.17.5...v0.17.6

Contributors

kubukoz, Baccata, and 3 other contributors
Assets 2
Loading

v0.17.5

15 Mar 21:50
@kubukoz kubukoz
v0.17.5
374d3e5
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.17.5

This release is backward binary-compatible with the previous releases from the 0.17.x lineage.
However, the generated code produced by this version is not entirely source-compatible with the previous version.
More info below.

Possible breaking changes

This version introduces changes in how the code is rendered that may result in some breakage in userland. We've
carefully architected the changes to reduce the likelihood of breakage happening.

A number of constructs are now rendered not in the companion object of the generated service, but rather in the companion
object of the reified operation type. These constructs include the error types that get generated by operations.

This change has been performed in order to eliminate the risk of collision between the generated types and some type
members present in the smithy4s.Service interface. This collision, when it happened, was making the code impossible to
compile.

In order to reduce breakage around the error types (which are likely to be used in userland), we have decided to generate
aliases at the location where they used to live. The generated code should not break source compatibility in the large
majority of usage of Smithy4s.

A small minority of users may have to change how they access the generated constructs they may have depended on. This is unlikely,
as the constructs in question are used internally by interpreters via interfaces that haven't changed, and they are not constructs
that are advertised in our documentation. We only expect some possible breakage in advanced usage performed by a handful of
people.

See:

Behavioural changes

Adjust encoding/decoding HTTP query parameters

Changed the handling of the httpQueryParams (plural) trait so that possible httpQuery-annotated fields do not take priority
over it during decoding. This means that httpQueryParams receive the whole set of query parameters, which may induce duplication
with the value contained by overlapping httpQuery-annotated fields.

On the encoding side, the behaviour is that httpQuery fields have priority over httpQueryParams fields.

This is a more faithful implementation of the spec.

See #827

Improvements

Validate model for codegen after transformations

Adds logic to validate the model after pre-processing model transformations (before the code-generation)

See #821

Support time zones in DATE_TIME parsing

AWS has changed the Smithy specification of the DATE_TIME timestamp format to precise that numeric offsets should be handled.
This is now the case.

See #844

Dynamic: Add metadata method

The currently undocumented dynamic module has received an improvement allowing to access the metadata
of the loaded models via its platform-agnostic interface.

See #823

Bug fixes

Http4s client body

Empty bodies are now correctly using the built-in withEmptyBody of Http4s, which correctly removes
the Content-Type header from the request upon usage. This solves issues when Smithy4s is being called
(or calling) strict clients/servers that check this type of thing.

See #826

Handle NaN and Infinity in AWS JSON codecs

The AWS Json protocols specify that NaN, Infinity and -Infinity are valid values for Double and Float types.
This is now handled.

See #822

Better handling of special characters when loading Smithy models from dependencies

A bug was preventing dependencies that would have special characters in their absolute paths to be loaded successfully.
This is now fixed.

See #850

Http4s client: Support Byte parameters in paths

Byte fields are now correctly supported when used by an httpLabel member.

See #819

Library updates

Full Changelog: v0.17.4...v0.17.5

Contributors

dependabot and scala-steward
Assets 2
Loading

v0.17.4: more efficient ArraySeq json parsing

13 Feb 14:32
@Baccata Baccata
v0.17.4
b694728
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.17.4: more efficient ArraySeq json parsing

0.17.4

Improvements

More efficient Json parsing of ArraySeq

See #806

Fix parsing logic of AWS credentials file to allow for comments

See #811

Add documentation on how to point AWS clients to local environments

See #812

What's Changed

New Contributors

Full Changelog: v0.17.3...v0.17.4

Contributors

etspaceman, plokhotnyuk, and 3 other contributors
Assets 2
Loading

v0.17.3: Scaladocs, easier ADTs, Scala 3 wildcards, easier AWS SDK usage

10 Feb 10:57
@Baccata Baccata
v0.17.3
1cefba2
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.17.3: Scaladocs, easier ADTs, Scala 3 wildcards, easier AWS SDK usage

0.17.3

This release is backward binary-compatible with the previous releases from the 0.17.x lineage.

General announcements

  • We are opening a public Discord server for users to ask questions about Smithy4s and the Smithy ecosystem in general
  • We are lowering the barrier of entry to use Smithy4s as an AWS SDK. Go check out the docs 😄

User-facing features

Addition of an new @adt trait to streamline the inlining of structures as sealed-trait members

Under certain conditions, it is now possible to annotate union shapes with @adt, which has the effect of inlining
all the structure shapes under it directly in the companion object of the union, as opposed to create Case-suffixed
wrappers. Additionally, when a union is annotated with @adt, the intersection of mixin shapes that are applied to every member of the union is now used as Scala-level mixin traits. This facilitates object-oriented usage of Smithy4s.

Read the new docs for more info.

See #787

Scaladoc now gets generated

Smithy @documentation traits (which has syntactic sugar in the form of triple-slashes-prefixed comments) is now used to generate Scaladoc above the relevant data-types, interfaces and methods that get generated in Smithy4s.

#731

Thank you @zetashift for this awesome contribution and @msosnicki for this valuable contribution !

Scala 3 wildcards now get generated when relevant.

Under conditions which should automatically be propagated from the build-tool to the code-generation,
Scala 3 wildcards now get generated instead of Scala 2 wildcards. This makes user experience better on
Scala 3, as syntax deprecation warnings will no longer be issued.

Thank you @albertpchen for this awesome contribution !

See #736

Simpler AWS clients

It is now possible to directly instantiate AWS clients against a Monadic context, which makes for a better
UX when calling unary request/response operations. When using that mode, stream operations being called
such clients will fail with a raised exception.

See #744

AWS config file credentials providers

It is now possible to load credentials from an AWS-compliant configuration file (typically found under ~/.aws/credentials).
This is wired by default in the clients, and has lower precedence than the other providers.

Improve docs

We've improved and added new sections to the documentation, in particular around AWS SDK usage and model pre-processing.

Bug fixes

Null default value traits are now correctly handled

The default trait allows for not setting a value. Now, the absence of value (ie null) in the
default trait at the smithy level translates to the correct "zero" value of the target type.

See #782

Decoding Document.DNull to Optional fields now works correctly

Null documents were not being decoded as None, but rather were leading to decoding failures
when decoding data types from smithy4s.Document

See #725

Fix the JS source-map URI

The URI was previously using the wrong relative path

See #740

Traits applied on collection members now leads to hints being correctly generated

See #769

Defaults are not ignored in refinements

Loading a smithy 1.0 model with smithy 2.0 tooling (which Smithy4s uses) leads to the automatic
addition of "default" traits on some shapes and members. When combined with refinements, this had
the side effect of treating the refined type as required when it should be in fact optional.
It's all the more confusing that there is no mechanism in place to reconcile refinement logic,
with default values, as refinement logic is expressed in run-time code whereas default value validation
is expressed in build-time code.

See #795

Other notable changes

Performance improvements of the json parsing logic

Yet another awesome contribution from @plokhotnyuk to shave allocations off the Json parsing logic, leading
to performance improvements.

See #764

Compliance tests

Our implementation of our alloy#simpleRestJson protocol is now derived automatically from test specifications
written in Smithy itself

See:

This also paves the road for testing our implementation of the AWS protocols using official tests, which are located
[there]

Generic logic against smithy4s-generated enumerations is now easier to write

Some tweaks were made to the smithy4s.Enumeration.Value interface to allow for more generic logic using enumerations.

See #794

PR List

Read more

Contributors

cb372, etspaceman, and 12 other contributors
Assets 2
Loading

v0.17.2 : errors as scala3 unions, js sourcemaps

10 Jan 11:57
@Baccata Baccata
v0.17.2
2961b9c
Compare
Choose a tag to compare
v0.17.2 : errors as scala3 unions, js sourcemaps

0.17.2

This release is backward binary-compatible with the previous releases from the the 0.17.x lineage.

User-facing features

Scala 3 unions support for operation errors

See #707

In order to render Operation errors as Scala 3 union types, a following metadata flag needs to be added: metadata smithy4sErrorsAsScala3Unions = true (in any of the smithy files that are used for code generation).

Source-mapping github paths are now automatically added during scala-js compilation

This will make it easier to run front-end debuggers on webpage build with smithy4s-issued clients

See #706

Addition of Transformation.apply utilty method :

it's now possible to invoke transformations more conveniently in polymorhic code, via a method in the Transformation companion object

See #681

Bug fixes

Static query params are now handled correctly

It is now possible to define static query parameters when using the http trait :

@http(method: "GET", uri: "/foo?bar=baz)
operation Foo {}

Service interfaces now receive the set of all operations tied to resources transitively tied to the service

For instance, when running the code-generator, the Library interface will now receive a getBook method, which
wasn't previously the case

service Library {
  resources: [Book]
}

resource Book {
  read: GetBook
}

@readonly
operation GetBook {
}

New

New Contributors

Full Changelog: v0.17.1...v0.17.2

Contributors

kubukoz, zetashift, and 6 other contributors
Assets 2
Loading

v0.17.1 : dependency fetching bugfix

13 Dec 13:35
@Baccata Baccata
v0.17.1
af8aff1
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.17.1 : dependency fetching bugfix
  • Fixes a bug that would lead the SBT resolver to try and fetch dependencies with the wrong binary version of Scala. See #672
  • Fixes a bug in the compliance test module when tests would fail because json object would exhibit different key ordering. See #664
  • Adds a pprint dependency to the compliance test module in order to make value mismatches clearer. See #663

What's Changed

Full Changelog: v0.17.0...v0.17.1

Contributors

yisraelU, Baccata, and scala-steward
Assets 2
Loading

v0.17.0 : move of `smithy4s.api` shapes to `alloy` (and much more)

05 Dec 15:39
@Baccata Baccata
v0.17.0
cea113c
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.17.0 : move of `smithy4s.api` shapes to `alloy` (and much more)

0.17.0

A word of warning

This Release is breaking on many levels and is therefore NOT compatible with the previous releases in any way : specifications / Scala sourcecode / binary code.

The most user-facing breakage is the move of smithy4s.api smithy namespace to alloy, as we've moved our definitions to a Scala-agnostic location. In theory, a project-wide string replacement of smithy4s.api to alloy should do the trick.

Read below for more information.

Abstract

This 0.17.0 release of Smithy4s brings a number of improvements on the abstractions implemented by the generated code, in particular in terms of flexibility and user experience.

This release also aims at bringing inter-operability with other tools and projects that Disney Streaming is putting forward to reinforce the Smithy ecosystem, such as smithy-translate and alloy.

In order to achieve these improvements, we've had to break a number of things at different levels. This release is therefore neither source nor binary compatible with the previous ones, and also forces the user to update their Smithy specifications.

Breaking changes

Smithy-level breaking changes

See #561

The Smithy shapes that were previously residing under smithy4s.api namespace have moved to the alloy namespace. Alloy is a standalone library containing Smithy shapes and validators, defined here.

The reason for us to bring this change is to have a language specific location to define shapes that are relevant to the protocols/runtime-behaviours we're putting forward, that could be used by tooling working with other languages than Scala. It was important for us to lose the 4s suffix, which is short for for Scala.

This change implies, for instance, that any use of smithy4s.api#simpleRestJson in your specification will have to be replaced by alloy#simpleRestJson.

Note that this change, in use cases that follow our documentation, should have no visible effect in the Scala code.

Build-plugins breaking changes (SBT/mill)

Multiple input directories

See #587

The smithy4sInputDir setting/task in SBT/mill has been replaced by smithy4sInputDirs, allowing the user to set several directories where the plugins should look for Smithy files.

Change in smithy-library dependency resolution

See #607

We've changed the smithy-sharing mechanism to do two things:

  1. By default, any dependency declared "normally" in SBT or mill, by means or libraryDepedencies ++= or def ivyDeps, will be inspected for Smithy files after being resolved. This means that, for instance, if your application has a runtime dependency on a library that was built with Smithy4s and contains Smithy files, your local specs can use the code defined in these Smithy files to create or annotate new shapes. You no longer need to declare those using % Smithy4s or def smithy4sIvyDeps: these are now reserved for libraries containing Smithy files that you do not want your application's runtime to depend on.
  2. Libraries built by Smithy4s automatically track the dependencies that they used during their own code-generation, by storing some metadata in their Jar's manifests. By default, the Smithy4s plugins will also pull those dependencies (which will have been declared upstream using % Smithy4s in SBT or def smithy4sIvyDeps in mill), for your project's code generation. This facilitates the transitivity of specification-holding artifacts. This mechanism is used, for instance, to communicate to users projects the fact that Smithy4s depends on shapes that are defined in the alloy library, and that these shapes should be made available to user projects, without impacting the user's application runtime, and without requiring any setup from the user.

Normal-usage breaking changes in the generated code

See #599

Depending on your setup, it may be a breaking change, but @deprecated Smithy-traits now translate to the @deprectated Scala annotation in the generated code. For instance, if you used @enum heavily, you'll probably deprecation warnings in your console when compiling. Depending on your scalacOptions, it is possible that these warnings turn into errors. If you want to silence these particular errors while upgrading, you can do the following:

scalacOptions ++= Seq(
  "-Wconf:msg=object Enum in package api is deprecated:silent",
  "-Wconf:msg=type Enum in package api is deprecated:silent",
  // for Scala 3
  "-Wconf:msg=object Enum in package smithy.api is deprecated:silent",
  "-Wconf:msg=type Enum in package smithy.api is deprecated:silent"
)

Normal-usage source breaking changes

See #569

If you use Smithy4s in the ways that were previously advertised in the documentation, you may have to perform some small adjustments.

In particular, the simpleRestJson extension method that was added to implementations of service-interfaces generated by Smithy4s is now removed, in favour of the SimpleRestJsonBuilder construct (which now works for any service Smithy shape that will have been annotated with alloy#simpleRestJson).

Additionally, some methods that were deprecated in 0.16.x releases have been removed.

Advanced usage breaking changes

The abstractions that the generated code implements and that the runtime interpreters use have undergone some massive changes.

Non-exhaustive list of symbol renames :

old new
smithy4s.Monadic smithy4s.kinds.FunctorAlgebra
smithy4s.Interpreter smithy4s.kinds.FunctorInterpreter
smithy4s.Service#asTransformation toPolyFunction
smithy4s.Service#transform fromPolyFunction
smithy4s.PolyFunction smithy4s.kinds.PolyFunction
smithy4s.Transformation smithy4s.kinds.PolyFunction5
smithy4s.GenLift[F]#λ smithy4s.kinds.Kind1[F]#toKind5

Unification of the natural-transformations/polymorphic functions.

  • Smithy4s makes a lot of use of polymorphic functions of various kinds. Those are now code-generated (see the project/Boilerplate.scala file) to ensure the consistency of the various ways they are being used. This means that smithy4s.PolyFunction has moved to smithy4s.kinds.PolyFunction, and that the previous smithy4s.Transformation is now smithy4s.kinds.PolyFunction5. This decision ripples in the smithy4s.Service interface, which now sports toPolyFunction and fromPolyFunction methods, allowing to turn a finally-encoded implementation into a final one. smithy4s.kinds.PolyFunction2 is also a thing, and may be used in bi-functor contexts.
  • kind-specific types were created to facilitate the "lift" of constructs to the right kinds. For instance, when inspecting the internals of this library, you might see things like Kind1[IO]#toKind5 where it was previously GenLift[IO]#λ. We're hoping to convey meaning better, although this code is definitely still not trivial (and never will).
  • smithy4s.Transformation is now a typeclass-like construct, which expresses the fact that a construct can be applied like a function. This construct is used by the transform method that is generated on service interfaces, which allows to apply custom behaviour generically on all method invocations in these interfaces.
  • The Service interface takes a single Alg type parameter, the Op parameter has moved to type-member position, facilitating implicit search in some contexts (as well as the writing of some logic).
  • A bunch of path-dependent type aliases were created in the Service interface.
  • The compliancetest module has changed drastically in UX. For those not aware, this module allows to run tests written in Smithy against your own implementation of protocols. This will be useful for third-party libraries that implement simpleRestJson (or any other http/rest like protocol), to virtually get tests for free. We don't think this module had any users so far, but we'll slowly be porting some of our tests away from the smithy4s repository and into the alloy repository.

User facing improvements

Stubs

See #595

It is now possible to quickly stub a service with a default value (IO.stub being a good candidate), which can be helpful for testing purposes. The resulting code looks like this :

import smithy4s.hello._
import cats.effect._
val stubbedHelloWorld : HelloWorldService[IO] = new HelloWorldService.Default[IO](IO.stub)

Transformations, including bi-functors

See #584

smithy4s.Transformation has been revised to facilitate the integration with various shapes of transformations. It allows, in particular, to transform a service implementation by applying generic (but polymorphic) behaviour in all of its methods. For instance, this can be used to apply a timeout on all of the methods of a service, or retrying behaviour, etc ...

In particular, the smithy4s.Transformation companion object contains in particular AbsorbError and SurfaceError interfaces that developers can leverage to get their services to go from mon...

Read more

Contributors

kubukoz, yisraelU, and 4 other contributors
Assets 2
Loading

v0.16.10

23 Nov 20:29
@kubukoz kubukoz
v0.16.10
b364720
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.16.10

Allow credentials in coursier Fetch in the model loader in #632

Updates the internal dependency resolution mechanism to allow for Coursier credentials to be used in the smithy4s-codegen CLI.

Full Changelog: v0.16.9...v0.16.10

Assets 2
Loading

v0.16.9

22 Nov 20:52
@kubukoz kubukoz
v0.16.9
b078966
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.16.9

This release includes a fix for a regression in the http4s server interpreter, as well as a couple library version updates.

Catch metadata errors in operations without an Errorable in #622

What's Changed

Full Changelog: v0.16.8...v0.16.9

Contributors

kubukoz, yisraelU, and scala-steward
Assets 2
Loading

v0.16.8

10 Nov 18:48
@kubukoz kubukoz
v0.16.8
fb6c2e3
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.16.8

User-facing changes

Catch PayloadErrors in complete decoding in CodecAPI by @kubukoz in #596

Fixes a bug in which decoding failures in CodecAPI would sometimes be thrown instead of returned in an Either.

Other changes

Full Changelog: v0.16.7...v0.16.8

Contributors

kubukoz, lewisjkl, and scala-steward
Assets 2
Loading