Add LSP-some-sass

[niksy]

https://github.com/niksy/LSP-sass

[STReviewBot]

Automated testing result: SUCCESS

Repo link: LSP-sass

Packages added:
  - LSP-sass

Processing package "LSP-sass"
  - All checks passed

[predragnikolic]

Some notes:

• you probably need to mention that the user also needs to install the Sass package for sintax highlighting https://github.com/niksy/LSP-sass?tab=readme-ov-file#installation

• Since LSP-sass can be used to process style[lang="scss"] blocks in SFCs, CSS language features from LSP-volar will clash with LSP-sass since both are trying to provide information at the same time.

This looks like something that needs to be improved in LSP. What requests are clashing?

[predragnikolic]

Apart from that, code looks ok.
If you know what the minimum supported node version is, you could also add such check. Here is an example
https://github.com/sublimelsp/LSP-volar/blob/5b595c0f274163600af43f05c5baa14f5e236480/plugin.py#L24-L26. (this is optional)

[rchl]

Would you consider migrating the repo to this organization (and getting full access to the repo)? We prefer that since then we can easily manage and ensure that everything is aligned.

[niksy]

@predragnikolic

you probably need to mention that the user also needs to install the Sass package for sintax highlighting niksy/LSP-sass#installation

If you know what the minimum supported node version is, you could also add such check. Here is an example
sublimelsp/LSP-volar@5b595c0/plugin.py#L24-L26. (this is optional)

Done!

This looks like something that needs to be improved in LSP. What requests are clashing?

Basically, Some Sass language server used in LSP-sass is extending default CSS language server, but Volar also does that to provide features such as handling v-bind functions in CSS.

I’ve already tried to see if style block processing can be disabled in Volar, but I don’t see option for that.

@rchl

Would you consider migrating the repo to this organization (and getting full access to the repo)? We prefer that since then we can easily manage and ensure that everything is aligned.

Sure, that would definitely be better approach!

[rchl]

Sure, that would definitely be better approach!

Can you create a PR against https://github.com/sublimelsp/LSP-some-sass ? I'll set up permissions later so that you can manage it.

Note that I've named it LSP-some-sass (open to discuss this) since we should be calling the package by the server name and not by the language name. Otherwise if there would be multiple servers for a single language then the distinction would not be clear.

[niksy]

@rchl I’ve created PR for codebase: sublimelsp/LSP-some-sass#1

Note that I've named it LSP-some-sass (open to discuss this) since we should be calling the package by the server name and not by the language name. Otherwise if there would be multiple servers for a single language then the distinction would not be clear.

I’m okay with this; as I see, most language servers for Sublime LSP follow this logic.

[STReviewBot]

Automated testing result: ERROR

Repo link: LSP-some-sass
Results help

Packages added:
  - LSP-some-sass

Processing package "LSP-some-sass"
  - ERROR: No valid semver tags found at https://github.com/sublimelsp/LSP-some-sass/tags for the package "LSP-some-sass".

[jwortmann]

Hello, I see in the readme

Beware that there are certain features that can’t be disabled currently (duplicate color provider references).

This looks like a bug in LSP (I see that color boxes are currently requested for all SessionBuffers, but probably they shouldn't). Could you file an issue in https://github.com/sublimelsp/LSP or provide an example file and the language servers where this can be reproduced (for someone who doesn't know what Sass or Vue is)?

Btw, for now it should be possible to disable the color provider in one of the servers via

{
    "disabled_capabilities": {
        "colorProvider": true
    },
}

[niksy]

@jwortmann sure, no problem, here it is: sublimelsp/LSP#2534

I’m aware that color references can be disabled as capability, but I didn’t want to mention that since it’s very invasive and relates to full language server feature as opposed to specific feature (Vue Sass style block).

[niksy]

Current status:

• Initial codebase has been merged: Add initial implementation LSP-some-sass#1
• Node 20 support has been added to lsp_utils: fix: update node to 20.18.0 lsp_utils#125
  • I suppose we’re waiting for new release before we create initial version for LSP-some-sass?

[predragnikolic]

Thank you, tested with the latest release of lsp_utils.

Note, some people might run into issues:

1. if lsp_utils is not up to date. They will probably see an error like found Node v18, expected v20. The way to resolve it is to make sure that they have the latest lsp_utils installed.
2. if they have "local_use_electron": true in lsp_utils.sublime-settings. The server will just throw an error in that case and not start. This is not the first Language Server that doesn't work in the electron environment. The way to fix is to set "local_use_electron": false to not run the node electron version that uses pointer completion.

[rchl]

It works with electron for me (on mac).

[rchl]

Actually you are right. There is an error like:

Traceback (most recent call last):
  File "/Users/rafal/Library/Application Support/Sublime Text/Packages/LSP/plugin/core/windows.py", line 282, in start_async
    plugin_class.install_or_update()
  File "/Users/rafal/Library/Application Support/Sublime Text/Lib/python38/lsp_utils/_client_handler/abstract_plugin.py", line 109, in install_or_update
    server.install_or_update()
  File "/Users/rafal/Library/Application Support/Sublime Text/Lib/python38/lsp_utils/server_npm_resource.py", line 127, in install_or_update
    raise Exception('Error installing the server:\n{}'.format(error))
Exception: Error installing the server:
Failed to run yarn command "import":
yarn import v1.22.22
info found npm package-lock.json, converting to yarn.lock
error Failed to import from package-lock.json, source file(s) corrupted

Though if you install with normal Node then it works after switching to Electron so it's more an issue with npm install than actually running.

I think we should fix that (in LSP-some-sass) before releasing.

[rchl]

So I think it's an issue with using yarn and it not being compatible with package lock version 3. It might be fixable by just creating lock file with older npm version.

[rchl]

And before merging this one, a new tag needs to be added in the repo.

[predragnikolic]

Pardon for the rush