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
(feat): introduce custom runtime aspect class for nodejs #29998
base: main
Are you sure you want to change the base?
Conversation
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
public visit(construct: IConstruct): void { | ||
|
||
//To handle custom providers | ||
if (construct instanceof cdk.CustomResourceProviderBase) { |
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 don't think we need to check for instances of CustomResourceProviderBase
, Provider
, or ReceptRule
. At their core these are all the same construct: CfnResource
of type AWS::Lambda::Function
. This should be all we need to look for.
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 is more to the point that we want to update it only for 'CustomResources' and not for all lambda functions which i think we can cover with CfnResource
of type AWS::Lambda::Function
, but this is more suitable for the use case of customResources
only
abstract class RuntimeAspectsBase implements IAspect { | ||
|
||
/** | ||
* The string key for the runtime |
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 isn't descriptive of what targetRuntime
is. How about something like, "The runtime that the aspect will target for updates while walking the construct tree."
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.
Also why is this public? This seems like an implementation detail.
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.
yeah, these strings was to pass initial lints, have more formatted version and correct typing in latest commit.
/** | ||
* RuntimeAspect | ||
*/ | ||
export class RuntimeAspect extends RuntimeAspectsBase { |
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 really want to expose this? Additionally, if I'm using this I'm not clear what key
is. Also, string
is extremely loose. I could pass anything as a string. It seems like we should be building an enum-like class on RuntimeAspect
which is extensible. Introducing NodeJsAspect
means we would need a new class for every single runtime. I realize we may never introduce new runtimes, but we should make this extensible. How about something like this:
export class RuntimeAspect extends RuntimeAspectsBase {
public static nodeJs20() {
// return class implementation
}
}
This may be better to put everything on RuntimeAspectsBase
though since we would just be returning the implementation and another class is probably extra unnecessary code.
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.
updated in latest commit for your review
} | ||
|
||
export class NodeJsAspect { | ||
public static modifyRuntimeTo(key: lambda.Runtime) { |
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.
See my above comment. I think a better user experience here is to do all the construction for them. We can expose options like nodeJs20
and then we can to all the construction like passing the associated Runtime
for the user. This also prevents the user from breaking themselves, like passing node 16 which would be breaking since it only comes with SDK v2.
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.
yes, was trying with implementation earlier too but it was not reflecting the updated nodejs version in template this way, gave it a second attempt and it seems to be working now updated in latest commit.
The pull request linter fails with the following errors:
PRs must pass status checks before we can provide a meaningful review. If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Issue # (if applicable)
Closes #.
Reason for this change
Description of changes
Introduce custom aspect class
Description of how you validated changes
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license