Skip to content
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(jsii): experimental --strip-deprecated feature #2437

Merged
merged 12 commits into from
Jan 26, 2021

Conversation

RomainMuller
Copy link
Contributor

@RomainMuller RomainMuller commented Jan 19, 2021

This feature will cause jsii to erase all declarations marked with
@deprecated from the .jsii assembly and .d.ts files.

When a @deprecated type is extended (or implemented) by a type that
is not @deprecated, the inheritance chain will be corrected, erasing
the @deprecated type and replacing it with it's non @deprecated
parents, if any.

Remaining uses of @deprecated members will be reported through
diagnostic messages (with the ERROR severity).


A new module bindings was implemented to allow relating TypeScript AST
nodes to "arbitrary" points in the jsii assembly, allowing to recover
that information once the tree was fully processed. This makes
multi-pass transformations not need to re-inspect the whole AST again.


⚠️ This is currently unable to identify interface implementations that become
invalid (in the type definitions) as a result of erasing a base class.


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

This feature will cause `jsii` to erase all declarations marked with
`@deprecated` from the `.jsii` assembly and `.d.ts` files.

When a `@deprecated` type is extended (or implemented) by a type that
is not `@deprecated`, the inheritance chain will be corrected, erasing
the `@deprecated` type and replacing it with it's non `@deprecated`
parents, if any.

Remaining uses of `@deprecated` members will be reported through
diagnostic messages (with the `ERROR` severity).

---

A new module `bindings` was implemented to allow relating TypeScript AST
nodes to "arbitrary" points in the jsii assembly, allowing to recover
that information once the tree was fully processed. This makes
multi-pass transformations not need to re-inspect the whole AST again.
@RomainMuller RomainMuller requested a review from nija-at January 19, 2021 17:06
@RomainMuller RomainMuller self-assigned this Jan 19, 2021
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Jan 19, 2021
@RomainMuller RomainMuller marked this pull request as ready for review January 20, 2021 11:41
Copy link
Contributor

@nija-at nija-at left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Architectural qn (non blocking): we have a couple of transformers here now - this one and the one for experimental API docs. How far away do you think we are to making these PnP to the jsii core compiler (not necessarily to the CLI or configuration)?

@@ -0,0 +1,891 @@
import {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend tests for such a large and complex code. I suppose it's coming soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...granted I am not allocated to another project...

@RomainMuller
Copy link
Contributor Author

Architectural qn (non blocking): we have a couple of transformers here now - this one and the one for experimental API docs. How far away do you think we are to making these PnP to the jsii core compiler (not necessarily to the CLI or configuration)?

To be honest - I very much dislike the current state of this; and it'd likely deserve a major overhaul. The main jsii business needs to happen as a transform, too, so we don't have to actually jump though the kind of hoops we are currently... The performance right now would be hit by the fact we actually cause the TypeScript compiler itself to emit (i.e: write output files, like .js & .d.ts files) at least twice, maybe thrice... This is...... unnecessary.

@nija-at nija-at added the pr/do-not-merge This PR should not be merged at this time. label Jan 21, 2021
Copy link
Contributor

@nija-at nija-at left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provisional approval

@@ -54,6 +54,12 @@ const warningTypes = Object.keys(enabledWarnings);
desc: `List of warnings to silence (warnings: ${warningTypes.join(
',',
)})`,
})
.option('strip-deprecated', {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expand and document this in the jsii docs. Also explain any pre-requisites, such as deprecated types must not be used in such-and-such places, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole point of it being EXPERIMENTAL here is I actually don't want to publicise it too much just yet...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add an experimental section to the docs 🤷‍♂️
Fine with me if you feel strongly

packages/jsii/test/deprecated-remover.test.ts Show resolved Hide resolved

const DEPRECATED = '/** @deprecated stripped */';

test('produces correct output', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would've been nicer to organize these fixtures and expectations as actual folders with files.
Would be much easier to add new cases as we fix or add features to the remove-deprecated.

WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expectations as actual folders with files means we have to write our own way to update snapshots (jest -u will only update .ts.snap files, and the structure there is not very flexible). Also - how is more files to know about and modify, better than the whole GIVEN/WHEN/THEN is in a single place?

@@ -54,6 +54,12 @@ const warningTypes = Object.keys(enabledWarnings);
desc: `List of warnings to silence (warnings: ${warningTypes.join(
',',
)})`,
})
.option('strip-deprecated', {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to ensure that when 'new' jsii features are supported (say, union types), they are correctly handled by this flag?

Not expecting it in this PR, but wondering if you've thought about this.

One way that comes to mind is - "some" automated mechanism (hand wave) of taking the jsii fixture (calc) and marking most or all of them as deprecated and stripping them out.

Another option - if there's some place where we've centralized the jsii specification and supported features, it might be easier walk through them and dynamically generate a fixture and run them through strip-deprecated.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Hand wave) Contributions are welcome 🤓

@@ -54,6 +54,12 @@ const warningTypes = Object.keys(enabledWarnings);
desc: `List of warnings to silence (warnings: ${warningTypes.join(
',',
)})`,
})
.option('strip-deprecated', {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Not necessary to do it in this PR)

What do you think about adding this option to the jsii component of package.json as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm favorable to this but did not have time to go about it... Should be easy enough to do.

@RomainMuller RomainMuller removed the pr/do-not-merge This PR should not be merged at this time. label Jan 25, 2021
@mergify
Copy link
Contributor

mergify bot commented Jan 26, 2021

Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it!

@mergify mergify bot added the pr/ready-to-merge This PR is ready to be merged. label Jan 26, 2021
@mergify
Copy link
Contributor

mergify bot commented Jan 26, 2021

Merging (with squash)...

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-5lHf64IXfvmr
  • Commit ID: a598334
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@mergify mergify bot merged commit f958f5a into main Jan 26, 2021
@mergify mergify bot deleted the rmuller/hide-deprecated branch January 26, 2021 20:37
@mergify
Copy link
Contributor

mergify bot commented Jan 26, 2021

Merging (with squash)...

@mergify mergify bot removed the pr/ready-to-merge This PR is ready to be merged. label Jan 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants