chore(release): 1.3.2

.gitignore

@@ -8,3 +8,4 @@ dist/
 .vscode
 *.tsbuildinfo
 *.tabl.json
+*.swp

CHANGELOG.md

@@ -2,6 +2,13 @@
 
 All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.
 
+## [1.3.2](https://github.com/aws/jsii/compare/v1.3.1...v1.3.2) (2020-04-20)
+
+
+### Bug Fixes
+
+* **python:** incorrect dependency on jsii ([#1582](https://github.com/aws/jsii/issues/1582)) ([c537bd7](https://github.com/aws/jsii/commit/c537bd7e700004b5a66124c1970f4fb540a427d6)), closes [#1573](https://github.com/aws/jsii/issues/1573)
+
 ## [1.3.1](https://github.com/aws/jsii/compare/v1.3.0...v1.3.1) (2020-04-18)
 
 

docs/assembly.md

@@ -78,7 +78,7 @@ classes. *Interface* names must be prefixed with an `I` (e.g: `IFoo`).
 
 Attribute    | Type        | Description
 -------------|-------------|----------------------------------------------------
-`kind`       |`'inteface'` |Discriminator to identify interfaces
+`kind`       |`'interface'`|Discriminator to identify interfaces
 `assembly`   |`string`     |The name of the assembly this interface is a part of
 `fqn`        |`string`     |The fully-qualified name of the interface
 `interfaces` |`string[]`   |The fully-qualified names of interfaces extended by this inteface
@@ -146,7 +146,7 @@ Attribute    | Type         | Description
 Attribute    | Type          | Description
 -------------|---------------|--------------------------------------------------
 `abstract`   |`boolean`      |Whether this method is `abstract`
-`async`      |`boolean`      |Whether this method is asyncrhonous
+`async`      |`boolean`      |Whether this method is asynchronous
 `name`       |`string`       |The name of the method
 `overrides`  |`string`       |The fully-qualified name of the class/interface that declares the overridden method
 `parameters` |`Parameter[]`  |Parameters of this method
@@ -168,7 +168,7 @@ Attribute    | Type          | Description
 -------------|---------------|--------------------------------------------------
 `abstract`   |`boolean`      |Whether this property is `abstract`
 `const`      |`boolean`      |Whether this property is a constant (implies `static` and `immutable`)
-`immutable`  |`boolean`      |Whethert his property is immutable
+`immutable`  |`boolean`      |Whether this property is immutable
 `name`       |`string`       |The name of the property
 `optional`   |`boolean`      |Whether this property is optional
 `overrides`  |`string`       |The fully-qualified name of the class/interface that declares the overridden property

docs/configuration.md

@@ -1,6 +1,6 @@
 # Configuration
 
-The configuration for `jsii` is recoded in the `package.json` file, which is
+The configuration for `jsii` is recorded in the `package.json` file, which is
 the standard package manifest for NPM packages. This document describes the
 constraints and extensions `jsii` adds to the [package.json schema].
 
@@ -301,7 +301,7 @@ the [`dependencies`][npm-reps] section of `package.json`.
 
 ### Dependencies that are `jsii` modules
 
-Node modules are conventionally versionned using [semantic versioning], but that
+Node modules are conventionally versioned using [semantic versioning], but that
 is not true of all package managers that `jsii` is able to target. Additionally,
 only one version of the `jsii` runtime and kernel can be used within a given
 application. In order to avoid version resolution surprises at run-time, `jsii`

docs/handbooks/language-implementation.md

@@ -70,7 +70,7 @@ to track learnings accumulated through the implementation process, as those will
 be tracked as comments or iterations on the RFC document.
 
 It is possible (and sometimes desirable) to start prototyping code-generation
-for the new language, as this can hlighlight implementation challenges that need
+for the new language, as this can highlight implementation challenges that need
 to be discussed in the RFC document. In any case, examples of the API signatures
 that are expected to be rendered allow early feedback to be provided by possible
 future users, and still helps identify challenges.
@@ -105,21 +105,21 @@ to avoid surprises later on that result in significant re-engineering effort:
 ## Code Generation
 
 First, implement a first version of the code generation for the new language
-before getting to far into the *[host library](#host-library)* implementation.
+before getting too far into the *[host library](#host-library)* implementation.
 This top-down approach ensures the requirements for the lower level parts of
-the implementation are well defined before they're implemented (reducing the
-chances significant re-work has to be done), and enables using the [Standard
+the implementation are well-defined before they are implemented (reducing the
+chances that significant re-work has to be done), and enables using the [Standard
 Compliance Suite] to ensure the overall implementation is *correct* according
 to the [specification] (since the code necessary to implement the test cases
 will be available right from the start).
 
 This work happens within the [`jsii-pacmak`] package.
 
 Focus initially on the API signatures before getting into their implementation.
-The first version may even thrw a *not implemented* exception when called.
+The first version may even throw a *not implemented* exception when called.
 
 The [`jsii-calc`] package, can be used as a sample consuming library which uses
-*jsii* to generate code in all traget languages. Start by making sure a decent
+*jsii* to generate code in all target languages. Start by making sure a decent
 API is generated from this package and its dependencies, and use those to
 implement the tests from the [Standard Compliance Suite]. You'll also get a
 feeling for whether the generated code achieves a good developer experience or
@@ -129,7 +129,7 @@ not.
 
 Now that we are generating "empty shell" APIs that represent the necessary
 entities to back the [Standard Compliance Suite] tests, start implementing the
-*host library* and update the code generator until all the tests pass. It's
+*host library* and update the code generator until all the tests pass. It is
 possible to publish artifacts even when tests in the suite are failing. As soon
 as basic features are working, work on [Building and
 Packaging](#building-and-packaging) can start, so early feedback can be
@@ -138,7 +138,7 @@ gathered.
 > :construction: A standard architecture for the *host library* has not been
 > documented yet. Upcoming language implementations should contribute to this
 > process by documenting a general architecture that should be implementable
-> in any programming languages (and thus, asbtracting away language
+> in any programming languages (and thus, abstracting away language
 > specificities).
 
 ## Building & Packaging
@@ -194,21 +194,21 @@ with varied degrees of experience with the new language.
 
 ## General Availability
 
-Once the new language has been in *Developer Preview* wihout any significant
-usability issue or bug for long enough, and is used in real-world use-cases such
-as for [AWS CDK] applications, it becomes candidate to be declared *Generally
-Available*. At this point, breaking changes are no longer possible on the
-generated code.
+Once the new language has been in *Developer Preview* without any significant
+usability issues or bugs for a sufficient amount of time and is used in
+real-world use-cases such as for [AWS CDK] applications, it becomes a candidate
+to be declared *Generally Available*. At this point, breaking changes are no
+longer possible on the generated code.
 
 <!-- ######################### External References ######################### -->
 [jsii type system]: ../specifications/2-type-system.md
 [specification]: ../specifications/1-introduction.md
-[New Language Intake]: ../specification/5-new-language-intake.md
+[New Language Intake]: ../specifications/5-new-language-intake.md
 [CDK RFC repository]: https://github.com/awslabs/aws-cdk-rfcs#readme
 [`jsii`]: ../../packages/jsii
 [`jsii-calc`]: ../../packages/jsii-calc
 [`jsii-config`]: ../../packages/jsii-config
-[`jsii-pacmak`]: ../../packgages/jsii-pacmak
+[`jsii-pacmak`]: ../../packages/jsii-pacmak
 [`jsii-rosetta`]: ../../packages/jsii-rosetta
 [Standard Compliance Suite]: ../specifications/4-standard-compliance-suite.md
 [`jsii/superchain`]: ../../superchain

docs/runtime-architecture.md

@@ -9,7 +9,7 @@ needs to be available in order to execute code that depends on *jsii* libraries.
 The generated libraries have a dependency on a *Runtime client* library for the
 language, which contains the necessary logic to start a child `node` process
 with the `jsii-runtime`. The `jsii-runtime` manages JSON-based inter-process
-communication over it's `STDIN` and `STDOUT`, and manages a `@jsii/kernel`
+communication over its `STDIN` and `STDOUT`, and manages a `@jsii/kernel`
 instance that acts as a container for the **Javascript** code that backs the
 *jsii* libraries.
 

docs/specifications/1-introduction.md

@@ -1,6 +1,6 @@
 # Introduction
 
-This document provides a high level overview of *jsii*, starting with it's
+This document provides a high level overview of *jsii*, starting with its
 design tenets. It introduces the concepts and components that compose *jsii*.
 
 
@@ -40,9 +40,9 @@ that is proposed:
   followed when introducing changes to the behavior of any component of *jsii*:
   new features, breaking changes to existing features, ...
 - [:mag: Addressing Gaps](#addressing-gaps) is the process used for adding
-  specification around existing but un-specified behavior.
+  specification around existing but unspecified behavior.
 - [:thumbsup: Trivial Changes](#trivial) explains how to propose changes that
-  improve the specification without changing it's meaning.
+  improve the specification without changing its meaning.
 
 #### <a id="new-behavior"/> :warning: Changing Behavior
 
@@ -77,8 +77,8 @@ the proposal (including alternatives considered, risks, ...).
 
 #### <a id="addressing-gaps"/> :mag: Addressing Gaps
 
-Proposal that increase the specification's coverage (desribing behavior that
-already exists) are handled as GitHub pull request that must contain the
+Proposals that increase the specification's coverage (desribing behavior that
+already exists) are handled as GitHub pull requests that must contain the
 following elements:
 
 - Relevant additions to the specification documents

docs/specifications/2-type-system.md

@@ -50,7 +50,7 @@ produced each time it is passed through the process boundary.
 
 ### Enum
 As in many languages, `enum` can be used to represent a group of related
-constants. Whle **TypeScript** `enum` entries are associated with a value that
+constants. While **TypeScript** `enum` entries are associated with a value that
 is either a `string` or a `number`, the *jsii* type system does not allow for
 those to be down-casted to their value type (e.g: a `string`-valued `enum` entry
 cannot be directly passed into a `string` parameter).
@@ -89,7 +89,7 @@ consequently considers `null` and `undefined` are semantically equivalent.
 
 ### Object
 **TypeScript**'s `object` type denotes anything that is not a *primitive* type,
-meaning anything other than a `number`, `srting`, `boolean`, `biging`, `symbol`,
+meaning anything other than a `number`, `string`, `boolean`, `bigint`, `symbol`,
 `null` or `undefined`.
 
 In the *jsii* type model, `object` indicates a block of structured data that can
@@ -119,9 +119,9 @@ the *jsii* type model does not support the following **TypeScript** entities:
 
 
 ## Complex Types
-The goal of *jsii* is to enable cross-language re-use of class libraries.
-**TypeScript** enables representing classic object-oriented concepts such as
-*classes*, *interfaces* and such. The *jsii* type system supports some
+The goal of the *jsii* is to enable cross-language re-use of class libraries.
+**TypeScript** enables representing classic object-oriented concepts, such as
+*classes* and *interfaces*. The *jsii* type system supports some
 additional nuances on top of those, to better represent **TypeScript** and
 **JavaScript** idioms in a way that enables generating convenient APIs in other
 languages.
@@ -172,10 +172,10 @@ example, in **Java**, those are returned as `java.lang.Object`).
 
 When used as inputs (parameters, or properties of a *struct*), it may be
 possible to generate method overloads that will allow for a convenient API in
-languages that support overloards.
+languages that support overloads.
 
 In general however, *type unions* are discouraged and should only be used when
-there is no alternate way to model the API.
+there is no alternative way to model the API.
 
 
 ## Serialization Behavior
@@ -275,7 +275,7 @@ element type of the mapping, combined with the dynamic type of the value itself:
 [Reference]: #reference-serialization
 
 Objects serialized by reference are passed using a special object that provides
-sufficient information to tie back to the instance within it's owning process.
+sufficient information to tie back to the instance within its owning process.
 It includes a `$jsii.byref` key associated with a string that uniquely
 identifies the instance, and an optional `$jsii.interfaces` key that provides a
 list of interfaces that the object implements.

docs/specifications/3-kernel-api.md

@@ -1,6 +1,6 @@
 # The *jsii* kernel API
 This document describes the API for the `@jsii/kernel` module, which is to be
-used by all *host* libraries. It provides the fundational features necesarry for
+used by all *host* libraries. It provides the fundamental features necessary for
 *host* processes to interact with the original module's code.
 
 > :construction: Currently, `@jsii/kernel` contains the bulk of the logic,
@@ -283,7 +283,7 @@ execute code that is defined in the *host* app, when the code path traverses a
 method or property that was implemented or overridden in the *host* app.
 
 Such cases will result in a callback request substituting itself to the response
-of the original call being made; execution fo which will resume once the
+of the original call being made; execution of which will resume once the
 callback response is provided.
 
 A callback request is sent from the `@jsii/kernel`'s `node` process to the
@@ -330,7 +330,7 @@ methods - including delegating to the `super` implementation, ...). Such calls
 will behave as they otherwise would (including the possible introduction of
 further callback requests).
 
-Once the *host* happ has fulfilled the request, it must signal the result of
+Once the *host* app has fulfilled the request, it must signal the result of
 that execution back to the `@jsii/kernel` process by using the `complete` call:
 
 ```ts
@@ -348,7 +348,7 @@ interface CallbackSuccess extends CompleteBase {
 }
 
 interface CallbackFailure extends CompleteBase {
-  /** The error that was raised during fulfilling */
+  /** The error that was raised during fulfillment */
   err: string;
 }
 
@@ -382,7 +382,7 @@ interface CallbacksResponse {
 Once the *host* app no longer needs a particular object, it can be discarded.
 This can happen for example when the *host* reference to an object is garbage
 collected or freed. In order to allow the **JavaScript** process to also
-recclaim the associated memory footprint, the `del` API must be used:
+reclaim the associated memory footprint, the `del` API must be used:
 
 ```ts
 interface DelRequest {
@@ -395,7 +395,7 @@ interface DelRequest {
 ```
 
 > **:warning:** Failure to use the `del` API will result in memory leakage as
-> the **JavaScript** process accumulates garbage in it's Kernel instance. This
+> the **JavaScript** process accumulates garbage in its Kernel instance. This
 > can eventually result in a *Javascript heap out of memory* error, and the
 > abnormal termination of the `node` process, and consequently of the *host* app.
 
@@ -458,22 +458,22 @@ Both the `invoke` and `sinvoke` calls result in the same response:
 
 ```ts
 interface InvokeResponse {
-  /** The result of the method invokation. */
+  /** The result of the method invocation. */
   result: any;
 }
 ```
 
-When the method's return type is `void`, the `result` value should typicaly be
-`undefined`, however it may not be (**TypeScript** may in certain circumstances
+When the method's return type is `void`, the `result` value should typically be
+`undefined`, however it may not be ?? (**TypeScript** may in certain circumstances
 allow returning a value from a `void` method): the *host* app should ignore such
 values.
 
 #### Asynchronous method invocation
 The `invoke` call can only be used to invoke *synchronous* methods. In order to
 invoke *asynchronous* methods, the `begin` and `end` calls must be used instead.
-Once the *host* app has entered an asynchronous workflow (after it made the
+Once the *host* app has entered an asynchronous workflow (after it makes the
 first `begin` call), and until it has completed all asynchronous operations
-(after all `begin` calss were matched with an `end` call), no *synchronous*
+(after all `begin` class are matched with an `end` call), no *synchronous*
 operation (including synchronous callbacks) may be initiated.
 
 ```ts

docs/specifications/4-standard-compliance-suite.md

@@ -33,9 +33,9 @@ end of the document, or whenever another `H2` title is reached.
 ### Test Case
 Within a category title, test cases are delimited by `H4` (`#### `) titles,
 which correspond to the test case name. The test case name should be kept
-concise (dieally within 75 characters) and try to be as descriptive as possible.
+concise (ideally within 75 characters) and try to be as descriptive as possible.
 
-Immediately after the `H4` title is an english language description of the test
+Immediately after the `H4` title is an English language description of the test
 case that explains the property the test is designed to validate in as much
 detail as possible. As much as possible, test case descriptions should be
 self-sufficient.
@@ -59,10 +59,10 @@ exchanged between the *host* and `node` processes during the execution of the
 test case, such that implementations can assert coherent behavior.
 
 Initial messages corresponding to the `hello` and `load` calls can be omitted at
-the beginning of the kernel trace. Those messages are typically identicall
-across tests and there is little value in asserting around those. Any `load`
+the beginning of the kernel trace. Those messages are typically identical
+across tests and there is little value in asserting around those. However, any `load`
 call happening after the first call that is neither the `hello` message or
-another `load` call **must** however be included.
+another `load` call **must** be included.
 
 The dialogue is the sequence of JSON formatted messages, from the perspective of
 the *host* app, using the following notation:
@@ -82,7 +82,7 @@ the *host* app, using the following notation:
 * Blank lines can be added to logically group trace elements
 
 > :question: is there a need to support some form of a capture mechanism to
-> provision for non-deterministric results, or non-normative elements such as
+> provision for non-deterministic results, or non-normative elements such as
 > the exact Object IDs issued for created instances?
 
 <details><summary>Show Template</summary>
@@ -136,7 +136,7 @@ following schema:
 interface TestReport {
   /** The report is broken down by test category, using the name as-is */
   [category: string]: {
-    /** For each test in the category, using it's name as-is */
+    /** For each test in the category, using its name as-is */
     [test: string]: {
       /** Whether the test passed or failed */
       status: 'PASS' | 'FAIL';