-
Notifications
You must be signed in to change notification settings - Fork 13
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
Direct comparison via TypeScript's isTypeAssignableTo
function
#36
Direct comparison via TypeScript's isTypeAssignableTo
function
#36
Conversation
Had to modify the TS source to make it accessible, but it appears to work well.
isTypeIdenticalTo
functionisTypeAssignableTo
function
Just a quick feedback, I am heading out for vacation: I totally like the HTML changes (Table, filter, etc.) About the comparison: It would be very beneficial to have a more precise comparison. However, we should have a close look at "present but not compatible". If these entries are actually compatible in practice, i.e. an extension developer can use the API without noticing a thing, then the report would show a lot of false positives. |
@colin-grant-work Great work! 👍 I've tested this PR and looked at the code, for now just on a high level. Overall it makes a very good impression and I really like the improved report and certainly find the increased precision to be very valuable! Of course, this new approach for a compatibility check makes a lot of green lines orange, which doesn't look great. However, I guess at this stage, it is hard to tell which of the orange ones actually do have a larger impact or which don't. Anyway, better we know it and work on it rather than sweeping it under the rug. Until we cleaned up the easily fixable incompatibilities, however, we may want to just show the warning in a less aggressive way, e.g. say "partly supported" or ✔️~, to avoid scaring off adopters from using certain plugins or even Theia in the first place, even though many of the plugins using that API would actually work. In fact, we currently don't know how impactful those inconsistencies are. But eventually we should, imho, aim for 1:1 equivalent definitions and rather work around technically reasonable differences or partly unsupported behavior in the plugin-ext implementations. I may miss something, but I can't really think of a good reason to keep differences in @colin-grant-work What's your overall feeling on the newly raised incompatible ones? Are they mostly minor "structural" but less semantic differences? For instance, the example @colin-grant-work brought up in #32 (comment) is a clear incompatibility and should be addressed. If someone puts in an I could offer to skim the incompatibilities a bit next week, if that helps. If I'm not mistaken, there are about 200 of them though ;-) which leads to the next point: Report-wise, imho the most important issue is the knock-on effect, as it kind-of distorts the report and doesn't clearly point to the actual culprit anymore. Do you think it would be feasible to address this effect with reasonable effort, e.g. with a second pass to check the incompatible ones more locally? I didn't find the place where you use |
@planger @JonasHelming, thanks for your feedback. I've taken a look (with @vince-fugnitto) at some of the new incompatibilities. Some of them are pretty trivial: a lot of missing A lot of the other new compatibility issues are knockons. A good example there is that Given that, I think @planger's suggestion that we at a minimum reduce the apparent severity of the warning is a good one to give us time to address straightforward cases and reduce the number of derived incompatibilities we see in mostly-supported API. It may also make sense to specify the target VSCode version explicitly, and either omit
It should be possible to set things up so that if an incompatibility is detected, we check some other heuristic - simplest would be string identity of the nodes - and if it passes that, then we assume that the fault lies somewhere else. I'll experiment with that.
I've switched to using |
A check for string identity of the declarations reduces incompatibilities by about 90, it appears. I'll push a patch soon. |
I've implemented the check for string identity of the declarations. That reduces the reported incompatibilities on Theia |
9ec57a1
to
0006800
Compare
0006800
to
b4ad73a
Compare
I've changed the 'warning' to have a green background with a yellow circle. I'm open to suggestions - @vince-fugnitto? |
@colin-grant-work I have the following suggestions if interested:
I have the following POC to show my feedback: comparator.mov |
Maybe I'm missing something, but what's the point of the |
@vince-fugnitto Looks awesome! Thanks! I'd just have a minor suggestion: I think it could be better to make |
I agree, I think the column |
@planger, where you do stand on the current state of this PR? I think the TypeScript comparison is better than the existing comparison, and I think that with my PR, there are basically no false reports of incompatibility: in all of the cases where TS reports that a field is incompatible, inspection confirms that there is a substantive difference in the declaration. We will have to be vigilant about unresolved references leading to |
4dceaa7
to
a2babae
Compare
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 is looking very good 👍
I have tested the new solution with a focus on the presentation of stubbed
,
The testing was performed against stubbed theia.d.ts
versions available using:
THEIA_URL_PATTERN = 'https://raw.githubusercontent.com/alvsan09/test_theia.d.ts/${VERSION}/theia.d.ts';
The expected results mentioned below correspond to the mocked theia.d.ts
mentioned above.
I noticed the following:
- Type decorators are missing, I think they are quite useful
- Type aliases are being incorrectly shown as members of a previous entry
e.g.Definition
,DefinitionLink
- Stubbed annotation missing for some entries e.g.
EvaluatableExpression v1.29.0, TreeItem master Extension
does not reflect any implementations, however the former solution
seem to somehow map the status to an equivalentPlugin
entry, so this mapping is missing.Enum
's reflected as child entries, e.g.InputBoxValidationSeverity
- From above,
Enum
members are not shown Memento#keys
showUnsupported
for all versions, however the entry is present fromv1.29.0
Memento#keys
update is expected to showstubbed
for themaster
version.- Multiple signatures of function
showQuickPick
show as only a single entry
@@ -12,7 +12,14 @@ | |||
import * as ts from 'typescript'; | |||
import { RecursiveRecord } from './recursive-record'; | |||
|
|||
export interface Comparison extends RecursiveRecord<boolean | null> { } | |||
export const enum SupportLevels { |
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.
Minor:
Although not explicitly stated on the theia
coding conventions,
most enum
names are singular.
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.
Updating my vote, as per previous review ...
@colin-grant-work I'm much in favor of this PR! The enhanced precision of this report surely will help us identifying where we need to improve and I certainly appreciate the improved style of the report. 👍 I guess waiting for your PR to fix the "pseudo" incompatibilities would help avoiding a time period where the report is a bit overly pessimistic. Thank you @alvsan09 for making the comparison with the old report! I had that on my todo list for tonight. Once those are fixed, I'm really looking forward to this PR getting merged. Thanks a lot! |
@alvsan09, thanks for taking a thorough look through the results. I will see what adjustments need to be made 👍 |
This is noted in the description under the heading 'loss of metadata.' I don't find this data very helpful: an extension developer who wants to use the API likely knows what's a function and what's a class; a developer improving the API will have to look at the declarations anyway. But they can be restored if there's consensus about their inclusion
Fixed - they're now displayed as top-level.
At the moment, the code expects
Also noted in the description:
In particular, it is not correct to say that we support the
This is deliberate -
This is actually correct: and the double declaration makes it incorrect.
This is a consequence of the comparison method - it's simpler to allow TS to compare the effective constraint rather than attempting to match up overrides. |
I would prefer to reinstate them and save the space from other columns e.g. by decreasing the number of |
I was chatting off-line with @vince-fugnitto and he has raised a valid concern on the icons being used by the former solution e.g. Copyright for Classes, forsquare for functions, and venmo for variables, that would definitely need to be improved, however it would make sense to address it in a separate PR later in the future and if there is a consensus to bring them back. As per the rest of the explanations, I am fine with them! |
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 have used showQuickPick
as a reference to test the last two commits and they work fine 👍
The code looks good to me as well !
I'll merge tomorrow unless there are objections (@planger, with a CC to Jonas, if he's not still on vacation). |
@colin-grant-work Thanks for the heads-up! 👍 for merging. Jonas will be back next week. |
This PR proposes an alternative strategy for comparing
theia.d.ts
andvscode.d.ts
. Currently, metadata is extracted from the declaration files, and then that metadata is compared at varying levels of detail. In this experiment, the internal typechecking functionisTypeIdenticalTo
, which is present onTypeChecker
but not declared, is used to answer the question of compatibility directly, so that every member of the declaration can be labeled present and compatible, present but not compatible, or absent.This PR also makes a number of changes to the report:
Todo:
This is currently just a proposal and a demonstration, and it should be evaluated thoroughly before acceptance. There are a few known todos:
extensions
). I've removed that for now, since it isn't clear to me why we shouldn't match those intheia.d.ts
instead of having special handling here.Advantages:
isTypeIdenticalTo
available internally to TypeScript, but for example it considers even code-identical enum declarations not to be identical, so it may be too strict.Disadvantages:
isTypeAssignableTo
is used as a black box: we get no information about why declarations don't match. There may be other API that would provide more information (e.g.checkTypeRelatedTo
). Onmaster
the parsing method produces more metadata and can be inspector more easily for problems.