Added null check to some adapters and changed type definition

[ayame113]

Some LSP requests lack null checking and are causing errors, so I fixed them.

I made the following changes:

1. Added null check (https://github.com/atom-community/atom-languageclient/commit/e20bba5a4fe06b4f1a24f2063b1a60fcd5da1514)
2. Fixed the type definition (https://github.com/atom-community/atom-languageclient/commit/85cc505a5c9999e4da044996aa49e436d32d017a)
3. Use the vscode-languageserver-protocol package for type definition (https://github.com/atom-community/atom-languageclient/compare/85cc505..d665159)

If you don't need the third change, reverting it will still work.

[UziTech]

I think we were discussing this in https://github.com/atom-community/atom-languageclient/pull/132#discussion_r595580845

I'm not sure if it is better to throw an error if the lsp returns something invalid or fail silently like this PR. Is null or undefined a valid return for .codeAction?

[aminya]

I think we were discussing this in #132 (comment)

This is different though.

[UziTech]

This is different though.

How? Why are these checks necessary if null or undefined are not correct outputs of .codeAction anyway?

If null or undefined are valid outputs then we should change the types to reflect that.

[aminya]

I meant the changes under lib/languageclient.ts which seem reasonable as they are using the original types.

[UziTech]

I meant the changes under lib/languageclient.ts which seem reasonable as they are using the original types.

Ya I think those changes are good. I'm just not sure about null checks.

[ayame113]

(some comment)

• Currently, the vscode-languageserver-protocol module is used for type definition. In this PR, I also want to use it in the return value of the language-client method.
  • Since the return type is not exported directly from the module, I am using the generics of the function.
  • I used it as a reference for implementation https://github.com/microsoft/vscode-languageserver-node/blob/d58c00bbf8837b9fd0144924db5e7b1c543d839e/client/src/common/client.ts#L83-L86
  • This will cause a type error if the wrong return type.
• Removed null from the return value of the following request according to the type definition
  • completionItem / resolve
  • codeLens / resolve
  • Added null
  • textDocument/references
  • textDocument/documentHighlight
  • textDocument/documentSymbol
  • workspace/symbol
  • textDocument/codeAction
  • textDocument/codeLens
  • textDocument/documentLink
  • textDocument/formatting
  • textDocument/rangeFormatting
  • textDocument/onTypeFormatting
  • textDocument/rename
  • I think this implementation fits the spec, but you can leave null in the return value if you want to deal with invalid null checks outside the spec.

[aminya]

I'll review today or tomorrow

[github-actions[bot]]

:tada: This PR is included in version 1.8.3 :tada:

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot :package::rocket: