-
Notifications
You must be signed in to change notification settings - Fork 245
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
Conversation
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.
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.
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 { |
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.
I would recommend tests for such a large and complex code. I suppose it's coming soon.
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.
...granted I am not allocated to another project...
To be honest - I very much dislike the current state of this; and it'd likely deserve a major overhaul. The main |
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.
Provisional approval
@@ -54,6 +54,12 @@ const warningTypes = Object.keys(enabledWarnings); | |||
desc: `List of warnings to silence (warnings: ${warningTypes.join( | |||
',', | |||
)})`, | |||
}) | |||
.option('strip-deprecated', { |
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.
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.
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 whole point of it being EXPERIMENTAL
here is I actually don't want to publicise it too much just yet...
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.
Maybe add an experimental section to the docs 🤷♂️
Fine with me if you feel strongly
|
||
const DEPRECATED = '/** @deprecated stripped */'; | ||
|
||
test('produces correct output', async () => { |
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.
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?
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.
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', { |
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.
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.
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.
(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', { |
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.
(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?
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.
I'm favorable to this but did not have time to go about it... Should be easy enough to do.
Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it! |
Merging (with squash)... |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Merging (with squash)... |
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 thatis not
@deprecated
, the inheritance chain will be corrected, erasingthe
@deprecated
type and replacing it with it's non@deprecated
parents, if any.
Remaining uses of
@deprecated
members will be reported throughdiagnostic messages (with the
ERROR
severity).A new module
bindings
was implemented to allow relating TypeScript ASTnodes 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.
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.