Skip to content

chore: rewrite imports in READMEs for aws-cdk-lib#14255

Merged
mergify[bot] merged 3 commits intomasterfrom
njlynch/readmerewriteimports
Apr 20, 2021
Merged

chore: rewrite imports in READMEs for aws-cdk-lib#14255
mergify[bot] merged 3 commits intomasterfrom
njlynch/readmerewriteimports

Conversation

@njlynch
Copy link
Copy Markdown
Contributor

@njlynch njlynch commented Apr 19, 2021

For the v2 (aws-cdk-lib) docs, the imports scattered throughout the READMEs need
to be re-written. We could hand-edit all of the READMEs on the v2-main branch,
but this is not an ongoing mechanism and may also introduce forward-merge pain.
Instead, we're going to take the cheap option of rewriting the import statements
as part of ubergen when building the aws-cdk-lib package.

I aimed to capture as many import types as I found in the live READMEs.

As an example, the code transforms these imports as seen below:

// BEFORE
import * as cdk from '@aws-cdk/core';
  import * as cloudfront from '@aws-cdk/aws-cloudfront';
import codeartifact = require('@aws-cdk/aws-codeartifact');
import { VpcEndpointServiceDomainName } from '@aws-cdk/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from '@aws-cdk/core';

// AFTER
import * as cdk from 'aws-cdk-lib';
  import { aws_cloudfront as cloudfront } from 'aws-cdk-lib';
import { aws_codeartifact as codeartifact } from 'aws-cdk-lib';
import { VpcEndpointServiceDomainName } from 'aws-cdk-lib/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from 'aws-cdk-lib';

Note: Doesn't use the existing rewrite-imports method as that would require parsing the Markdown (requiring an extra dependency) and potentially guarding against malformed inputs. This approach was chosen as a simple, pragmatic solution. We can revisit this in the future if necessary.


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

For the v2 (aws-cdk-lib) docs, the imports scattered throughout the READMEs need
to be re-written. We could hand-edit all of the READMEs on the v2-main branch,
but this is not an ongoing mechanism and may also introduce forward-merge pain.
Instead, we're going to take the cheap option of rewriting the import statements
as part of `ubergen` when building the `aws-cdk-lib` package.

I aimed to capture as many import types as I found in the live READMEs.

As an example, the code transforms these imports as seen below:

```ts
// BEFORE
import * as cdk from '@aws-cdk/core';
  import * as cloudfront from '@aws-cdk/aws-cloudfront';
import codeartifact = require('@aws-cdk/aws-codeartifact');
import { VpcEndpointServiceDomainName } from '@aws-cdk/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from '@aws-cdk/core';

// AFTER
import * as cdk from 'aws-cdk-lib';
  import { aws_cloudfront as cloudfront } from 'aws-cdk-lib';
import { aws_codeartifact as codeartifact } from 'aws-cdk-lib';
import { VpcEndpointServiceDomainName } from 'aws-cdk-lib/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from 'aws-cdk-lib';
```
@njlynch njlynch requested review from a team and rix0rrr April 19, 2021 16:36
@njlynch njlynch self-assigned this Apr 19, 2021
@gitpod-io
Copy link
Copy Markdown

gitpod-io bot commented Apr 19, 2021

@github-actions github-actions bot added the aws-cdk-lib Related to the aws-cdk-lib package label Apr 19, 2021
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Apr 19, 2021
@nija-at nija-at added the pr/do-not-merge This PR should not be merged at this time. label Apr 19, 2021
@rix0rrr
Copy link
Copy Markdown
Contributor

rix0rrr commented Apr 19, 2021

PR could do with a motivation not to use the rewrite-imports functionality we already have (and presumably tested)

@nija-at
Copy link
Copy Markdown
Contributor

nija-at commented Apr 19, 2021

motivation not to use the rewrite-imports functionality

I was going to ask about this too.
I then assumed it was because rewrite-imports used ts transforms that might (will?) not work on code snippets that are not valid typescript.
Would love to know if there were other reasons.

@njlynch
Copy link
Copy Markdown
Contributor Author

njlynch commented Apr 19, 2021

PR could do with a motivation not to use the rewrite-imports functionality we already have (and presumably tested)
I then assumed it was because rewrite-imports used ts transforms that might (will?) not work on code snippets that are not valid typescript.

Simplicity and laziness.

To reuse rewrite-imports, I'd need to first parse the Markdown (likely requiring bringing in a new dependency for the parsing), then pass and transform each block through rewrite-imports, potentially handling any errors from malformed code. On the surface, the approach taken here is simpler (albeit slightly more fragile). Open to arguments that I should reconsider this and at least try to do the Markdown parsing...

@njlynch njlynch removed the pr/do-not-merge This PR should not be merged at this time. label Apr 20, 2021
@mergify
Copy link
Copy Markdown
Contributor

mergify bot commented Apr 20, 2021

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-cdk-automation
Copy link
Copy Markdown
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
  • Commit ID: 7da27c2
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@mergify
Copy link
Copy Markdown
Contributor

mergify bot commented Apr 20, 2021

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).

@mergify mergify bot merged commit 96d4071 into master Apr 20, 2021
@mergify mergify bot deleted the njlynch/readmerewriteimports branch April 20, 2021 10:44
njlynch added a commit that referenced this pull request Apr 21, 2021
Imports in READMEs are now rewritten from '@aws-cdk/...' to 'aws-cdk-lib'.
This change was introduced in #14255, but no validation was included in the
original PR. This change introduces a post-build validation step for aws-cdk-lib
to ensure that the module rewrites were properly done.
njlynch added a commit that referenced this pull request Apr 22, 2021
Imports in READMEs are now rewritten from '@aws-cdk/...' to 'aws-cdk-lib'.
This change was introduced in #14255, but no validation was included in the
original PR. This change introduces a post-build validation step for aws-cdk-lib
to ensure that the module rewrites were properly done.
mergify bot pushed a commit that referenced this pull request Apr 22, 2021
…#14302)

Imports in READMEs are now rewritten from '@aws-cdk/...' to 'aws-cdk-lib'.
This change was introduced in #14255, but no validation was included in the
original PR. This change introduces a post-build validation step for aws-cdk-lib
to ensure that the module rewrites were properly done.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
njlynch added a commit that referenced this pull request Apr 26, 2021
For the v2 (aws-cdk-lib) docs, the imports scattered throughout the READMEs need
to be re-written. We could hand-edit all of the READMEs on the v2-main branch,
but this is not an ongoing mechanism and may also introduce forward-merge pain.
Instead, we're going to take the cheap option of rewriting the import statements
as part of `ubergen` when building the `aws-cdk-lib` package.

I aimed to capture as many import types as I found in the live READMEs.

As an example, the code transforms these imports as seen below:

```ts
// BEFORE
import * as cdk from '@aws-cdk/core';
  import * as cloudfront from '@aws-cdk/aws-cloudfront';
import codeartifact = require('@aws-cdk/aws-codeartifact');
import { VpcEndpointServiceDomainName } from '@aws-cdk/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from '@aws-cdk/core';

// AFTER
import * as cdk from 'aws-cdk-lib';
  import { aws_cloudfront as cloudfront } from 'aws-cdk-lib';
import { aws_codeartifact as codeartifact } from 'aws-cdk-lib';
import { VpcEndpointServiceDomainName } from 'aws-cdk-lib/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from 'aws-cdk-lib';
```

Note: Doesn't use the existing `rewrite-imports` method as that would require parsing the Markdown (requiring an extra dependency) and potentially guarding against malformed inputs. This approach was chosen as a simple, pragmatic solution. We can revisit this in the future if necessary.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
john-tipper pushed a commit to john-tipper/aws-cdk that referenced this pull request May 10, 2021
For the v2 (aws-cdk-lib) docs, the imports scattered throughout the READMEs need
to be re-written. We could hand-edit all of the READMEs on the v2-main branch,
but this is not an ongoing mechanism and may also introduce forward-merge pain.
Instead, we're going to take the cheap option of rewriting the import statements
as part of `ubergen` when building the `aws-cdk-lib` package.

I aimed to capture as many import types as I found in the live READMEs.

As an example, the code transforms these imports as seen below:

```ts
// BEFORE
import * as cdk from '@aws-cdk/core';
  import * as cloudfront from '@aws-cdk/aws-cloudfront';
import codeartifact = require('@aws-cdk/aws-codeartifact');
import { VpcEndpointServiceDomainName } from '@aws-cdk/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from '@aws-cdk/core';

// AFTER
import * as cdk from 'aws-cdk-lib';
  import { aws_cloudfront as cloudfront } from 'aws-cdk-lib';
import { aws_codeartifact as codeartifact } from 'aws-cdk-lib';
import { VpcEndpointServiceDomainName } from 'aws-cdk-lib/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from 'aws-cdk-lib';
```

Note: Doesn't use the existing `rewrite-imports` method as that would require parsing the Markdown (requiring an extra dependency) and potentially guarding against malformed inputs. This approach was chosen as a simple, pragmatic solution. We can revisit this in the future if necessary.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
john-tipper pushed a commit to john-tipper/aws-cdk that referenced this pull request May 10, 2021
…aws#14302)

Imports in READMEs are now rewritten from '@aws-cdk/...' to 'aws-cdk-lib'.
This change was introduced in aws#14255, but no validation was included in the
original PR. This change introduces a post-build validation step for aws-cdk-lib
to ensure that the module rewrites were properly done.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
hollanddd pushed a commit to hollanddd/aws-cdk that referenced this pull request Aug 26, 2021
For the v2 (aws-cdk-lib) docs, the imports scattered throughout the READMEs need
to be re-written. We could hand-edit all of the READMEs on the v2-main branch,
but this is not an ongoing mechanism and may also introduce forward-merge pain.
Instead, we're going to take the cheap option of rewriting the import statements
as part of `ubergen` when building the `aws-cdk-lib` package.

I aimed to capture as many import types as I found in the live READMEs.

As an example, the code transforms these imports as seen below:

```ts
// BEFORE
import * as cdk from '@aws-cdk/core';
  import * as cloudfront from '@aws-cdk/aws-cloudfront';
import codeartifact = require('@aws-cdk/aws-codeartifact');
import { VpcEndpointServiceDomainName } from '@aws-cdk/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from '@aws-cdk/core';

// AFTER
import * as cdk from 'aws-cdk-lib';
  import { aws_cloudfront as cloudfront } from 'aws-cdk-lib';
import { aws_codeartifact as codeartifact } from 'aws-cdk-lib';
import { VpcEndpointServiceDomainName } from 'aws-cdk-lib/aws-route53';
import { Construct, Stage, Stack, StackProps, StageProps } from 'aws-cdk-lib';
```

Note: Doesn't use the existing `rewrite-imports` method as that would require parsing the Markdown (requiring an extra dependency) and potentially guarding against malformed inputs. This approach was chosen as a simple, pragmatic solution. We can revisit this in the future if necessary.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
hollanddd pushed a commit to hollanddd/aws-cdk that referenced this pull request Aug 26, 2021
…aws#14302)

Imports in READMEs are now rewritten from '@aws-cdk/...' to 'aws-cdk-lib'.
This change was introduced in aws#14255, but no validation was included in the
original PR. This change introduces a post-build validation step for aws-cdk-lib
to ensure that the module rewrites were properly done.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot pushed a commit that referenced this pull request Nov 22, 2021
- Adds `rewriteImports` and helper functions `rewriteReadmeImports` and `rewriteMonoPackageImports` to `aws-cdk-migration` package.
- `individual-package-gen` consumes `rewriteReadmeImports` for alpha modules.
- `individual-package-gen` treats rosetta fixtures as source files and rewrites imports there as well.
- Adds `aws-cdk-migration` as a dependency to `ubergen`.
- Refactors `rewriteImports` in `ubergen` to use the API in `aws-cdk-migration`. Has the side affect of removing the string-replace function that was introduced in this [PR](#14255). This changes the readme import style from `import { blah as blah } from 'aws-cdk-lib';` to `import * as blah from 'aws-cdk-lib/blah';`.
- fixes error in `cfnspec` that generated invalid import names for L1 module readmes.
- fixes bug in `cdk-build` that only executed one `post` command.
- fixes `verify-imports` scripts typo introduced previously (that was not caught due to the `cdk-build` bug).

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot pushed a commit that referenced this pull request Nov 22, 2021
- Adds `rewriteImports` and helper functions `rewriteReadmeImports` and `rewriteMonoPackageImports` to `aws-cdk-migration` package.
- `individual-package-gen` consumes `rewriteReadmeImports` for alpha modules.
- `individual-package-gen` treats rosetta fixtures as source files and rewrites imports there as well.
- Adds `aws-cdk-migration` as a dependency to `ubergen`.
- Refactors `rewriteImports` in `ubergen` to use the API in `aws-cdk-migration`. Has the side affect of removing the string-replace function that was introduced in this [PR](#14255). This changes the readme import style from `import { blah as blah } from 'aws-cdk-lib';` to `import * as blah from 'aws-cdk-lib/blah';`.
- fixes error in `cfnspec` that generated invalid import names for L1 module readmes.
- fixes bug in `cdk-build` that only executed one `post` command.
- fixes `verify-imports` scripts typo introduced previously (that was not caught due to the `cdk-build` bug).

----

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

(cherry picked from commit 66e37cc)

# Conflicts:
#	packages/@aws-cdk/cfnspec/lib/library-creation.ts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

aws-cdk-lib Related to the aws-cdk-lib package contribution/core This is a PR that came from AWS.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants