aws-cdk-lib: exporting a class that implements IVpc but only looks up a vpc by Id
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
### Describe the feature
Having a class that is able to lookup a Vpc by it's Id and implementing `IVpc` so it can be extended with own methods and properties.
### Use Case
Doing `class MyVpc extends Vpc` will try to deploy a new Vpc to aws and that is not intended. I want to be able to extend a class that looks up Vpc by it's id in something like:
```typescript
class MyVpc extends VpcLookup {
constructor(scope: Construct, id: string, props?: VpcLookupOptions) {
super(scope, id, props);
}
get someSubnetGroup() {
this.selectSubnets({
...
})
}
}
```
### Proposed Solution
Maybe it's possible to move `Vpc.fromLookup` code/logic to inside of a seperated class constructor?
### Other Information
Alternative solution would be export [LookedUpVpc](https://github.com/aws/aws-cdk/blob/1f7075f8bd6bd3c1d760cb9e899a7cba52e2993a/packages/aws-cdk-lib/aws-ec2/lib/vpc.ts#L2218)?
### Acknowledgements
- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
### CDK version used
2
### Environment details (OS name and version, etc.)
linux
Contributor guide
Research direction
Start in packages/aws-cdk-lib/aws-ec2/lib/vpc.ts, especially Vpc.fromLookup and the LookedUpVpc implementation linked in the issue. Trace how the lookup result implements IVpc and review related tests before deciding whether exporting that class or introducing a separate extensible class fits the API. Done means consumers can extend a lookup-backed VPC without synthesizing a new VPC.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100