LSP for IntelliJ/PHPStorm

[nickvergessen]

I spotted the LSP in the changelog and got curious.
Just in case it matches the section from the #986 issue:

Per-editor integrations (like VS Code's "LSP client" extensions)

I'd be interested in an IntelliJ version for it.

I installed the following IntelliJ plugin https://github.com/redhat-developer/lsp4ij and then tried to define it:

But apart from a small notification

And traces:

The logs only showed:

server initialized!

I guess I need to hand in more configuration for the Server or Client side, but I was unable to spot anything in https://github.com/zizmorcore/zizmor-vscode/blob/main/src/extension.ts that I should be copying. Or is it in the typescript dependency and you simply didn't need to change anything?

Would you be able to share the JSON of server configuration, initialization options and client configuration that the VSCode version is creating?

[angelozerr]

@nickvergessen I am the author of LSP4IJ.

I am not sure that you can define file pattern with / since it uses the same class used in intellij when you define file type.

Could you just define *.yml in your file pattern.

[angelozerr]

@nickvergessen I am the author of LSP4IJ.

I am not sure that you can define file pattern with / since it uses the same class used in intellij when you define file type.

Could you just define *.yml in your file pattern.

@nickvergessen if you need to know which configuration settings initializations options expexted by the language server I suggest that you install the vscide extension and defines
zizmor.trace.server to verbose in the vscode settings znd you should see the same lsp traces than vscode

[nickvergessen]

Thanks a lot @angelozerr that was way easier then expected:

It seems to work now

[angelozerr]

Thanks a lot @angelozerr that was way easier then expected:

It seems to work now

Thzts great!

I wonder if it could be interesting to add your server definition as templzte in lsp4ij https://github.com/redhat-developer/lsp4ij/blob/main/docs%2FUserDefinedLanguageServerTemplate.md

And if you like LSP4IJ please add a review in jetbrzins marketplace to help us to promote it. Thanks!

[nickvergessen]

I will test it a bit more, but it really looks quite "easy". I exported the server, all files are empty but the template.json one which is:

{
  "name": "zizmor - Static analysis for GitHub Actions ",
  "programArgs": {
    "default": "zizmor --lsp"
  },
  "fileTypeMappings": [
    {
      "fileType": {
        "patterns": [
          "*.yml"
        ]
      },
      "languageId": "yaml"
    }
  ]
}

[angelozerr]

Indeed it should be easy to do and it is the reason why I think it could be a good idea to have a template. Please read the doc because for instance you need to define an id in your templzte.json

More i suggest that yiu write 1n installer.json to install the server automaticly.

I suggest that you see the templates/lsp user defined ls.

By adding your ls as template you will have an exitor notification which will promote to install the server. See for instance zstro doc at https://github.com/redhat-developer/lsp4ij/blob/main/docs%2Fuser-defined-ls%2Fastro-ls.md

[woodruffw]

Hey @nickvergessen, thanks for opening! And thank you @angelozerr for diagnosing!

For future reference, the relevant document selector configuration is here:

https://github.com/zizmorcore/zizmor-vscode/blob/e8cae71e3acd9184ef6558854bb5b2261028187f/src/extension.ts#L47-L50

...and also here in the LSP server itself, although I'm guessing in this case LSP4IJ doesn't allow the server to declare its capabilities like this:

zizmor/crates/zizmor/src/lsp.rs

Lines 50 to 116 in 1cc8f93

	let selectors = vec![
	lsp_types::DocumentFilter {
	language: Some("yaml".into()),
	scheme: None,
	pattern: Some("**/.github/workflows/*.{yml,yaml}".into()),
	},
	lsp_types::DocumentFilter {
	language: Some("yaml".into()),
	scheme: None,
	pattern: Some("**/action.{yml,yaml}".into()),
	},
	];
	// Register our capabilities with the client.
	// Clients like the VS Code extension should do this for us, but we
	// also explicitly request these capabilities in case the client/integration
	// neglects to.
	self.client
	.register_capability(vec![
	lsp_types::Registration {
	id: "zizmor-didopen".into(),
	method: "textDocument/didOpen".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentRegistrationOptions {
	document_selector: Some(selectors.clone()),
	})
	.unwrap(),
	),
	},
	lsp_types::Registration {
	id: "zizmor-didchange".into(),
	method: "textDocument/didChange".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentChangeRegistrationOptions {
	document_selector: Some(selectors.clone()),
	sync_kind: 1, // FULL
	})
	.unwrap(),
	),
	},
	lsp_types::Registration {
	id: "zizmor-didsave".into(),
	method: "textDocument/didSave".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentSaveRegistrationOptions {
	include_text: Some(true),
	text_document_registration_options:
	lsp_types::TextDocumentRegistrationOptions {
	document_selector: Some(selectors.clone()),
	},
	})
	.unwrap(),
	),
	},
	lsp_types::Registration {
	id: "zizmor-didclose".into(),
	method: "textDocument/didClose".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentRegistrationOptions {
	document_selector: Some(selectors),
	})
	.unwrap(),
	),
	},
	])
	.await
	.expect("failed to register text document capabilities with the LSP client");

More generally, I'd recommend constraining your configuration like one of the above, since matching *.yml will cause a bunch of wasted work on matches that aren't actually GitHub Actions definitions or workflows.

[angelozerr]

Hey @nickvergessen, thanks for opening! And thank you @angelozerr for diagnosing!

You are welcome!

For future reference, the relevant document selector configuration is here:

https://github.com/zizmorcore/zizmor-vscode/blob/e8cae71e3acd9184ef6558854bb5b2261028187f/src/extension.ts#L47-L50

...and also here in the LSP server itself, although I'm guessing in this case LSP4IJ doesn't allow the server to declare its capabilities like this:

zizmor/crates/zizmor/src/lsp.rs

Lines 50 to 116 in 1cc8f93

	let selectors = vec![
	lsp_types::DocumentFilter {
	language: Some("yaml".into()),
	scheme: None,
	pattern: Some("**/.github/workflows/*.{yml,yaml}".into()),
	},
	lsp_types::DocumentFilter {
	language: Some("yaml".into()),
	scheme: None,
	pattern: Some("**/action.{yml,yaml}".into()),
	},
	];
	// Register our capabilities with the client.
	// Clients like the VS Code extension should do this for us, but we
	// also explicitly request these capabilities in case the client/integration
	// neglects to.
	self.client
	.register_capability(vec![
	lsp_types::Registration {
	id: "zizmor-didopen".into(),
	method: "textDocument/didOpen".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentRegistrationOptions {
	document_selector: Some(selectors.clone()),
	})
	.unwrap(),
	),
	},
	lsp_types::Registration {
	id: "zizmor-didchange".into(),
	method: "textDocument/didChange".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentChangeRegistrationOptions {
	document_selector: Some(selectors.clone()),
	sync_kind: 1, // FULL
	})
	.unwrap(),
	),
	},
	lsp_types::Registration {
	id: "zizmor-didsave".into(),
	method: "textDocument/didSave".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentSaveRegistrationOptions {
	include_text: Some(true),
	text_document_registration_options:
	lsp_types::TextDocumentRegistrationOptions {
	document_selector: Some(selectors.clone()),
	},
	})
	.unwrap(),
	),
	},
	lsp_types::Registration {
	id: "zizmor-didclose".into(),
	method: "textDocument/didClose".into(),
	register_options: Some(
	serde_json::to_value(lsp_types::TextDocumentRegistrationOptions {
	document_selector: Some(selectors),
	})
	.unwrap(),
	),
	},
	])
	.await
	.expect("failed to register text document capabilities with the LSP client");

More generally, I'd recommend constraining your configuration like one of the above, since matching *.yml will cause a bunch of wasted work on matches that aren't actually GitHub Actions definitions or workflows.

I agree with you @woodruffw, the file pattern matching in LSP4IJ should be improved. @nickvergessen could you create an issue in LSP4IJ please.

[woodruffw]

NB: I'm moving this over to a discussion for now, but I'd be happy to take a doc PR that updates the LSP integrations section to mention IntelliJ 🙂