generated from amazon-archives/__template_Apache-2.0
-
Notifications
You must be signed in to change notification settings - Fork 69
refactor(toolkit-lib): move message definitions to shared package #220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `IIoHost` interface has the following method:
```ts
interface IIoHost {
notify<T>(msg: IoMessage<T>): Promise<void>;
}
```
The generic parameter `T` is only used once, without bounds, for a
singleton argument in input position. This means it is equivalent to the
following:
```ts
interface IIoHost {
notify(msg: IoMessage<unknown>): Promise<void>;
}
```
(Preferring `unknown` over `any` so that implementors are forced to
test for the type of the `data` field, just like they would need
to do with an argument of type `T`)
In the words of the [Java generics
tutorial](https://docs.oracle.com/javase/tutorial/extra/generics/methods.html):
> Generic methods allow type parameters to be used to express
> dependencies among the types of one or more arguments to a method and/or
> its return type. If there isn't such a dependency, a generic method
> should not be used.
Or [similar advice for
TypeScript](https://effectivetypescript.com/2020/08/12/generics-golden-rule/):
> Type Parameters Should Appear Twice
>
> Type parameters are for relating the types of multiple values. If a
> type parameter is only used once in the function signature, it's not
> relating anything.
aa9fcc9 to
91cbd22
Compare
91cbd22 to
807f549
Compare
807f549 to
074c32c
Compare
074c32c to
293973f
Compare
auto-merge was automatically disabled
March 10, 2025 19:04
Pull request was closed
293973f to
b5cbf62
Compare
Move message registry to shared package, so that it can be shared between the CLI and the toolkit.
b5cbf62 to
a0d2444
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #220 +/- ##
==========================================
- Coverage 85.16% 84.89% -0.27%
==========================================
Files 208 208
Lines 35657 35564 -93
Branches 4630 4626 -4
==========================================
- Hits 30367 30192 -175
- Misses 5139 5215 +76
- Partials 151 157 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mrgrain
approved these changes
Mar 10, 2025
github-merge-queue bot
pushed a commit
that referenced
this pull request
Mar 18, 2025
(Replaces #188). On CI systems, the CDK CLI tries to avoid writing to `stderr` because there are a couple of CI systems that are commonly configured to fail if any output is written to `stderr`. That means all output, like notices, must go to `stdout`. Some commands (like `cdk synth` or `cdk bootstrap --show-template`) produce usable output on `stdout`, and these are commonly scripted, like piping their output to a file. However, because notices must go to `stdout`, these now interfere with the output of these commands. This needs a more thorough reworking of the CLI output streams, but there is a risk of affecting users who are currently relying on the fact that all output goes to `stdout`. In this PR, we are doing the first steps to solving this situation: - Notices will always go to `stderr`, so that they will never interfere with `stdout` anymore. - We try to detect what CI system we are running on, and we will completely suppress notices *unless* we determine that we are running on a CI system where it is "safe" to write to `sterr` (fail closed). "Safe" in this case means that the CI system doesn't come with an easy to toggle checkbox that makes commands fail based on what they print, instead of their exit codes. The only systems I'm aware of that have this checkbox are "Azure DevOps", and "TeamCity running PowerShell scripts". Even though we know the systems that are "unsafe", we will only show notices on systems known to be "safe". Fixes aws/aws-cdk#33589. Also in this PR, because this grew. * Introduce `IoDefaultMessages` in the CLI package, which helps migrate "legacy" logging code to just emit default warning/info/etc messages to the IoHost. * Removed the ability to log with a `{ message: 'asdf' }` object to the global logger functions. This wasn't being used anywhere other than tests, and it's sort of pointless: if you know the code you should be using the `MessageMaker` to make a message object; if you don't know the code you can emit a string. There is no need to look up the right code given a level and a message object. * Make it possible for result types to be any type, not just object types. This is necessary to cover the "result" from legacy logging, where the result is just a string. * Updated many tests in a test file (`cli-io-host.test.ts`) that failed type checking, but succeeded running, and therefore didn't fail the build of #220. * Centralized `TestIoHost` into the helper package, and renamed it to `MockIoHost`. * Introducing a `FakeIoHost` in the CLI package to assert on messages emitted to an `IoHost`. --- By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license --------- Signed-off-by: github-actions <[email protected]> Co-authored-by: github-actions <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Move the message definitions to the shared package and make them public. This also required moving a bunch of type definitions to the shared package because they are used as payloads for the message types.
In the CLI it's now possible to access those numbers and access their associated payload types in a type-checked way.
A type-safe
switchstatement now looks like this:This change also makes the
datafield of anIoMessagerequired. The type of a message without payload is nowIoMessage<void>:data: voidis only inhabited bydata: undefinedwhich sort of tracks becausem.data === undefinedeven if there is no payload (don't look too closely at the different behavior for'data' in m😎 ). The type can no longer beneverbecause a type like{ data: never }can not be inhabited by any values. We could also usedata: undefined, also only admittingundefined, butvoidreads more clearly for its intent.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license