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

Add missing types from atom-languageclient #57

Merged
merged 15 commits into from
Feb 19, 2021
Merged

Add missing types from atom-languageclient #57

merged 15 commits into from
Feb 19, 2021

Conversation

aminya
Copy link
Member

@aminya aminya commented Feb 7, 2021

I compared the types in atom-languageclient with the types we had here in atom-ide-base, and I added the missing ones here.

The types will be removed from atom-languageclient once this PR is merged.
atom-community/atom-languageclient#121

We no longer need to maintain the types in two places.

@aminya aminya marked this pull request as ready for review February 18, 2021 09:54
@aminya aminya changed the title Move missing types or docstring from atom-languageclient Add missing types from atom-languageclient Feb 18, 2021
@@ -13,7 +24,7 @@ export interface CodeActionProvider {
getCodeActions(
editor: Atom.TextEditor,
range: Atom.Range,
diagnostics: Message[]
diagnostics: Diagnostic[] // | Message[]
Copy link
Member Author

Choose a reason for hiding this comment

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

atom-languageclient uses Diagnostic. Not sure if linter Message supports code action API yet

Copy link
Contributor

Choose a reason for hiding this comment

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

Diagnostic is from atom-ide-ui. Which is a slight variation on linter Message. Actually defined here: https://github.com/facebookarchive/atom-ide-ui/blob/master/modules/atom-ide-ui/pkg/atom-ide-diagnostics/lib/types.js#L93

I would suggest we rather scrub this legacy off of atom-languageclient rather than dragging it into the town square, figuratively speaking.

Since we're expecting Linter to handle our diagnostic messages, we really should use the Linter messages and not an ad-hoc approximation defined above.

Copy link
Member Author

@aminya aminya Feb 19, 2021

Choose a reason for hiding this comment

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

I agree. We should fix this issue.

The Message type is not compatible with Diagnostic, and Diagnostic is what is used right now in atom-languageclient. Since it is part of a bigger change and codeAction is not implemented yet in the Linter package), I am going to keep Diagnostic for now, so I can merge the linked PR.

The Diagnostic types were actually removed in this WIP PR, So, we should eventually do the big work, and fix everything.
atom-community/atom-languageclient#112

Copy link
Contributor

@lierdakil lierdakil left a comment

Choose a reason for hiding this comment

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

More types is probably good. However, there are a few questionable places I think? I've added a few comments. I'll mark this as requesting changes.

The most questionable one is substituting Message for Diagnostic. We really should strive to get closer to Linter spec, and where possible avoid dragging up parts of things Facebook killed a long time ago.

@@ -13,7 +24,7 @@ export interface CodeActionProvider {
getCodeActions(
editor: Atom.TextEditor,
range: Atom.Range,
diagnostics: Message[]
diagnostics: Diagnostic[] // | Message[]
Copy link
Contributor

Choose a reason for hiding this comment

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

Diagnostic is from atom-ide-ui. Which is a slight variation on linter Message. Actually defined here: https://github.com/facebookarchive/atom-ide-ui/blob/master/modules/atom-ide-ui/pkg/atom-ide-diagnostics/lib/types.js#L93

I would suggest we rather scrub this legacy off of atom-languageclient rather than dragging it into the town square, figuratively speaking.

Since we're expecting Linter to handle our diagnostic messages, we really should use the Linter messages and not an ad-hoc approximation defined above.

types-packages/uri.d.ts Show resolved Hide resolved
activeSignature?: number
activeParameter?: number
activeSignature?: number | null
activeParameter?: number | null
Copy link
Contributor

Choose a reason for hiding this comment

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

As far as I can tell, this nulls serve no practical purpose and the only reason they are here is because of flowjs. I suggest we lose them.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, but these types were being used with the null union in atom-languageclient. Removing null at this point is dangerous in my opinion.

types-packages/datatip.d.ts Outdated Show resolved Hide resolved
@aminya aminya merged commit 49bf749 into master Feb 19, 2021
@aminya aminya deleted the types branch February 19, 2021 09:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants