chore(cdk): init templates are major-version aware #11665
Conversation
In preparation of non-trivial differences in the init templates between v1 and v2 (see #11638), moving all of the existing init templates to a /v1 subdirectory and making the init library major-version aware. Note: This change only concerns the v1 changes. The v2 init templates are already broken, and I will adapt #11638 once this has been merged (and forward- merged).
|
|
| */ | ||
| function mockVersionNumber() { | ||
| // eslint-disable-next-line @typescript-eslint/no-require-imports | ||
| const releaseJson = require(`${__dirname}/../../../release.json`); |
There was a problem hiding this comment.
Note - I don't love this. I'm totally open to better ways to get the correct major version for the branch (if such a thing exists).
There was a problem hiding this comment.
can we instead run the tests for both v1 and v2? (maybe update cliTest so that there's no test case duplication?)
skimming through the tests, it seems it's just checking that specific files get created. I'm assuming it doesn't try to install dependencies, but maybe I'm wrong.
There was a problem hiding this comment.
can we instead run the tests for both v1 and v2?
I don't think this makes sense. v1 (master/this change) obviously can't run the v2 templates. We can add tests to ensure the v2 CLI can instantiate the v1 templates, but I'm not sure what value that provides, exactly.
I'm assuming it doesn't try to install dependencies, but maybe I'm wrong.
These tests do run npm install after initializing the template to prove the template is valid.
| */ | ||
| function mockVersionNumber() { | ||
| // eslint-disable-next-line @typescript-eslint/no-require-imports | ||
| const releaseJson = require(`${__dirname}/../../../release.json`); |
There was a problem hiding this comment.
can we instead run the tests for both v1 and v2? (maybe update cliTest so that there's no test case duplication?)
skimming through the tests, it seems it's just checking that specific files get created. I'm assuming it doesn't try to install dependencies, but maybe I'm wrong.
nija-at
changed the title
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
|
Thank you for contributing! Your pull request will be updated from master 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 |
I foolishly changed some of the ordering of .npmignore as part of #11665 to logically group similar components together, without taking into account the fact that ordering in .npmignore is *important*. Fix the ordering to fix the pipeline. Tested via: * Diffing the contents of `pack` between a recent release and what's generated here. * Running `package/test/integ/run-against-dist package/test/integ/init/test-typescript.sh`
I foolishly changed some of the ordering of .npmignore as part of #11665 to logically group similar components together, without taking into account the fact that ordering in .npmignore is *important*. Fix the ordering to fix the pipeline. Tested via: * Diffing the contents of `pack` between a recent release and what's generated here. * Running `package/test/integ/run-against-dist package/test/integ/init/test-typescript.sh` ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ource As part of the CDKv2 work, #11665 made the init templates version-aware (allowing for different init templates for v1 and v2). This works when the CLI \is run from a packaged distribution, but when run locally in development -- for example, when running `cdk-integ` -- the CLI was failing due to the local version being 0.0.0, and the templates looking for a "v0" directory. Fix the local experience by (currently) defaulting to v1 templates for local development.
…ource (#11731) As part of the CDKv2 work, #11665 made the init templates version-aware (allowing for different init templates for v1 and v2). This works when the CLI \is run from a packaged distribution, but when run locally in development -- for example, when running `cdk-integ` -- the CLI was failing due to the local version being 0.0.0, and the templates looking for a "v0" directory. Fix the local experience by (currently) defaulting to v1 templates for local development. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
In preparation of non-trivial differences in the init templates between v1 and
v2 (see #11638), moving all of the existing init templates to a /v1 subdirectory
and making the init library major-version aware.
Note: This change only concerns the v1 template changes. The v2 init templates are
already broken, and I will adapt #11638 once this has been merged (and forward-
merged).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license