-
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): added a symbol identifier to every type in the assembly #3030
Merged
Merged
Changes from 12 commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
e79b6ce
feat: added a map from symbol identifiers to fully qualified names in…
19057de
Fixed tests
688c58c
Added a symbolId to every type instead of a global map
9e3ada8
Fixed integration tests
c02f3a9
Removed leftover prop
c2f17d0
Update 0.21.2.jsii.json
otaviomacedo 4156836
Fixed snapshot test
86b6caf
Fixed snapshot test
635456f
Fixed snapshot tests
434e5a6
Made test OS agnostic
8ab42d7
Fixed the symbolIdentifier function to take into account a possible o…
880bc4e
Splitting the path by either \ or /
5413e15
Merge branch 'main' into otaviom/symbol-identifiers
mergify[bot] File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 the intention down the line to leverage the fact that this effectively contains a file path + declaration name?
If so, the relative path might be altered by
tsc.outDir
... And that might be worth considering?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.
For the deprecation warnings, the only requirement is that this string uniquely identifies the symbol. The idea is: the JSII assembly is the source of truth for deciding whether an element is deprecated. But when we traverse the AST, what we have are Typescript nodes. So this property is the bridge between the two domains. If we can deterministically generate the same strings when writing to the assembly and when reading from it, we can do this mapping.
@rix0rrr do you have other applications in mind?
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.
It's a good point, I had forgotten about that. The identifier should be stable regardless of whether we're looking at the "uncompiled" source, or the "compiled + distributed" sources that go up on NPM.
These are the potential cases we could be running into:
All should ideally have the same identifier, so that we can treat jsii packages that we consume via in-repo symlinks and via monorepo symlinks the same.
That kinda sucks actually :(.
Anyone any good ideas?
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 mean... logically the identifier should have the path
src/file
in there. We have to think about how to extract that short relative path from this full path though:It requires us to be able to identify the
<dist>
dir in some way.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.
Ho but that's actually not too hard. Given that we're looking for the
package.json
anyway, that will haveoutdir
set underjsii.tscOptions
(or whatever the configuration is again). So it would work something like this: