You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this is Christian from the WebStorm team at JetBrains and we have been working on integrating the Astro LS for our most recent version but noticed an unexpected issue close to release that we'd like to raise with you in order to discuss whether you would consider fixing it on your end before we build some unconventional workarounds.
During the startup of the language server it attempts to load prettier and the prettier plugin for the purposes of initializing the Volar services:
"Couldn't load `prettier` or `prettier-plugin-astro`. Formatting will not work. Please make sure those two packages are installed into your project.",
type: MessageType.Warning,
});
}
returnprettier;
However, if no instance of prettier was found then the upstream volar-service-prettier will throw an error and prevent the Astro LS from starting at all. While it is true that this is fixed once the user installs those two peer dependencies (prettier and the plugin) explicitly into their project, this is not necessary when using VSCode. The readme does mention this, but I had the assumption this formatting is optional and not required.
Seemingly, the VSCode Astro plugin is silently (and unconventionally) installing the LS into the node_modules together with prettier and the plugin and thus the LS is able to pick up those dependencies. I came to this conclusion after creating a fresh Astro project that caused the LS to fail in WebStorm and noticed that opening it once in VSCode and then again in WebStorm causes no more issues until I noticed that the node_modules folder has been changed.
I would like to propose to make the detection and inclusion of the prettier service more robust and optional, i.e. making the following function call be handled more gracefully or the implementation check whether the dependencies exist in the first place before attempting to initialize the Volar service. Calling the create function from volar-service-prettier with no instance causes the failure to start.
I'm open for discussions and willing to contribute the necessary changes to handle this use-case more gracefully than before if there are no objections.
Steps to Reproduce
npm init astro
Open the project outside of VSCode in any editor/IDE that supports the language server, but hasn't prettier or prettier-plugin-astro installed
The LS is not starting at all
The text was updated successfully, but these errors were encountered:
After a quick conversation with @Princesseuh we noticed that this issue has been fixed last week as part of upstream changes that were done in volarjs/services#84 and then pulled in via #823. The problems are no longer occurring in newer versions of the LS.
Describe the Bug
Hey everyone,
this is Christian from the WebStorm team at JetBrains and we have been working on integrating the Astro LS for our most recent version but noticed an unexpected issue close to release that we'd like to raise with you in order to discuss whether you would consider fixing it on your end before we build some unconventional workarounds.
During the startup of the language server it attempts to load prettier and the prettier plugin for the purposes of initializing the Volar services:
language-tools/packages/language-server/src/languageServerPlugin.ts
Lines 98 to 107 in 6fd9314
However, if no instance of prettier was found then the upstream
volar-service-prettier
will throw an error and prevent the Astro LS from starting at all. While it is true that this is fixed once the user installs those two peer dependencies (prettier and the plugin) explicitly into their project, this is not necessary when using VSCode. The readme does mention this, but I had the assumption this formatting is optional and not required.Seemingly, the VSCode Astro plugin is silently (and unconventionally) installing the LS into the
node_modules
together with prettier and the plugin and thus the LS is able to pick up those dependencies. I came to this conclusion after creating a fresh Astro project that caused the LS to fail in WebStorm and noticed that opening it once in VSCode and then again in WebStorm causes no more issues until I noticed that thenode_modules
folder has been changed.I would like to propose to make the detection and inclusion of the prettier service more robust and optional, i.e. making the following function call be handled more gracefully or the implementation check whether the dependencies exist in the first place before attempting to initialize the Volar service. Calling the
create
function fromvolar-service-prettier
with no instance causes the failure to start.language-tools/packages/language-server/src/languageServerPlugin.ts
Line 55 in 6fd9314
I'm open for discussions and willing to contribute the necessary changes to handle this use-case more gracefully than before if there are no objections.
Steps to Reproduce
npm init astro
The text was updated successfully, but these errors were encountered: