feat(core): cdk init --generate-only

[nmussy]

Starting with a draft to get the ball rolling.

I'm not pleased with the yarn detection, maybe we should just stick with --package-manager?

Fixes #4795

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[mergify]

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
merged. In the meantime, please take a minute to make sure you follow this
checklist:

• PR title type(scope): text
  • type: fix, feat, refactor go into CHANGELOG, chore is hidden
  • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
  • text: use all lower-case, do not end with a period, do not include issue refs
• PR Description
  • Rationale: describe rationale of change and approach taken
  • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
  • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
• Testing
  • Unit test added. Prefer to add a new test rather than modify existing tests
  • CLI or init templates change? Re-run/add CLI integration tests
• Documentation
  • README: update module README to describe new features
  • API docs: public APIs must be documented. Copy from official AWS docs when possible
  • Design: for significant features, follow design process

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[eladb]

This feels like it’s taking things a bit too far. We are very careful to add complexity around init templates because the abuse potential is high. My understanding is that given package.json yarn can very easily create a lock file. Do we really need this to be part of the template?

Maybe we can just add to the template a readme instruction on how to use yarn?

[nmussy]

@eladb The issue isn't with using the package.json, or converting the package-lock.json into a yarn.lock.
Using the wrong package manager during the initial installation can cause significant network and disk overhead. They each have their own cache, and both pnpm and yarn (in the future) generate a different, more efficient node_modules.

Another solution might be a --skip-install flag, like ng new has.

[eladb]

--skip-install sounds better. Maybe it should be more general like --generate-only and we can apply this to all other templates (for example, for java we shouldn't run mvn package).

Pull request has been modified.

Pull request has been modified.

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[nmussy]

I realized when testing --project-name that I missed adding generateOnly to the settings:

aws-cdk/packages/aws-cdk/lib/settings.ts

Line 236 in d044461

generateOnly: argv.generateOnly,

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request is now being automatically merged.

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Pull request has been modified.

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository