-
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
feat(cli-lib): [JS/TS only] experimental support for programmatic CLI api #22836
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.
4daabfc
to
746c163
Compare
@@ -0,0 +1,237 @@ | |||
import * as core from '@aws-cdk/core'; | |||
import { exec as runCli } from 'aws-cdk/lib'; |
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.
Minimal example to proof this works with the bundled package:
npm install aws-cdk
node -e "const { cli } = require('aws-cdk/lib'); cli()"
cli
is the existing export. I have no reason to believe exec
would behave any different. Any further proof is very tricky within the constraints of the build setup (the bundled version of aws-cdk
is only created at package time and as a tarball).
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.
Additionally confirmed this by taking the produced tarball from our test build pipeline and used it in an app.
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
ba65d15
to
5335dc1
Compare
try { | ||
const templatesDir = path.join(rootDir(), 'lib', 'init-templates'); | ||
const templateNames = await listDirectory(templatesDir); | ||
const templates = new Array<InitTemplate>(); | ||
for (const templateName of templateNames) { | ||
templates.push(await InitTemplate.fromName(templatesDir, templateName)); | ||
} | ||
resolve(templates); | ||
} catch { | ||
resolve([]); |
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 code should not fail if the template directory cannot be found.
### list | ||
|
||
```ts | ||
// await this asynchronous method call using a language feature |
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.
Oops! Missing Rosetta feature here I think
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!
cd999c2
to
47bd963
Compare
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.
Provisionally approved after you consider my questions
* } | ||
* ``` | ||
*/ | ||
produce(context: Record<string, any>): Promise<string> |
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 environment?
If this library is used via jsii, then the process.env.CDK_DEFAULT_ACCOUNt = '1234';
statements will be executed in the Node process, which is separate from the JVM so System.getEnvironment('CDK_DEFAULT_ACCOUNT')
will not find it.
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.
Well that sucks. Now I have to think gain. 😭
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.
Just pass the environment in and let the user deal with it.
/** | ||
* Create the CLI from a CloudAssemblyDirectoryProducer | ||
*/ | ||
public static fromCloudAssemblyDirectoryProducer(producer: ICloudAssemblyDirectoryProducer) { |
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.
Did we drop the fromCloudAssemblyDirectory
constructor on purpose?
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, I think there's no point to it. If someone really wants to do this, they can do a stub producer:
{
produce: async () => '/path/to/assembly/dir'
}
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.
Ya but it looks nicer
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.
But it's pretty useless! We can always add it later if people are asking for it. 🤷🏻♂️
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Experimental wrapper around the existing
aws-cdk
package, which is possible due to minor adjustments in the cli.The API interface is adapted from
cdk-cli-wrapper
. Currently all options are passed as array args to the existing cli args parser function. In future all code fromaws-cdk
should move over here and the dependency between the two would be reversed. When this is done we can start refactoring the internal APIs to be more programmatically usable.What's in a name
Currently aiming for
@aws-cdk/cli-lib
, but any suggestions are welcome.Why is this bundled?
To make the package a jsii library we need to bundle non-jsii dependencies. For now most of the code is still located in the
aws-cdk
package which has a different build pipeline to our other packages, simply including the directory inbundledDependencies
is not an option. While the aim is to eventually have most code in this package, we are not there yet. Until then, bundling is the easiest option.The build setup as configured for this package is needed because
jsii
MUST operate on TypeScript files andjsii-pacmak
MUST be used because this is how the various language packages are created. Therefore bundling must happen after the jsii assembly has been created, but before jsii-pacmak runs.We should not import submodules that are not explicitly exported
Yes, that's right we should not do this and no user land code should do this.
In this situation there are two things that make this "okay":
All Submissions:
Adding new Unconventional Dependencies:
New Features
yarn integ
to deploy the infrastructure and generate the snapshot (i.e.yarn integ
without--dry-run
)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license