-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
chore: make examples in aws-ec2
package compilable
#5011
Conversation
Using the new "rosetta" sample compiler from aws/jsii#925, introduce fixtures and fix up sample code to make all examples in the `aws-ec2` package compile. This serves as a demonstration of how to set up fixtures and how to write the examples.
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
And again, this obviously will not compile before we have released and merged the requisite JSII tooling. |
If we don't do this, the '@example' will absorb the non-standard '@Attribute' tag.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
``` | ||
|
||
While processing the examples, the tool will look for a file called | ||
`rosetta/with-bucket.ts-fixture` in the package directory. This file will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps a bit late now but would be better to have used the extension format .ts.fixture
in line with how template files are usually named like .html.erb
, .template.json
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be .fixture.ts
then. I recall not doing that because TSC will want to compile it then, something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hence the suggestion to go .ts.fixture
.
Rationale: The file might not be strictly typescript (or atleast not a complete typescript app). When the fixture is resolved (with the example code), it becomes correct typescript (or fully valid).
Non-blocking.
treated as a regular TypeScript source file, but it must also contain the text | ||
`/// here`, at which point the example will be inserted. The complete file must | ||
compile properly. | ||
|
||
Before the `/// here` marker, the fixture should import the necessary packages | ||
and initialize the required variables. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got a bit lost in the text here, until I saw the ec2 package.
Can we clean up the lang a bit and/or mention the examples in the ec2 packages earlier on?
# Compile examples with respect to "decdk" directory, as all packages will | ||
# be symlinked there so they can all be included. | ||
echo "Extracting code samples" >&2 | ||
node --experimental-worker $(which jsii-rosetta) \ | ||
--compile \ | ||
--output samples.tabl.json \ | ||
--directory packages/decdk \ | ||
$(cat $TMPDIR/jsii.txt) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should ideally be in the build step of each module so that I can see errors on invalid example code. If this happens only in the pack step, I won't know of this until a PR build.
Why not do this in the build step as done in compile samples?
Also, this is technically not 'packing'. If I were to speed up PR builds by removing packing, we would still want this to be present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not do this in the build step as done in compile samples?
Because it's not hermetic. Samples will require everything to have been built and linked into decdk
package.
|
||
# Run rosetta against decdk dir, failing on compilation errors | ||
node --experimental-worker $scriptdir/../node_modules/.bin/jsii-rosetta \ | ||
--directory $scriptdir/../packages/decdk \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Help me understand why we need to run this against decdk and can't be run against the current package's node_modules
? Also, should decdk have been pre-built for this to work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No just linked.
Because otherwise in aws-events
package I cannot write samples that use aws-events-targets
, for example (which I really want to do).
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
2 similar comments
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
@@ -28,4 +28,4 @@ coverage/ | |||
cdk.context.json | |||
.cdk.staging/ | |||
cdk.out/ | |||
|
|||
*.tabl.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want this in pkglint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just going to be created here, not in any subpackage. So not really?
@@ -0,0 +1,13 @@ | |||
// Fixture with packages imported and a VPC created |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't it make more sense to use .fixture.ts
extension so the IDE/github will know this is typescript?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, but the problem is the include paths won't resolve in the location where the files are stored so the IDE will start complaining and showing permanent errors in the Errors
tab.
I've decided against that for now.
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
2 similar comments
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request is now being automatically merged. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request is now being automatically merged. |
Commit Message
chore: make examples in
aws-ec2
package compilableUsing the new "rosetta" sample compiler from aws/jsii#925, introduce
fixtures and fix up sample code to make all examples in the
aws-ec2
package compile.
This serves as a demonstration of how to set up fixtures and how
to write the examples.
Need to reverse the order between
@example
and@attribute
; becauseof a bug in the TypeScript compiler, it will think a new tag starts if
a
@
comes up in the example. This means that we cannot typeimport s3 = require('@aws-cdk/aws-s3');
in examples (it would parse@aws = -cdk/aws-s3');
.To fix that, we absorb non-recognized tags that follow an
@example
back into the example body, but since
@attribute
is non-recognized,we'd absorb that as well. The solution is to have
@example
as the last tag.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license