Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Separate language support from vscode-R again

Abierto
  • ¿Algo no está bien?
#1,749 6 comentarios 3 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
r, typescript, vscode
Área
developer-experience, tooling

Línea de trabajo

The issue names no implementation files or tests. Start by reviewing the existing language-server integration and related issues #1540 and #1648, then compare the proposed minimal extraction with the extension-pack structure. Done would be an agreed extraction approach with minimal behavior changes; the larger runtime split is explicitly separate.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I would like to reconsider separating the language-server integration from vscode-R, similar to the old vscode-r-lsp, and eventually make REditorSupport.r an extension pack / umbrella extension.

When vscode-r-lsp was merged into vscode-R in 2.1.0 (#695), languageserver was effectively the standard choice for R language intelligence.
That is no longer the case.

The R editor ecosystem now has several actively developed, independently distributed tools with VS Code extensions:

  • Air provides a very fast Rust-based formatter and language server.
  • Jarl provides a fast Rust-based linter with diagnostics and automatic fixes.
  • Arity provides a full Rust-based language server with completion, hover, go-to-definition/references, rename, diagnostics, semantic tokens, and more.
  • Posit's Oak may become another standalone R language server in the future.

In particular, these newer tools are designed around fast static analysis.

Given this ecosystem, it no longer seems ideal for vscode-R itself to own one particular LSP client/runtime combination.
VS Code ecosystems such as Python and Java also separate language support and other tooling into independently maintained extensions, often combined through an extension pack.

A possible long-term structure would be:

REditorSupport.r          # extension pack / main entry point
├─ REditorSupport.r-syntax
├─ REditorSupport.r-runtime
└─ REditorSupport.r-lsp   # current languageserver-based integration

r-lsp could remain the default language support installed by the pack, while users could disable or replace it with Air, Jarl, Arity, or future alternatives without fighting functionality bundled into the main extension.

The first step could simply be extracting the existing LSP client with minimal behavior changes.
A larger runtime split can be discussed separately.

Related to #1540, #1648

Lenguaje dominante
TypeScript
Estrellas
1.2k
Forks
139
Merge medio
20 h 32 min
PR fusionados (30 d)
25

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de REditorSupport/vscode-R

Todos los issues de REditorSupport/vscode-R

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.