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
The VSCode extension serves as a wrapper for the language server, while the language server, in turn, acts as a wrapper for the language service. This separation, though common, presents challenges for contributors in local development. Additionally, when a patch is applied to the language service, the current practice necessitates making corresponding patches to both VSCode and the language server in the development chain. Adopting a monorepo architecture could simplify this process, while also not compromising independent development and deployment.
✨ Do you have a proposal for making it better?
We should either create a new repository that includes all components—Cucumber VSCode, language server, and language service—or reuse the existing VSCode repository with the language server and language service integrated.
📚 Any additional context?
I notice that we have moved away from the monorepo approach, but for these packages, it may not be worthwhile. Some popular VSCode extensions follow this architecture, like robotframework-lsp and tailwindcss-intellisense.
How to test across different source code versions of two components. For example, an in-development language-server change against an in-development language-service change of another contributor on a different branch/fork.
"presents challenges for contributors in local development" - would you be able to outline some of these challenges? Can you think of any other opportunities that might mitigate or resolve these challenges?
Will close this for now @binhtran432k, had a look at alternatives and some other repositories but unfortunately haven't located a suitable mitigation for the mentioned issues. Will keep an eye on this and reopen if encounter a suitable option; will also continue to work on improving the development experience and documentation. Appreciate your support as always.
🤔 What's the problem you've observed?
The VSCode extension serves as a wrapper for the language server, while the language server, in turn, acts as a wrapper for the language service. This separation, though common, presents challenges for contributors in local development. Additionally, when a patch is applied to the language service, the current practice necessitates making corresponding patches to both VSCode and the language server in the development chain. Adopting a monorepo architecture could simplify this process, while also not compromising independent development and deployment.
✨ Do you have a proposal for making it better?
We should either create a new repository that includes all components—Cucumber VSCode, language server, and language service—or reuse the existing VSCode repository with the language server and language service integrated.
📚 Any additional context?
I notice that we have moved away from the monorepo approach, but for these packages, it may not be worthwhile. Some popular VSCode extensions follow this architecture, like robotframework-lsp and tailwindcss-intellisense.
This text was originally generated from a template, then edited by hand. You can modify the template here.
The text was updated successfully, but these errors were encountered: