Vscode: Agregue soporte para abrir múltiples carpetas de proyectos en la misma ventana

de acuerdo, pero tal vez sea una solución optimizada para la memoria

+1

No estoy seguro de entender la pregunta; es un editor de código liviano, no un IDE ... ¿por qué necesitaría abrir múltiples carpetas de "proyecto" que no son jerárquicas (donde podría establecer la ruta de trabajo a un padre mutuo)?

Si está trabajando en módulos que están almacenados de forma desigual en el disco que de alguna manera interactúan entre sí en ese grado, entonces están demasiado estrechamente acoplados para empezar ... ¿son sus proyectos hermanos? Si es así, simplemente abra la carpeta principal, o la carpeta principal / principal ... donde sea que esté la raíz de su "solución".

Bueno, si tiene varios módulos (que están todos en su propio repositorio de git) que son independientes entre sí, pero tiene un repositorio que usa esas dependencias, tiene sentido poder abrir estas carpetas independientes y hacer cambios que reflejarse para que pueda probarlo localmente. ¡Eso seguiría siendo un editor de código ligero pero más útil en mi humilde opinión!

El problema principal con la configuración del proyecto como padre es que la integración de git desaparece; sin embargo, hay otros casos de uso válidos más allá de tener un padre mutuo.

@stoffeastrom suena como un caso de uso para submódulos; No estoy seguro de cómo su proyecto haría referencia a otro, a menos que estuviera creando un alias con algún mecanismo, como el enlace npm, etc. Este problema es lo que los administradores de paquetes están destinados a resolver en gran medida. Si los módulos están estrechamente acoplados, en realidad no son módulos aislados. No podría realizar cambios confiables para respaldar un proyecto sin preocuparse de que el cambio tenga consecuencias para otros consumidores en el futuro. Incluso con los submódulos, son de solo lectura por defecto exactamente por esa razón.

En cualquier caso, lo que @Tyriar acaba de mencionar es una de las razones por las que desconfío de tener este tipo de interfaz de ruta de trabajo múltiple en una sola instancia / ventana: tienes que manejar integraciones (como git), extensiones, refactorización, depuración, etc, etc, etc. todo de alguna manera aislada. Por ejemplo:

Si uso la integración de git para confirmar, ¿estoy comprometiendo el proyecto A o el proyecto B?
Si refactorizo ​​el nombre de una clase en TypeScript, ¿debería refactorizarlo en el proyecto A o en el proyecto B, o en ambos? ¿Qué pasa si existe el mismo nombre de clase en ambos proyectos con diferentes significados? ¿Qué pasa si uno se refiere libremente al otro?

Estos son solo algunos ejemplos de cómo algo aparentemente simple puede volverse muy complicado, muy rápidamente. Creo que sería mucho más confuso y, francamente, menos útil que alt-tab / cmd + tab entre algunas instancias separadas de VSCode, cada una administrando felizmente su propia ruta de trabajo aislada sin todo el esfuerzo adicional y los problemas de casos extremos.

No digo que no se pueda resolver, pero no entiendo por qué cambiar entre múltiples ventanas y / o instancias es un problema. Quizás me estoy perdiendo algo ...

Sublime, Atom, Webstorm: también son editores de código "ligeros" (excepto quizás Webstorm) y permiten abrir varias carpetas raíz desde diferentes ubicaciones. Estos editores son probablemente el 99% de lo que utilizan los desarrolladores web.
El código puede competir con ellos con un soporte de TypeScript mucho mejor (y será muy popular considerando que Angular 2 está por llegar) pero solo si les da a los desarrolladores lo que usan ahora como una funcionalidad básica.

+1

+1

Como desarrollador de Go, encuentro esta función extremadamente útil en Sublime o IntelliJ Idea. Por ejemplo, mi pequeño proyecto importa código de la biblioteca principal de Go o puede importar alguna biblioteca de terceros. Así que necesito poder navegar rápidamente hacia ellos y leer ese código.

+1. Las soluciones de microservicio de repositorio multi-git son muy dolorosas en VS Code en este momento, pensando en encontrar otro IDE compatible con Typescript.

Definitivamente necesitamos algún tipo de "solución". Soy un desarrollador nativo, y esto casi siempre implica la creación de un conjunto de libs / dll y luego hacer referencia a ellos desde algún proyecto de aplicación de host.
Una vez que tenemos varios proyectos, también necesitamos un 'proyecto de inicio' para cuando presionemos 'ejecutar'.

También me gustaría soporte para proyectos y múltiples raíces git. El código que uso con frecuencia se encuentra en varios repositorios de git y no poder cambiar entre ellos sin cerrar mi espacio de trabajo actual y abrir otro solo para dar la vuelta y cerrar ese para abrir el anterior es agotador. Si agrego la carpeta principal donde se encuentran todos mis repositorios, obtengo la capacidad de navegar y buscar entre mis archivos, pero pierdo la integración de git. Es un verdadero fastidio.

La línea entre "editor de texto" e "IDE" es bastante borrosa y realmente no me importa cómo se etiqueta VS Code. Lo que me importa es lo que puede hacer una herramienta y lo indoloro que es de usar. Creo que agregar apoyo al proyecto aliviaría muchas fricciones para personas como yo.

También me gustaría ver que la integración de git funcione cuando su espacio de trabajo contiene múltiples repositorios, pero solo quiero asegurarme de que personas como @ Loren-Johnson se den cuenta de que pueden tener múltiples ventanas de código vs abiertas simultáneamente.

Esto es en respuesta a: "no puedo cambiar entre ellos sin cerrar mi espacio de trabajo actual"

¿Quiere decir que el número 2686 es un duplicado de esto?

Lo siento, leí mal la descripción y volví a abrir esta.

+1

¿Hay algún progreso en este tema, o al menos alguna declaración si alguna vez se implementará? ¿Hay algunas decisiones de bajo nivel en el código que impiden tener múltiples raíces en un proyecto?

Esta es prácticamente la única razón por la que no voy a pasar de ST3 a VSCode.

+1

+1

+1

+1 esto sería muy útil. La sugerencia de usar submódulos de git es muy inconveniente. Me encantaría tener esta función.

Un enfoque ligero inicial sería algo similar a lo que hace la extensión git-project-manager . El enfoque podría ser básicamente cambiar el contexto / raíz de lo que git ve como cambios, pero sin cambiar el contexto / raíz de lo que ve el navegador de archivos. Esta extensión funciona perfectamente, solo necesita una integración más estrecha para que el cambio sea más rápido.

+1

+1: comencé a seguir el camino del uso de submódulos de git, pero se siente más como un truco que como una solución real.

+1

+1

Estoy usando la extensión git-project-manager para cambiar entre carpetas, pero realmente me encantaría tener una opción para abrir varias carpetas a la vez.
+1

Solo quiero decir que el propietario de la extensión Project Manager también está esperando este problema.

Con respecto a algunos de los comentarios (arriba), solo quiero decir que todos somos diferentes, todos tenemos nuestras formas particulares de ejecutar nuestro trabajo en nuestros proyectos particulares. Ese hecho hace que UX sea más importante de lo que ya es.

Todos sabíamos que "Abrir carpeta ..." era solo el primer paso para tener inevitablemente la gestión de proyectos en vscode con cosas como "Abrir proyecto ...", etc. Al igual que todos los demás editores, especialmente SublimeText (que es de donde vengo).

Para mí, este problema es una mejora de la UX del producto. Y todos sabemos que UX es el rey.

Casi siento que este tipo de cosas deberían ser la ley y, por lo tanto, la etiqueta "solicitud de función" debería ser "recordatorio de función".

Este problema debe tener la máxima prioridad sobre cualquier otro problema en vscode. No solo porque UX es el rey, sino porque no estoy experimentando ningún otro problema con vscode en este momento además de este ... técnicamente.

Originalmente estaba navegando para pedirle a Microsoft que se haga cargo de estas extensiones similares a proyectos e integre directamente en VSCode, y mejore su UX, por ejemplo, agregando "Proyectos ..." al menú.

Gracias,
+1

+1

Mi caso de uso para esta función se describe aquí: # 9515. (Se cerró como un duplicado de este problema).

¡Espero que suceda esta característica!

+1

@ poidl, @ mastrauckas , @mdedgjonaj , @alanleite , @Xcorpio , @mibanez , @josebalius y @brusbilis :
Hace un tiempo, GitHub introdujo la encantadora característica "Agrega tu reacción" (¿ves el emoticón en cada esquina superior derecha de un comentario o el problema en sí?).
Aquellos tienen el propósito de informar al equipo de VSCode sobre su interés, pero evitan comentarios +1 . También evita que otras personas que se suscribieron a un determinado problema o MR obtengan una notificación y, por lo tanto, ahorra un tiempo valioso. Otra ventaja es que los problemas / MR se pueden ordenar por most reaction que hace que el equipo de VSCode pueda ver instantáneamente lo que es relevante para los usuarios. Además de eso, incluso hay una Uservoice para VSCode .

Este comentario en sí es meta y, por lo tanto, tampoco tiene sentido. Lo siento, pero pensé que era necesario con fines educativos. Cada respuesta directa a este comentario (= más meta) resultará en que bloquee al usuario.
¡Hagamos ejercicio reaccionando solo a este comentario usando la función reaction !

A la respuesta de @poidl : ¡Entonces no respondas en absoluto!

No veo esa carita sonriente. Al menos en el móvil. ¡Feliz bloqueo!

@poidl sí, la función de reacciones no está disponible en el sitio móvil de GitHub, lamentablemente (junto con muchas otras funciones). Puede acceder a él en el dispositivo móvil presionando el botón "Versión de escritorio" en la parte inferior del sitio.

Sin embargo, el consejo de @ dj-hedgehog es acertado, las reacciones de GitHub nos permiten medir el interés de la comunidad en algo de manera más efectiva que el recuento de comentarios. Además, estamos planeando desaprobar User Voice para que los problemas y reacciones de GitHub sean nuestra fuente de verdad para las solicitudes de funciones.

+1

+1

Mi solución a este problema: crear un enlace simbólico a la raíz de mi proyecto.
Entonces, si tengo:
project/modules/gitmodule

Entro en mi carpeta gitmodule y hago:
ln -s ../../../project .project

Ahora puedo abrir mi carpeta gitmodule en vscode y todavía tengo acceso a la carpeta del proyecto principal.
Utilizo un punto en el nombre del archivo para que aparezca en la parte superior de mi lista en el explorador.
Obviamente, preferiría no tener que hacer esto, pero pensé que podría ser útil para algunos de ustedes.

Casi lo olvido: no olvide agregar el enlace simbólico a su .gitignore

+1

Esta es una característica realmente importante para un editor de texto moderno. Por favor, resuelva ese "problema".
Durante un tiempo, he tenido que copiar y pegar todos los directorios que se utilizan en mi carpeta de trabajo real y esto en Sublime Text es tan trivial.

Proyecto> Agregar carpeta al proyecto en Sublime Text incrementa una nueva ruta a la estructura Json.

Mira abajo:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

Cuando se trabaja con el chef, por ejemplo, es común ver una estructura de carpetas como:

└── cookbooks
    ├── cookbook1
    ├── cookbook2
    ├── cookbook3
    └── cookbook4

Donde los libros de cocina (cookbook1 por ejemplo) en la carpeta raíz (cookbooks) son los repositorios de git independientes. Esto es muy común. Ahora tienes que trabajar en cookbook4 pero incluye cookbook2 y cookbook3. A menudo, necesitará abrir los 3, ya sea para simplemente hacer referencia al código o para editar o refactorizar el código en los 3.

Las 2 opciones normales (no trucos de enlaces simbólicos) presentan problemas que ningún desarrollador quiere:

1. Como se mencionó anteriormente muchas veces, ahora tendría que abrir varias ventanas (no es bueno)
2. Si abre libros de cocina como root para ver los 3, perderá la integración de git, ya que la carpeta de libros de cocina no es un repositorio obtenido (tampoco es bueno)

+1, usuario de Eclipse IDE aquí que tiene la función de control total del 'espacio de trabajo'.

Visual Studio Code no es un IDE. Es un editor multiplataforma ligero, como Atom o Sublime. Eclipse, Xcode, Visual Studio, et. todos son gigantes en comparación.

Lo siento, no estoy seguro si está discutiendo en contra o a favor de esta característica ... Atom, Sublime, VIM, Emacs le permiten abrir varias carpetas en una sola instancia. Ligero o no es una buena característica, IntelliJ IDEA, un IDE, por ejemplo, no le permite abrir varios proyectos todavía.

@dmccaffery, las características que se solicitan aquí no son solo características IDE. Las características que se solicitan son comunes a todos los _editores_ que dijo que Visual Studio Code es _like_.

Atom, Sublime y otros editores ligeros pueden abrir varias carpetas.

A mí, personalmente, no me importa si esta función termina en el producto o no; entiendo por qué algunas personas la quieren, pero debo señalar que hace que todo sea un poco más complicado. Por ejemplo: al buscar usando una expresión regular, ¿qué espacio de trabajo estoy buscando? ¿uno? ¿todas?

¿Qué sucede si tengo una carpeta que contiene un proyecto de nodejs donde el ancho de mi pestaña suele ser de 2 espacios, y una carpeta es un proyecto de dotnet donde el ancho de mi pestaña es de 4 espacios? El código debería conocer la configuración del espacio de trabajo para cada carpeta y mantener el contexto en todo momento.

Estos son solo algunos ejemplos de situaciones en las que varios espacios de trabajo dentro de una sola instancia pueden resultar difíciles. Todo lo que digo es que esta función es mucho más complicada que simplemente mostrar múltiples rutas en el explorador.

@dmccaffery no es más complicado que sublime y atom. Todo esto debería ser configurable, incluso los anchos de pestaña por espacio de trabajo. La búsqueda en atom y sublime puede estar solo en el archivo actual, en este espacio de trabajo, etc ... es su elección.

Aquí hay un hecho, te guste o no y no tiene nada que ver con lo que tú o yo queremos. Si otro software similar a un precio similar (gratis en este caso) tiene mejores o más características, y el desarrollador descuida este hecho, este software se quedará atrás.

Por mi parte, no me gustaría que eso le sucediera a este editor. Creo que este editor tiene un potencial muy bueno y puede seguir siendo relevante durante algún tiempo _si_ los desarrolladores escuchan los deseos / necesidades de su base de usuarios.

Otra vez; No estoy argumentando a favor o en contra, solo tenga en cuenta que este es un editor muy nuevo con un contexto mucho más innovador que sus competidores, déle algo de tiempo.

Incluso en su ejemplo con la integración de chef y git, ¿cómo mantiene el contexto en cuanto a con qué repositorio se está comprometiendo? La interfaz de usuario actual debería adaptarse al cambio de contexto constante, lo mismo para OmniSharp, que utiliza un servidor y roslyn para proporcionar resaltado de sintaxis, etc. para proyectos CoreCLR. Las implicaciones son de gran alcance y deberán ser muy bien pensadas.

No hay discusión sobre la idea de que las características deben estar bien planificadas y pensadas. Eso es un hecho, creo. Creo que todos los usuarios estarían felices si la respuesta aquí fuera "está en la hoja de ruta" o "estamos trabajando para ese fin". Todo lo que digo es que un "no" probablemente mataría a bastantes usuarios de la noche a la mañana.

En cuanto al cambio de contexto y los repositorios de git en chef, sí de acuerdo ... todo esto es cierto y ya se ha logrado en otros editores de código abierto. ¿Sabes lo mejor del código abierto? ¡Es abierto! Mire el código, obtenga ideas, diablos, incluso use parte de él (asegúrese de incluir licencias según sea necesario). Esa es una de las mejores cosas de foss (software de código abierto gratuito), la colaboración y el intercambio de conocimientos. Dado que este editor ya está usando código atom ... creo que esto también sería un hecho.

Encontré esto mencionado en https://github.com/Microsoft/vscode/wiki/Roadmap

VS Code es un producto joven y todavía faltan características y experiencias que usted está solicitando y que queremos ofrecer.
....
....

• Varias carpetas dentro de un solo espacio de trabajo

Creo que nadie dice que esta función es simple (ya que todos somos desarrolladores, podemos saber qué es necesario cambiar) y las personas invitadas comentan este boleto solo quieren mostrar lo importante que es, qué prioridad debe ser, y cómo comparar esta función con algunos hermanos VS Code (Atom, Sublime, por ejemplo).

Pero debido a que esto ya está en la hoja de ruta (cualquiera puede confirmar que la página wiki aún es correcta), deberíamos discutir sobre cómo implementar esto en lugar de simplemente decir cómo lo necesitamos y qué tan importante es (como nuevamente, supongo que el equipo central de VS Code ya sabemos cómo lo necesitamos y lo importante que es esta función).

No estoy familiarizado con el código fuente de VS Code, ¿alguien puede decirme si quiero implementar esta función, dónde debo buscar primero? En el primer paso, solo quiero abrir varias carpetas y mostrarlas en la barra izquierda.

@nvcnvn no es tan trivial como podría parecer implementar esto, ya que muchos vscode asumen que solo se puede abrir una carpeta. Como tal, necesitará pasar por UX y probablemente tocar muchas partes del código base, potencialmente con impactos en la API de extensión también.

Recuerdo cuando salió Atom, con la misma limitación de _carpeta única_. Las quejas también fueron las mismas, especialmente las comparaciones con Sublime. Luego, cuando se lanzó la compatibilidad con _múltiples carpetas_, algunos paquetes (extensiones) se rompieron debido a la nueva API. Otros no se rompieron pero tampoco lo apoyaron. Pasó algún tiempo hasta que se volvió _estable_ en todo el ecosistema.

Como dijo @Tyriar , habrá cierto impacto en la UX y la API de extensión, y probablemente será un lanzamiento de _Insider_ ocupado para los desarrolladores de núcleo y extensiones, para adoptar la nueva API.

Entonces, ¿qué se está discutiendo exactamente aquí?
Quiero decir, todo lo que veo es "no hacer mejoras porque podría romper cosas" ...

Insinuación:
¡TODAS LAS MEJORAS EN EL CÓDIGO PUEDEN ROMPER ALGO!

Ese es el punto de depurar, refactorizar, prelanzamientos (alfa, beta, rc, etc ...)
Vamos, en serio? Nunca conocí a un programador serio que tuviera miedo de mejorar el código porque podría romper algo. Ten cuidado, sí, tómate tu tiempo y mantente a salvo, sí, pero nunca digas "no, podría romper cosas" jejeje

@ddreggors No estoy discutiendo, simplemente estoy indicando información sobre el problema. Dije lo que dije para que @nvcnvn no intente construir un PR para esto, ya que esto deberá hacerlo el equipo debido a la lista de partes interesadas.

Como señaló @nvcnvn , este problema está en la hoja de ruta, lo que significa que el equipo lo analizará pronto. Somos un equipo relativamente pequeño, sin embargo, con muchas cosas que cubrir, por lo que algunas cosas deben retrasarse.

@Tyriar Entendido, sigo viendo estos comentarios de varias personas que parecen sugerir que es mejor no agregar esta función por una razón u otra. El peor de los cuales se debió al hecho de que el código no es un IDE, cuando otros compararon claramente a otros editores que no son IDE. Me hizo querer llegar a la raíz del miedo a este cambio para superarlo si es posible.

Puedo entender la preocupación de que ese PR no esté completo, sin embargo, podría ser un buen comienzo ... fusionar ese cambio en una rama y usarlo como base. Úselo para ver roturas y arreglarlas.

@ddreggors , sería una pérdida de tiempo que cualquiera tocara esto antes de que se reuniones de UX

Bastante justo, usted sabría mejor en ese extremo. Sin embargo, es bueno saber que esto se está discutiendo. :-)

Gracias por los esfuerzos y lo que parece el comienzo de un muy buen editor.

También parece ser un esfuerzo en vano sugerir este tema para sus reuniones de UX :–)

Cambié temporalmente a Atom ya que se ha vuelto mucho más estable en la versión 1.9. Solía ​​fallar cuando se abría cualquier archivo grande y esa fue la razón principal por la que comenzó a verificar VSCode en algún momento. Tengo muchas ganas de ver varios proyectos en una ventana; parece que no tengo nada que hacer más que seguir este hilo hasta entonces.

¿Por qué la gente de Microsoft no se concentra en esto?

+1

+1

Realmente amo VS Code. Se ha convertido en mi editor principal, pero la dificultad de trabajar en más de 2 proyectos a la vez se está volviendo confusa. Hay un doble golpe en estos dos problemas abiertos: este y la configuración de la información de la barra de título .

Cualquiera de estas características resolvería el problema (aunque idealmente, ¡me gustaría ambas!). No me importa poner todo con lo que trabajo en una sola carpeta y abrirlo, pero la integración de git no funciona y no hay una forma trivial de buscar solo dentro de un proyecto u organizar los resultados por proyecto.

No me importa abrir cada proyecto en una ventana física de VS Code diferente y dejar que mi sistema operativo administre las instancias, pero debido a que la barra de título muestra primero el nombre del archivo abierto, en lugar de un identificador de carpeta raíz / proyecto, es imposible cambiar a otro proyecto abierto específico sin abrir y mirar cada instancia activa. Convierte algo que debería ser fácil en una molestia constante.

Por favor, ¿hay alguna forma de que añadir una de estas dos funciones se convierta en una prioridad? Intenté todo lo que se me ocurrió para solucionarlo, incluso pasé una hora buscando alguna alternativa a la barra de tareas de Windows que me permitiera elegir ventanas de una lista que podría mostrar más texto en la barra de título, pero no puedo encontrar cualquier cosa.

Si alguien tiene alguna sugerencia sobre cómo administrar múltiples proyectos abiertos de VS Code de manera efectiva, me encantaría escucharla.

Lo importante que funciona bien en Atom es que los complementos, como eslint, aún deberían funcionar a nivel de proyecto. Entonces, si el Proyecto A tiene sus propias reglas de eslint, el Proyecto B no debería verse afectado por esas reglas y viceversa. No puedo esperar a tener tal UX en Code. Este es definitivamente uno de los mayores obstáculos de adopción en este momento, si no el más grande.

Esto es lo único que me obliga a adoptarlo.

Sé que es posible que tenga muchos otros problemas que solucionar y otras funciones que implementar, pero al menos un soporte básico para comenzar sería increíble.

¡Gracias por el arduo trabajo en VSCode!

+1

Hasta que se implemente esta función (si alguna vez se implementa), le sugiero que simplemente agregue la capacidad de configurar la barra de título para mostrar el nombre del proyecto antes del nombre del archivo. De esta forma al menos será posible distinguir entre las diferentes ventanas de vscode que están abiertas para los diferentes proyectos. Vea el n .

Esto también es un tapón para mí. Veo que algunos desarrolladores se preguntan por qué tiene varios repositorios de git a la vez. Esto sucede con casi cualquier lenguaje que utilice módulos de terceros. Solo mire php - composer, js - bower, node - npm, golang, etc. Es muy común comenzar un proyecto que usa algunos de sus módulos y desea editar y confirmar los cambios en el alcance del proyecto.

¿Existe al menos soporte para reconocer .vscode/settings.json en directorios anidados? Cuando se trabaja en un solo proyecto, puede haber subárboles con diferentes conjuntos de configuraciones y que vienen de diferentes repositorios (git). p.ej

root/
    server/
        .vscode/
            settings.json // <== affects all files in the server/ directory
        code/
            tsconfig.json
            foo.ts
    client/
        .vscode/
            settings.json // <== affects all files in the client/ directory
        code/
            tsconfig.json
            foo.ts
    .vscode/
        settings.json // for any file not in server/ or client/

Esperaría que vscode tomara (y tal vez fusionara) la configuración del directorio principal más cercano como muchos archivos de configuración ( .eslint , .gitignore , .editorconfig , tsconfig.json , 'paquete.json` ....).

Entonces, cuando abro /root , cualquier archivo en root/server/ debe manejarse como si abriera root/server/ directamente. La solución más simple sería dejar de buscar configuraciones en los directorios principales cuando se encuentre un archivo .vscode/settings.json .

Esto es realmente necesario.

+1. Dealbreaker para mí.

Esto es realmente necesario. +1

Existe una solución alternativa para anidar carpetas en un espacio de trabajo de vscode. solo para crear un enlace de símbolo a la carpeta del espacio de trabajo, como este mklink /d link target

Estoy de acuerdo, creo que esta solicitud es un requisito definitivo.
No siempre tienes un proyecto en una sola carpeta; puedes tener carpetas auxiliares y hermanas y no tener esta función es un factor decisivo para mí en este momento; por eso tengo que usar sublime.
¡Por favor agréguelo!

En el lado izquierdo, muestra la carpeta en la que se encuentra como proyecto. Esto podría funcionar si lo tuviera donde pueda ver cada área de carpeta (proyecto) abierta allí. Puede expandirlo y contraerlo como lo hace ahora (pero para múltiples áreas de carpeta).

Un editor increíble si pudiera cambiar entre dos proyectos. Un verdadero Dealbreaker.

Hola a todos, recomiendo la extensión Git Project Manager si cambian mucho entre proyectos mientras tanto. Escanea un directorio en busca de directorios que contengan una carpeta .git y permite cambiar rápidamente a ellos, lo he estado usando durante algunas semanas y ciertamente lo hace más fácil.

Cuando cambio de proyecto, voy:

1. ctrl + alt + p
2. Escriba el inicio del proyecto, por ejemplo. "vsc" para vscode
3. entrar

O si quiero abrir el proyecto en otra ventana, presiono ctrl + shift + n de antemano. Puedes configurar la extensión para que siempre se abra en una nueva ventana si eso también es lo tuyo.

Esta es una captura de pantalla sobre cómo puede tener fácilmente varios proyectos.

@ soljohnston777 el problema es que la integración de git (o cualquier otro tipo de configuración de código VS) no es compatible a nivel de carpeta.

el problema es que la integración de git (o cualquier otro tipo de configuración de código VS) no es compatible a nivel de carpeta.

¿Eh realmente? ¿VSCode repitió los errores que cometió el eclipse cuando se trata del concepto de espacio de trabajo? Eso sería sorprendente, sabiendo que bastantes miembros del equipo VSCode han sido parte del equipo central de eclipse ...

¿VSCode repitió los errores que cometió eclipse cuando se trata del concepto de espacio de trabajo?

No puedo hablar de la filosofía de los arquitectos aquí, pero este hecho (que la configuración es por instancia y no por carpeta) es la razón de este problema y discusión.

Puede usar ventanas VScode separadas para proyectos. ¿Por qué no implementarlo así dentro de VSCode? (Ventana separada por botón de proyecto lateral; solo haga referencia a él dentro). Se ahorraría la molestia de codificarlo dentro del programa, pero los proyectos se muestran en el interior y hacen que sea fácil de integrar y desarrollar.

Git se puede colocar de forma independiente para cada área de carpeta para múltiples proyectos ... Encuentro que el git es confuso con VSCode, así que tiendo a hacer la línea de comando de todos modos (que parece que debería poder hacer eso en VSCode).

Tener una carpeta principal que contenga subcarpetas que sean repositorios de git independientes es realmente útil cuando todas pertenecen al mismo proyecto. Me gustaría ver esto disponible, al menos con un indicador de configuración opcional en la configuración.

También me gusta expresar mi gran interés en tener soporte de git para múltiples repositorios de git.

+1. Esta es una característica principal que impide mi adopción de VSCode como mi editor principal.

+1

+1 - especialmente para las personas que trabajan con bases de código de microservicios / muchos repositorios, esto es clave. (Clave: no tenerlos todos abiertos a la vez, sino alternar entre ellos y hacer que el editor recuerde qué archivos estaban abiertos y en qué espacios de trabajo).

+1
Nuestra configuración es algo así como el código central en un repositorio GIT, un código regional en otro repositorio y un código específico del proyecto en otro repositorio, por lo que cuando trabajas en un proyecto necesitas codificar desde los tres (o más) repositorios. No poder tener un "proyecto" con su propia configuración específica y la capacidad de agregar múltiples carpetas desde múltiples fuentes es el rey de un bloqueador.

@danechitoaie, ¿cómo sabe que un cambio que realiza en su repositorio principal no interrumpe a otra persona que depende de él para una región o base de código de proyecto diferente? Parece una forma peligrosa de trabajar; Debería haber una gestión de versiones separada utilizando algún tipo de sistema de gestión de paquetes o similar.

Sin argumentar en contra de alguna implementación de espacios de trabajo, pero un sistema de proyecto completo agrega una gran cantidad de complejidad.

De acuerdo, lo es y deberían / ​​podrían hacer muchas cosas mucho mejor, pero ... está fuera del control o capacidad de nuestros "usuarios mortales" para tomar decisiones ...

Entendido. Me encanta cuando pasa ese tipo de cosas.

¿Qué tal esto?

Para mí, un simple botón de cambio como ese no es suficiente. Si solo necesitamos así de simple, abra 2 instancias (ctrl shift N) y luego use la tecla de acceso rápido de su sistema operativo para cambiar entre ventanas / espacios de trabajo.
Me encanta tener algo que facilite la comparación de archivos, la estructura de los proyectos, algo que me ayude a hacer cambios menores rápidamente y construir y mantener todas las diferencias en la misma pantalla, capaz de revertir los cambios para todos los proyectos con los que estoy trabajando.

+1

+1

Tipo de solución alternativa para macOS Sierra.

Una pestaña por proyecto dentro de una ventana configurando Prefer tabs when opening documents en Always en la configuración del muelle. Pero también afectará el comportamiento de otras aplicaciones.

+1

Esto se está convirtiendo en un asesino para mí. Me encanta el programa, pero hombre, ¿no me gusta que uno solo tenga una ventana ...

Honestamente, tuve que dejar de usar Code porque, por mucho que me gustara, se volvió demasiado engorroso cambiar de ventana.

Si esto se soluciona en el futuro, lo intentaré nuevamente, hasta entonces, esto es un impedimento para mí y para todas las personas que lo probé.

+1

+1

Prefiera: +1: reacciones sobre el comentario del problema original, ya que nos ayuda a priorizar y no envía notificaciones a todos los que escuchan el problema para obtener actualizaciones.

+1

Actualmente estoy usando Sublime y probando Code. Se ve y se siente bien, pero la integración de Git en un solo proyecto es un factor decisivo. Tengo un proyecto Hadoop / Oozie, por lo que tengo un repositorio de código y otro de notas de trabajo. En Sublime, los tengo abiertos en la misma ventana y puedo comprometerme con el repositorio de Git apropiado para cada uno.

entonces, será bueno agregar

+1 sí, crítico en el mundo de los microservicios, es habitual tener 3..4 repositorios abiertos al mismo tiempo

Recordatorio semanal: deje de publicar comentarios con +1. En su lugar, apruebe el problema inicial, que en realidad se cuenta.

Sé que todos tenéis buenas intenciones. ¡Así que siéntete libre de borrar tu comentario +1 para que no ocupe espacio en este importante registro histórico también!

@jamietre Lo he intentado ... duro:

¿Quizás otra alternativa es bloquear este problema pero mantener abierto hasta que se resuelva? De esta manera, conocemos la importancia del problema (yo diría que ya tenemos suficientes +1 para él), pero no podemos agregar al desorden / redundancia (por ejemplo, no se permiten más comentarios).

Aunque creo que es una característica que rara vez se usa, solo encontré el bloqueo de un proyecto / repositorio público en Github.

El bloqueo podría desbloquearse cuando se considere necesario, si es que alguna vez lo hiciera.

@daluu, así es como funciona el repositorio de anuncios / aspnet /. todos los problemas se bloquean de inmediato. Dicho esto, GitHub debería hacer algo en la interfaz de usuario para, al menos, impulsar a las personas hacia alternativas más allá del "+1", ya que ahora existen reacciones. 👍

Es muy útil poner la función de ventanas múltiples en su conjunto, al mirar los documentos de más de dos proyectos,

enfoque interesante del problema. Fui programador de VB / .net durante muchos años, amaba los lenguajes y las herramientas, pero he estado ausente durante algunos años en Hadoop / Spark / Scala / Intellij / Sublime-land. Todavía escucho DotNetRocks, me gusta estar al día de lo que está sucediendo y estaba interesado en escuchar sobre esta aplicación de Código. En el lado positivo, es un editor muy agradable, con algunas características de Git atractivas, pero eso es totalmente irrelevante, desafortunadamente. Debido a que no maneja Git para múltiples proyectos en el mismo espacio de trabajo, como lo hace Sublime con mucha elegancia, entonces simplemente no puedo usarlo

Eso pasa. Lo que más me sorprende es la reacción aquí, primero afirmar que esta no es una característica necesaria, y luego la mayor parte de la discusión ahora parece girar en torno a "cómo podemos evitar que las personas publiquen +1"

Te diré cómo lo haces: ¡solucionas un problema básico que se planteó por primera vez hace un año! Se llama "escuchar comentarios". El hecho de que no esté personalmente afectado por un problema no significa que no exista. Si no desea que un grupo particular de usuarios use la aplicación, entonces está bien, pero no nos dé un mecanismo de retroalimentación, luego discuta nuestro problema y luego enfóquese con nosotros por seguir solicitándolo.

He vuelto a usar sublime

El problema "+ 1" se puede solucionar con el siguiente código: if (post_message == "+1") {add_smiley_reaction (); delete_post_message (); }

Estimado GitHub, estoy disponible para contratar.

sí, esto nunca se solucionará, ¿verdad? Es mucho más fácil burlarse e ignorar los comentarios "+1" en lugar de abordar realmente el problema central, el software se comercializa para una sección particular de desarrolladores que no hace lo necesario para que sean productivos ...

solo lea este "Cada respuesta directa a este comentario (= más meta) resultará en que bloquee al usuario". - ¡Así es como se gestionan los comentarios! Métete los dedos en los oídos y di "¡no te oigo!"

querido señor

@ kryps1 entonces la gente agregará "+ 1" o "++ 1" o "1+" o "bump" o "Sí, por favor. +1". Hagas lo que hagas, la gente encontrará una forma de evitarlo. No es tan fácil como crees.

Deténgase con el debate inútil de +1 , por favor ... Concéntrese en lo que se necesita aquí, que son múltiples proyectos en el explorador.

Para el problema git , solo tiene que dividirse de la misma manera que el explorador (es decir, por cwd).

No comencemos una guerra de llamas por las cosas +1. Definitivamente sería bueno que se diera prioridad a este tema.

Pero me gustaría mencionar a la comunidad, asumo que las relaciones públicas y las contribuciones son bienvenidas ;-) alguien puede parchear / arreglar el código si los desarrolladores principales no lo consiguen. He mejorado algunos de mis proyectos (con bifurcaciones) porque el usuario / desarrollador prefiere hacerlo ellos mismos que esperar a que yo haga las mejoras que les gustaría sugerirme. Entonces, ¿alguien que esté molesto por este problema y sea lo suficientemente capaz / capacitado, por favor corríjalo (luego envíe un PR)? jajaja

Y volviendo al tema de +1, resaltar el problema y agregar su opinión es bueno, pero el +1 es una forma poco convincente de hacerlo si hay otros métodos disponibles, como la función de pulgar hacia arriba. Considere una publicación de Facebook, o la publicación original de Google+, y los usuarios / lectores agregan un comentario +1 en lugar de hacer clic en Me gusta (o una de las nuevas reacciones de Facebook), o +1 para Google+. Con el tiempo, ese es un hilo de comentarios largo de +1 poco convincentes, donde, como lector, podría estar desplazándome para ver comentarios interesantes, pero termino viendo un montón de +1. Esto es lo que estaba sucediendo aquí, preferiría no ver / leer estos +1, ya sea que sea un desarrollador de proyectos o solo un usuario (o estoy investigando este proyecto para un uso potencial).

En una nota relacionada, aquí hay un uso tonto (pero con buena intención) de un problema de GH, gracias a Dios, la gente no hizo +1 en él: https://github.com/sinatra/sinatra/issues/920

Asumo que los RP y las contribuciones son bienvenidos

Realmente no. Vea este comentario de agosto: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

Aparentemente, este tema está en la Hoja de Ruta desde al menos entonces, pero no ha habido ningún progreso al respecto. Sería bueno escuchar una actualización de estado del equipo de VSCode.

Para mí, y esto está tratando de volver a encarrilar el tema, se necesitan varias carpetas de proyectos.

En Atom, es compatible con GIT, y la única forma en que lo uso es anotar qué archivos tienen cambios. Tengo un servidor Rackspace que no permite SSH, así que voy a realizar cargas manuales. Sin embargo, puedo tener varias carpetas de proyectos en la barra lateral y hace que sea mucho más fácil hacer referencia al código que he usado en un proyecto anterior. O cambiar de marcha a otro proyecto si necesito un respiro.

Con VSCode, el problema que me impide cambiar, y quiero cambiar, es la falta de varias carpetas de proyectos en la barra lateral.

Quiero decir, supongo que podría abrir la carpeta raíz para resolverlo temporalmente, pero si solo necesito 3/20 carpetas y no quiero ver los archivos sueltos, entonces esta debería ser una implementación fácil, ¿verdad?

Actualización: La gran actualización del banco de trabajo que viene pronto es la salida en caliente (# 101), mientras trabajamos en la salida en caliente, hemos estado discutiendo activamente este problema para garantizar que el diseño tenga en cuenta varias carpetas.

Este problema es actualmente el número 2 en términos de: +1: reacciones de todos los problemas (número 1 por un banco de trabajo etiquetado en mucho tiempo), como tal, es muy probable que este sea el próximo gran trabajo para el banco de trabajo después de la salida en caliente.

Activado: +1: comentarios; solo sirven para molestar a las más de 80 personas suscritas al problema. Sin embargo, votar sobre el tema con una reacción es una de las cosas más poderosas que puede hacer para influir en el proyecto.

También tenga en cuenta que somos un equipo relativamente pequeño y que la limpieza del código base y el rendimiento de vscode es muy importante, por lo que las cosas toman tiempo para hacer las cosas bien. Particularmente para algo como esto, que es un cambio fundamental en cómo se ha construido vscode hasta la fecha, hay bastante trabajo en este tema.

+1

De hecho, esa sería una característica útil.

Cambié de Atom y realmente me gustó, pero trabajo en dos aplicaciones de interfaz de usuario y otros 2 SDK, pero la incapacidad de cambiar entre esos proyectos (o carpetas) rápidamente es una falta importante, supongo que debería volver a Atom hasta que esto suceda. se resolvió

Tengo muchas ganas de esta función ~~~

Soy un desarrollador de golang que usa vscode, espero que esto tenga un implemento, ¡gracias!

Estoy intentando cambiar de Sublime a VScode. Y pronto descubrí que VScode no admite varias carpetas en un concepto de "proyecto", es realmente un problema que me impide hacerlo.

Realmente me encantan las otras características de este editor "ligero". Mientras tanto, creo que admitir varias carpetas en un "proyecto" no haría que VScode "sobrepeso" o "similar a IDE". Simplemente lo haría más conveniente para los desarrolladores que usan otros editores para hacer la transición mucho menos dolorosa.

Espero tener esta mejora. ¡Gracias!

Además, si el equipo puede agregar la capacidad de guardar la configuración basada en el proyecto, que anula la configuración predeterminada, será genial. El caso de uso es si puedo tener diferentes intérpretes para diferentes proyectos. De manera similar, también ayudará tener diferentes tamaños de pestaña, etc. Por favor, avíseme si esto ya se puede lograr de alguna manera.

Como desarrollador, siempre estamos trabajando en múltiples proyectos y tenemos proyectos paralelos propios. Personalizar la configuración del proyecto (configuración del espacio de trabajo para vscode) cada vez que cambio de proyecto es un gran problema.

@bajubullet Debería probar https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig No estoy seguro si cubre todo lo que necesita, pero es un comienzo.

@danechitoaie gracias por la respuesta. Sin embargo, EditorConfig no ayuda, puedo especificar propiedades por tipo de archivo, pero si puedo guardarlas como configuración del proyecto, será más fácil y no me gusta tener .editorconfig para cada proyecto. Además, en el caso de extensiones como la extensión de python, que nos permite proporcionar el intérprete que se utilizará, esto no ayudará porque python.pythonPath no es compatible con editorconfig. Por favor, avíseme si me falta algo aquí. Cualquier sugerencia es bienvenida.

Estoy de acuerdo, también estoy ansioso por algún tipo de configuración específica del proyecto y poder abrir varias carpetas "raíz". Es lo único que extraño de Sublime.

¡Esto se implementará pronto!

Así que no es necesario seguir agregando contenido a esta publicación. Si tiene otros problemas, cree un nuevo hilo. ¡Gracias!

Este es un hilo bastante largo y leí tal vez un tercio, pero solo quiero expresar mi apoyo. Acabo de instalar VS Code con https://github.com/JuliaEditorSupport/julia-vscode como posible sustituto de Atom / Juno. ¡Es bonito! 😍

Sin embargo, al desarrollar el código de Julia, creo que es muy importante poder abrir varios paquetes en diferentes carpetas. En principio, podría abrir la carpeta de arriba, pero eso expondría los cientos de paquetes de Julia que he instalado. También podría cambiar mi LOAD_PATH, pero preferiría una solución VS Code.

Sinceramente espero poder abrir varias carpetas. Gracias por los esfuerzos 👍

Hola a todos, como habrán notado, estamos explorando la implementación de este problema durante esta iteración.

De https://github.com/Microsoft/vscode/issues/17608

Investigar espacios de trabajo de múltiples raíces en los diferentes componentes @team

Espero conversar con 3 a 5 de ustedes sobre sus casos de uso mientras pensamos en los detalles de implementación. Si puede, regístrese para un intervalo de tiempo de 15 minutos el próximo martes. Me encantaría charlar.

cambiar entre mi api y ui me está volviendo loco ... :-(

@ehartford ¿ alguna razón en particular por la que no comparten un padre común?

Si. La integración de Git no funciona si abro el directorio principal.

@ehartford buena razón: sonrisa:

@waderyan, ¿está buscando casos de uso de _usuarios finales_ únicamente, o también _ desarrolladores de extensiones_?

Como _usuario final_, la compatibilidad con varias carpetas fue útil la mayoría de las veces para _fines de búsqueda_. Solía ​​crear proyectos agregando diferentes carpetas de diferentes API, solo para facilitar las búsquedas (unificadas). Diría que no extraño tanto hoy, y no me molesta tener múltiples ventanas VSCode hoy, especialmente después de que se agregó el comando Switch Window : +1:

Como _ desarrollador de extensiones_ tengo algunas extensiones que se basan en _Project Context_, como context.workspaceState , activationEvents/workspaceContains . Y también Project Manager , que por cierto ya comencé a refactorizar los componentes internos para admitir múltiples carpetas. Me encantaría saber cómo afectará esto a las extensiones.

Gracias

Para agregar a lo que dije anteriormente (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917), en realidad uso submódulos de Git, por lo que cuando estoy trabajando en mis propios paquetes (privados), Tiene mucho sentido agruparlos, pero como Julia es todavía bastante joven (relativamente hablando), a menudo necesito trabajar en otros paquetes además del mío. No siento una razón convincente para agregar estos otros paquetes como submódulos (aunque podría).

Generalmente, para el desarrollo de paquetes de Julia, estoy constantemente saltando entre paquetes, por lo que tener varias carpetas de proyectos sería genial: +1:

PD: MS, preste más atención a Julia;)

Caso de uso más simple: microservicios

Jaja. Sí @saada 👍 En realidad, fueron los microservicios los que nos llevaron a VS Code. Estamos utilizando Azure Service Fabric y mi socio creó los primeros microservicios en .NET y Rust. Estoy trabajando en los microservicios de Julia. Mi compañero es un tipo de VS y le gustó VS Code for Rust. Me sugirió que probara VS Code para Julia. ¡Gracias!

@saada definitivamente en el radar. ¿Puede responder estas preguntas para ayudarme a ser más claro en los requisitos?

1. ¿Sus microservicios comparten una carpeta principal? ¿Por qué o por qué no?
2. ¿Cada microservicio está separado en su propio repositorio de git? ¿Por qué o por qué no?

1. ¿Cada microservicio está separado en su propio repositorio de git? ¿Por qué o por qué no?

@waderyan una posible razón es que algunas plataformas PaaS populares como Heroku requieren que cada aplicación (microservicio) esté en un repositorio de Git separado. Deploy-via-git-push se ha convertido en una estrategia popular.

@waderyan Me inscribí para una ranura mañana y estoy llegue , pero en la línea de casos de uso como este, el nuestro es similar.

Somos una gran organización, tenemos un registro npm privado y publicamos nuestros propios módulos que se comparten dentro de la organización. Tenemos una aplicación de reacción con una base de código de cliente que es una gran aplicación que consume algunos módulos comunes (como bibliotecas de utilidades, componentes compartidos) y una base de código de servidor que también se compone de varios módulos (aplicación de servidor express, componentes de servicio de datos backend consumidos por el capa de servicio y los servicios reales expuestos al cliente). El desarrollo activo implica un mínimo de dos (el cliente y la capa de servicios), pero la resolución de problemas puede implicar fácilmente media docena de módulos.

Incluso cuando se utilizan módulos públicos de npm, en ocasiones es útil tener su código fuente vinculado directamente y abierto en una instancia de VS Code separada para solucionar un problema difícil, o incluso un error en un módulo de terceros, pero principalmente es nuestro propio código.

Cada uno son repositorios de git separados. No hay problema para mantenerlos en mi sistema de archivos en una sola carpeta raíz (lo haría de todos modos). Pero necesito tener una instancia separada de VS Code abierta para cada uno, y cambiar de un lado a otro es doloroso porque solo puede ver el nombre del archivo, no el nombre de la aplicación en sí. No hay forma de averiguar fácilmente qué aplicación / módulo / proyecto está abierto en qué ventana. El nombre del archivo en sí proporciona muy poca información útil para discriminar entre varias instancias de VS Code.

Hay otro problema abierto relacionado con permitir que la información de la barra de título sea configurable, sobre el cual también he comentado mucho, y que tampoco se ha resuelto. Si fuera posible tener el nombre de la carpeta raíz a la izquierda en la barra de título, el problema de tener varios proyectos abiertos sería un problema mucho menor, porque al menos podría ver qué instancia abierta era cuál dentro de Windows al cambiar de tarea. Esto parece que debería ser realmente trivial hacer configurable y al menos aliviaría el dolor de no poder abrir varios repositorios de git en una sola instancia mientras esto se resuelve ...

@waderyan

1. Mis proyectos web se gestionan mediante una única carpeta principal. Está configurado de esta manera para la organización y los enlaces rápidos para las carpetas de mi repositorio. También hago esto, ya que es fácil para mí cambiar a un proyecto anterior / actual para extraer muestras de código cuando se van a reutilizar. A diferencia de abrir otra ventana, es más fácil abrir otra pestaña y, en mi caso, es más eficiente en el tiempo.

2. Cada proyecto web tiene su propia integración de git, sin embargo, personalmente, no necesito que .git esté integrado en mi editor de código. Es una buena opción para mí, pero no un requisito. Tienen su propia integración .git debido a que desean mantener cada proyecto web por separado en mi host de repositorio.

@nickmak @jamietre @pesho gracias por compartir sus pensamientos. Esto es útil y espero conversar con muchos de ustedes mañana.

@alefragnani Estoy enfocado en el escenario del usuario final. Hemos abordado este problema con cautela debido al impacto en las extensiones. Pisaremos con cuidado y comunicaremos cualquier cambio de API. Envíeme un ping en Twitter si lo desea y podremos atender una llamada para discutir más.

incluso notepad ++ admite múltiples carpetas. es la razón por la que no puede dejar el bloc de notas ++.
este día trabajando con javascript necesita abrir múltiples proyectos.

Hago trabajo de software integrado y generalmente hay algunas carpetas en las que estoy trabajando en todo el sistema. Por ejemplo, el código de la aplicación, la biblioteca del proveedor y el código del sistema operativo.

Me gustaría agregar mi caso de uso aquí para varias carpetas en la misma ventana.

Soy un desarrollador de juegos y, para nuestro juego actual, hemos implementado soporte para mods. Nuestro juego tiene proyectos de cliente, servidor y servidor maestro. Mientras se editan los archivos mod, es común trabajar solo en el nivel mod del juego (en lugar de lo que llamamos el nivel básico o nativo del código del juego real. Por ejemplo, trabajar solo en los archivos Lua en lugar de los archivos C ++ y C # para el servidor y cliente respectivamente). A menudo, las carpetas no se encuentran dentro de una carpeta principal común.

En este caso de uso, cuando solo trabajamos dentro de los archivos mod, en el pasado usamos la funcionalidad de carpeta múltiple de Sublime para crear una vista de proyecto de solo las carpetas mod de nivel superior del Cliente y el Servidor. Esto nos permite evitar los archivos nativos (C # y C ++) y editar rápidamente archivos Lua en esos dos proyectos que están muy relacionados entre sí.

Tener soporte para múltiples carpetas en VSCode nos permitiría hacer lo mismo y facilitaría enormemente nuestra adopción de VSCode (que amamos mucho).

¿Qué resultó de la llamada que se realizó la semana pasada? Estoy en Mac y parece que no puedo abrir varias instancias de VSCode, lo que pensé que sería una solución.

¡Gracias!

Recibí una llamada la semana pasada con Wade, es obvio y justo que esto no fue un
prioridad inicial, han creado un editor realmente bueno y, con suerte, ahora
lo están ampliando para satisfacer las necesidades de diferentes desarrolladores. El equipo de desarrollo es
escuchando, estoy deseando ver cómo lo hacen

El domingo, 15 de enero de 2017 a las 21:20, nowherenearithaca, [email protected]
escribió:

¿Qué resultó de la llamada que se realizó la semana pasada? Estoy en mac y no puedo parecer
para abrir varias instancias de VSCode, lo que pensé que sería una solución.

¡Gracias!

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
.

en gran solicitud
marca

@nowherenearithaca Tuve excelentes llamadas con varios usuarios y compartí lo que aprendí con el resto del equipo. Todavía estamos calculando los próximos pasos, pero espero que hagamos algo en esta área muy pronto.

@waderyan , perdón por la respuesta tardía:

¿Sus microservicios comparten una carpeta principal? ¿Por qué o por qué no?

Sí, por conveniencia. Facilita la búsqueda de servicios relacionados cuando se encuentran en el mismo directorio.

¿Cada microservicio está separado en su propio repositorio de git? ¿Por qué o por qué no?

Si. No solo tienen diferentes repositorios, también tienen diferentes configuraciones de borrado y depuración. Además, usar Cmd + P para cambiar archivos entre proyectos es muy útil. Búsqueda global en proyectos relacionados, ...

¡Espero ver esto en acción!

Una solución sería crear un enlace a la carpeta donde se encuentran los archivos a los que le gustaría acceder.
No es ideal pero puede ayudar.

_Ejemplo:_

/home/myprojet
/home/mylibs
cd /home/myproject
ln -s /home/mylibs
code /home/myprojet

Tengo 3 monitores y quiero usar VSCode en los tres. Si no puedo abrir varias instancias, al menos admitir desacoplar las pestañas y arrastrarlas a otras ventanas (similar a Visual Studio 2015).

De acuerdo.

Todos los demás editores de texto lo hacen. ¿Por qué microsoft no pensó en algo tan simple y necesario?

@calloncampbell Esa característica está en este número: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring No sé qué estoy haciendo mal, pero al usar code -n puedo abrir tantas instancias de editor como quiera.

Si lo entiendo correctamente, esto se investigará dentro del Plan de iteración de febrero como "Investigación inicial sobre la implementación de 'espacios de trabajo de múltiples raíces', espacios de trabajo de 'múltiples carpetas'" :)

+1 ...
¿No es esto posible con la versión anterior de VSCode o solo estaba usando Sublime? olvidó...
pero muy útil.
Ahora mi Mac está llena de 6 ventanas por todas partes ...

Y no, no abriré la carpeta raíz de todas esas 6 carpetas que he abierto, porque el explorador es un desplazamiento vertical y me llevaría una eternidad navegar por los archivos ...

@edmundtfy es posible en lo sublime. Visual Studio Code nunca tuvo soporte para esta funcionalidad.

¡La solución

@DeeJaVu considerando que ... VSCode tiene esta información sobre herramientas y control + clic para ir a la definición. Descargué algunas extensiones para Sublime pero el mouseover y el control + clic no funcionan tan bien ... ¿alguna recomendación?

Realmente extraño esto después de usar Sublime durante años. Ahora mismo estoy trabajando con Intershop (como interfaz) con cientos de miles de archivos por cartucho. Si tengo que cargar una tienda web completa, es muy lento cuando desea abrir CTRL + P para cambiar rápidamente a un archivo o cuando tiene que buscar.

Además, simplemente no quiero todas las carpetas de un proyecto en mi editor. No necesito todo como desarrollador front-end. Solo las carpetas que necesito son suficientes.

Otro ejemplo: crear un sitio Wordpress y complementos para él al mismo tiempo. ¿Por qué debería incluir un sitio completo de Wordpress? Simplemente ralentiza su eficiencia.

Otro problema que tenemos: nuestro marco de front-end está dividido en diferentes repositorios git '. Tener más de 4 ventanas abiertas es un verdadero dolor. Y SCSS intellisense no funciona entonces (IE. Variables del núcleo> paquete)

TLDR; VScode no se puede utilizar para proyectos grandes / enormes

+1, imagina que desarrollas un wordpress o un drupal con varios módulos personalizados.

La raíz de su proyecto es la raíz de su sitio web, pero no desea que el sitio web completo sea un repositorio, solo desea que varios módulos o temas sean repositorios independientes cada uno.

Caso de uso muy común en el desarrollo web que debería cubrirse, incluso con el IDE más pequeño / ligero.

+1

+1, me permitiría editar un proyecto y trabajar en sus submódulos sin problemas

+1

Es el único problema que nos impide migrar todo nuestro equipo de desarrollo de 32 personas a VS.

El desarrollo de microservicios simplemente no es factible, es doloroso.

+1

+1, definitivamente útil, estoy decidiendo pasar a vscode de sublime, pero, debido a que falta esta característica, creo que todavía usaría sublime hasta un día ...

Es una característica muy necesaria y básica. No puedo creer cómo los desarrolladores de este gran editor lo ignoraron. Es inútil sin esta característica. Esto me impide cambiar a VSCode desde Atom.

Agregue esta característica. Después de usar Sublime y luego Atom, esta es para mí una característica necesaria de un editor. Por supuesto, no es tan fácil debido a la integración de git, pero es algo que necesito dentro de mi editor favorito.

+1

+1 necesidad urgente

+1 Como se dijo antes, para pasar de Atom a VSCode realmente necesitamos esta función.

ATENCIÓN ANTES DE COMENTAR
* POR FAVOR !!!! Dejar de comentar con un "+1"

Cada uno de tus comentarios inútiles distrae a más de cien personas solo con este hilo !!!
Si desea admitir esta función, ¡tiene emoción en el primer mensaje!
Si desea suscribirse a las actualizaciones, este es el botón "Suscribirse" a la derecha de los temas.
Respeta a los demás miembros, que se ven obligados a leer tu "+1", "realmente necesario", etc.

Como referencia, la forma en que Sublime Text (como ejemplo) organiza sus proyectos es "incluyendo" árboles de carpetas, con opciones únicas por "carpeta" incluida en su proyecto.

Para visualizar esto, el JSON de un archivo de proyecto de Sublime Text se ve así:

{
    "folders":
    [
        {
            "name": "Front-End (web-forms)",
            "path": "source/www/forms",
            "file_exclude_patterns":
            [
                "*.sublime-*",
                ".gitignore"
            ],
            "folder_exclude_patterns":
            [
                "node_modules",
                ".idea",
                "bin",
                "fonts"
            ]
        },
        {
            "name": "CORE C# Server Components",
            "path": "Source/Server",
            "file_exclude_patterns":
            [
                ".gitignore",
                "*.resx",
                "*.designer.cs",
                "*.StyleCop",
                "*.testsettings",
                "*.cache",
                "*.user",
                "*.vsmdi"
            ],
            "folder_exclude_patterns":
            [
                "bin",
                "obj",
                "TestResults",
                "Service References"
            ]
        },
        {
            "name": "DB schemas & utility scripts",
            "path": "Source/Database"
        },
        {
            "name": "Grunt Build source",
            "path": "Build",
            "folder_exclude_patterns":
            [
                "dist",
                "node_modules",
                "TestResults"
            ]
        }
    ],
}

Como puede ver, cada carpeta incluida es relativa a la ruta del proyecto (en el caso de texto sublime, esta es la ruta del archivo *.sublime-project ). Además, cada carpeta tiene una sección para excluir patrones de archivos y carpetas con comodines. Excelente para ignorar (como se puede ver arriba) los resultados de las pruebas, las bibliotecas que no debes editar, las ilustraciones y muchas otras cosas.

Ésta es la última razón que me queda para no cambiar.

¡Es muy útil!

+1
Ejemplo: necesito verificar si alguna funcionalidad aún no está implementada en otros módulos a los que hace referencia la aplicación para que no duplique la funcionalidad

Obviamente, los módulos se almacenan en otro lugar de la ruta del archivo, no en la aplicación en sí, y usar múltiples ventanas es doloroso con una sola pantalla, cuando solo desea acceder rápidamente a un archivo y leer el código.
Estoy hablando de aplicaciones AngularJS, que no necesitan implementación ni nada, solo un servidor en ejecución.
¿Por qué debería molestarme en desarrollar otra estructura de archivos, cuando puedo abrir la carpeta de la aplicación directamente desde Tomcat y hacer que mis cambios surtan efecto en tiempo real?

Y no, no hay una carpeta principal, a menos que sugiera abrir la carpeta del servidor Tomcat como un proyecto (que es como sugerir que abra todo mi HDD como un proyecto, porque entonces podré abrir todos los archivos).

Vaya, desinstalé atom para probar VS, y esta función no se ha agregado desde 2015.

stoffeastrom abrió este número el 21 de noviembre de 2015

Eso es deprimente. :decepcionado:

PD: Abrir la carpeta maestra no es exactamente una solución, ya que también abre todos los archivos no deseados, superando todo el propósito de este ticket.

Eso es realmente deprimente. Pero, de nuevo, no es tan deprimente como las personas que todavía se quejan de un editor de código abierto increíble y gratuito (que agrega constantemente un puñado de características nuevas _todos los meses_). Ni tan deprimente como enviar spam a todos los que ven este hilo con comentarios sobre la depresión.

_{(Ahora soy uno de los spammers, supongo: sonríe :)}

Actualización: el plan actual es analizar esto en las iteraciones de marzo / abril.

Consulte https://github.com/Microsoft/vscode/issues/21923 para conocer el plan de iteración de marzo:

Investigar en espacios de trabajo de múltiples raíces y carpetas # 396 @bpasero @Tyriar

+1

Para compartir un ejemplo del mundo real que refina la descripción de la función: Ejemplo, WordPress Theme / Plugin dev.

En otros editores, configuro varias carpetas como "marcadores", para llegar a un árbol de archivos bastante grande y complejo un poco más fácil de administrar. Una es para webroot, que es la raíz. Preferiría que cualquier función de depuración y finalización de código busque para comenzar (el entorno). El segundo es el proyecto real, una carpeta de temas o una carpeta de complementos que, en mi flujo de trabajo, es la raíz del control de versiones. Ocasionalmente, configuro carpetas adicionales como referencia, como un tema principal, un tema de plantilla o un complemento con el que me estoy integrando y necesito hacer referencia / leer con frecuencia.

Entonces, la característica establecida aquí es, 1. la capacidad de configurar la raíz de git y la raíz de búsqueda en diferentes ubicaciones. 2. Un sistema de marcadores de carpetas que es puramente visual para ordenar el panel del árbol de archivos.

Para algunos en el hilo, donde la raíz de git y la raíz del proyecto es la misma, parece que aprender y usar submódulos sería suficiente, y luego solo se trata de 2. obtener una vista agradable y menos desordenada de una carpeta anidada.

Estoy seguro de que algunos en el hilo están pidiendo soporte literal para múltiples proyectos, pero supongo que la mayoría solo está pidiendo principalmente la idea más simple de marcadores de carpetas.

Además, estoy solicitando una forma de definir uno como raíz del proyecto (búsqueda / depuración) y otro como raíz de git. (Siéntase libre de ignorar mi pobre nombre de las cosas).

Mi solución para esto es simplemente crear una carpeta principal y crear los enlaces simbólicos con todos los proyectos que quiero.
_p.ej._

Tengo estos proyectos

1. my-app-api
2. mi-aplicación-cliente

Creo una carpeta llamada _my-app-all_ (el nombre es irrelevante aquí) y dentro, creo dos enlaces simbólicos que apuntan a my-app-api y my-app-client, luego en VSCode solo necesito abrir my-app- todas

Pasos

1. mkdir my-app-all
2. cd my-app-all
3. ls -s ../my-app-api
4. ls -s ../my-app-client

Notas:
La integración de git no funcionará

@DannyFeliz, esto debe marcarse como una respuesta a este problema y publicarse en la parte superior para que todos lo vean ... También lo he probado en Windows, usando el comando MKLINK.
Ejemplo de uso:

1. Abra el símbolo del sistema con privilegios de administrador
2. Ve a la carpeta de tu proyecto
   3. [opcional] crea una carpeta de enlaces
3. use MKLINK / D "link_name" "ruta a la carpeta a la que desea hacer referencia"

Cuando abra el proyecto en código VS, verá la carpeta a la que se hace referencia y todos los archivos / carpetas que contiene.

¡Felices chicos de codificación!

Esto no permite que funcione la integración de Git.

El lunes 20 de marzo de 2017 a las 2:42 p.m., poparazvandragos [email protected]
escribió:

@DannyFeliz https://github.com/DannyFeliz esto debe marcarse como un
responder a este problema y publicarlo en la parte superior para que todos lo vean ... He probado
esto también en Windows, usando el comando MKLINK.
Ejemplo de uso:

1. Abra el símbolo del sistema con privilegios de administrador
2. Ve a la carpeta de tu proyecto
   3. [opcional] crea una carpeta de enlaces
3. use MKLINK / D "link_name" "ruta a la carpeta a la que desea hacer referencia"

Cuando abra el proyecto en código VS, verá la carpeta referenciada
y todos los archivos / carpetas que contiene.

¡Felices chicos de codificación!

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

@ehartford Dije una respuesta, no LA respuesta, ya que la mayoría de nosotros estábamos buscando exactamente esto, mostrando varios directorios en la misma ventana de VSCode, que residen en diferentes ubicaciones.
Los enlaces simbólicos hacen precisamente eso, pero cuando se trabaja en Windows, esta no es la solución que se me ocurre.
Tuvo que pasar 2 años y para que un desarrollador de Linux / OSX viniera y nos mostrara la solución más simple.
Me alegro de haber decidido finalmente dejar caer mi comentario sobre este problema, ya que tengo una solución para lo que quería
después de solo 12 días, cuando más lo necesitaba.

El problema no debe descartarse, ya que se puede hacer mucho más si los desarrolladores deciden intervenir en el asunto.
Pero para la mayoría de nosotros esto es satisfactorio. Solo estaba sugiriendo que de alguna manera se mueva esto hacia arriba, para que la gente no pierda el tiempo leyendo todos los demás comentarios, hasta que llegue a este comentario. Algunos pueden simplemente pasarlo por alto debido al tamaño del hilo.

Solo editaré esto porque veo que la gente ya se me ha subido la espalda porque descubrí cómo lograr lo que quería y traté de hacer más fácil para los demás ver una alternativa aunque no fuera perfecta. Por cierto: siempre puede usar el símbolo del sistema integrado en VSCode para extraer / confirmar / enviar archivos en carpetas vinculadas individuales, pero ¿por qué conformarse con soluciones alternativas?

Sin la integración de Git, es totalmente inútil. No considero que esta sea una solución aceptable de ninguna manera. Esperando una solución real. Atentamente.

Si ayuda, el cliente de google appengine nodejs está estructurado así:

https://github.com/GoogleCloudPlatform/google-cloud-node

Me encantaría poder abrir / depurar / trabajar en una solución como esta (incluso si es un paquete a la vez). Me encantaría poder escribir proyectos / bibliotecas basados ​​en TypeScript en este estilo.

¡Gracias por todo el gran trabajo!

Amo VSCode, pero es una mierda manejar múltiples proyectos. Pero puedo entender por qué se ha pospuesto la función, ya que hace que varias cosas, como el control de fuente, sean más complicadas debido al anidamiento, etc.

Me encantaría tener una función de 'cambio rápido de proyecto' O la capacidad de 'tabular' múltiples instancias de vscode en una ventana.

Estoy completamente de acuerdo, admite la apertura de varias carpetas de proyectos en la misma ventana. Esta función es muy importante.

@replete No es una solución perfecta para su problema. Pero dale una oportunidad a Project Manager , esto me está ayudando parcialmente en este momento.

@dariusrosendahl Sí, ¡lo descubrí esta mañana curiosamente! Hace el trabajo por ahora.

La barra lateral tiene solo 5 iconos, no se necesitaría mucho para agregar una barra lateral de 'Proyecto'. Pero parece que los propietarios de productos vscode son muy quisquillosos con lo mínimo que es. En mi opinión, demasiado mínimo, ya que ahora se está convirtiendo en un IDE.

@replete me alegra saber que está siendo útil 😄

De hecho, existe una _API experimental_ para crear la llamada _ Contribución del Explorador de árboles_ (como un panel de Símbolos: https://github.com/Microsoft/vscode/issues/15485). Con eso, la extensión podría agregar un ícono a la barra de actividad.

Agregaré un problema a mi extensión con tu sugerencia, gracias 👍

+1

@dmccaffery

A mí, personalmente, no me importa si esta función termina en el producto o no; entiendo por qué algunas personas la quieren, pero debo señalar que hace que todo sea un poco más complicado.

Entonces, ¿tal vez no domine la conversación con comentarios negativos contra la función y sobre cómo VSC no es un IDE? Creo que una sola respuesta / voto negativo es suficiente, o en el peor de los casos dos, si se necesita aclarar una posición más.

Además, el argumento "no es un IDE" es discutible. Otros no IDE también lo permiten.

Por ejemplo: al buscar usando una expresión regular, ¿qué espacio de trabajo estoy buscando? ¿uno? ¿todas?

No es un gran problema. Busque todo o tenga un selector para establecer el alcance de la búsqueda en uno de los espacios de trabajo abiertos. Nuevamente, otros "no IDE" (así como IDE) ya manejan este (y otros) casos.

Solucioné este problema en mi propia configuración creando un directorio para cada "espacio de trabajo" y haciendo un enlace simbólico a los proyectos que quiero ver en dicho espacio de trabajo.

Vi eso

Investigación inicial en espacios de trabajo de múltiples raíces y carpetas # 396 @bpasero @Tyriar

se realiza de acuerdo con https://github.com/Microsoft/vscode/issues/21923 ¿alguna actualización sobre esto? :)

Nosotros (el subconjunto del equipo) hicimos una investigación inicial sobre la cantidad de trabajo involucrado y los desafíos que vemos y los próximos pasos son discutir el resultado de eso con el equipo y planificarlo. Hacemos nuestra planificación para el lanzamiento de abril durante esta semana, por lo que esperaría más elementos del plan detallados como resultado de este trabajo que se presentará pronto.

Si no llego demasiado tarde a la fiesta, aquí hay una buena manera de implementar esto.
Cuando vas a "Explorer" ya tenemos dos secciones. Uno para los archivos abiertos y otro para el árbol del explorador de la carpeta abierta actual.

Idealmente, podríamos abrir más carpetas en la misma ventana y se agregarían aquí en su propia sección que se puede expandir para ver el árbol del explorador.

Se podría hacer lo mismo para la sección de control de fuente. Una subsección por cada carpeta que se abre en el "explorador". Entonces, una relación 1 a 1.

De esta manera, tal vez podamos hacer felices a todos. Tenemos soporte para abrir múltiples carpetas en la misma ventana si queremos, y también la integración GIT todavía funciona y es capaz de manejar cada "raíz del proyecto" por separado.

Abrir más de un proyecto en la misma ventana también es una característica importante para mí. Por lo general, abro también proyectos para copiar algunas aplicaciones base. Acabo de instalar Visual Studio Code y volveré a Atom por este motivo

+1 Quiero mostrarles a otros desarrolladores el valor de VSCode, pero no poder abrir dos carpetas en la misma ventana es un factor decisivo. Espero que esto tenga una mayor prioridad.

Solo mis dos centavos:

Hasta ahora, la palabra "monorepo" no aparece en este hilo.

Mi monorepo centraliza las preocupaciones de configuración entre múltiples raíces, donde cada una está marcada con un archivo ".root" en la carpeta que las contiene.

No todas las raíces son un repositorio de git externo, pero permiten la anulación parcial de la configuración global.

Mi principal problema es que la búsqueda de archivos y / o símbolos no prioriza el contenido de mis raíces.

Creo que el requisito se puede dividir en ~ 4 separados, que pueden o no estar directamente relacionados entre sí (y probablemente implementados de forma independiente):

• admite varias carpetas en el explorador
• admite varias carpetas en la búsqueda
• admite varias carpetas en el control de código fuente
• admite varias carpetas en depuración

Por lo que he visto en este hilo, separar estos puede soportar una gama más amplia de escenarios. Por supuesto, debería haber todavía alguna carpeta "principal", afectando cómo se conservan las carpetas configuradas / seleccionadas.

No entiendo por qué la mayoría de los comentarios hablan de soluciones de explorador de múltiples raíces o carpetas. En realidad, creo que es realmente malo intentar implementarlo de la manera IDE. Agrega complejidad y seguramente impacta en el rendimiento (tiempo de carga, actualización de git ...).

Creo que esta característica es muy importante, la necesidad básicamente es tener una imagen visual de todos los proyectos relacionados y cambiar entre las ventanas de los proyectos rápidamente.

Tenemos dos opciones:

• Implementación en una sola ventana : En mi sentido, introduce muchas otras preocupaciones, múltiples proyectos de raíces para git, búsqueda ..... ESTO ES MUY MALO para la UX y potencialmente introducirá errores y complejidad al editor.
• Implemente un mecanismo de cambio que sea visual y mantenga una ventana por proyecto : ¡esta es la opción más segura y conveniente por un costo muy bajo! ¡@ min20 publicó un visual sobre los botones de cambio de

Espero que esta función aterrice, ¡pero no como soluciones de múltiples raíces! uno de los beneficios clave de un editor pequeño es su simplicidad y velocidad, muti-root != simplicity & speed

Tengo que estar completamente en desacuerdo contigo @ g13013 ¿has visto la implementación de Sublime? Es muy simple y aún mucho más rápido que Visual Studio Code. Incluso con todos los complementos GIT habilitados.

No estamos hablando de usar varios proyectos en un solo editor. Estamos hablando de usar solo las carpetas de un proyecto que necesita.

Estoy trabajando en tiendas Intershop, por ejemplo. Hay muchas cosas que no necesito, solo los cartuchos que tengo que editar. El 80% de las carpetas y archivos son inútiles para mí y solo hacen que el editor sea mucho más pesado (créame, se ralentiza mucho).

El uso de "Apertura rápida" en Visual Studio también es inutilizable si hay muchos archivos duplicados. A menudo no está seguro de abrir el correcto y, de nuevo, se ralentiza con MUCHOS archivos.

Lo entiendo, pero, habiendo usado sublime y atom en el pasado, finalmente llegué a la conclusión de que ninguno de ellos con la función "muti-root" ha resuelto nada más que la exploración de archivos de proyecto, hablando de sublime, el árbol de carpetas sublime es muy lento en proyectos grandes e incluso se congela al descubrir, sublime no tiene integración de funciones "git" y "depuración" lista para usar ... la introducción de muti-root presentará muchos problemas relacionados con la integración de git, búsqueda sin impactos en rendimiento ... incluso UX se ve afectado, como explorar problemas de srcoll en grandes proyectos.

Extraño, para mí es todo lo contrario.

Tal vez sea porque el 99% de las veces solo incluyo lo que necesito en Sublime o Atom :) y eso es exactamente lo que queremos.

Tal vez sea solo la forma en que usa el editor. Estoy acostumbrado a usar CMD / CTR + P y escribir el archivo exacto que quiero. Esto es imposible si tiene que incluir la raíz de un proyecto con muchos archivos duplicados. (cartuchos / archivos dejados allí para comparar lo que era el original :)) o algo como wordpress donde hay muchos archivos con el mismo nombre.

Hola,
Sí, la idea de varias carpetas está bien sin romper muchas cosas. Cada carpeta adicional puede ser una nueva subsección con un prefijo para indicar que es ajena a la carpeta principal. Primary se usa para depurar y Git. Un usuario puede hacer clic con el botón derecho en cualquier carpeta ajena y convertirla en principal . Lo que gana:
1) poder ver todas sus carpetas y archivos y abrirlos según sea necesario.
2) reubicación de lo principal en el que trabajar.

Ahora, si alguien quiere tener varios proyectos abiertos a la vez, entonces debería tener una nueva solicitud de emisión abierta. Eso agrega una complejidad significativa descrita por numerosas personas. Los complementos no equivalen a incorporados. Si hay un editor que tiene una función incorporada coincidente, se debe señalar para que otros desarrolladores puedan examinar cómo encaja su flujo de trabajo con dicha función. Gracias. Buen día.

Agrégueme a la lista de usuarios que consideran que este es el único factor decisivo que me impide pasar a VSC. Encuentro que la implementación Sublime de Proyectos es perfecta. Si necesito trabajar en la aplicación "Horas de voluntariado", por ejemplo, abro el proyecto que he llenado con diferentes carpetas (la carpeta principal del proyecto y otra carpeta que contiene imágenes). Ese es mi conjunto de trabajo para ese proyecto. Si necesito pasar a la aplicación "Exchange Calculator", puedo cambiar todo el conjunto de trabajo a ese proyecto o abrir una nueva ventana con ese proyecto.
Otro caso de uso es cuando se usa un CMS. Si estoy trabajando en un complemento para el CMS, puedo tener un proyecto para el complemento que es un repositorio de Git y otro para todo el CMS, que no está Gitificado. Puedo alternar entre los dos según sea necesario y mantener mis preocupaciones de Git separadas.
VSC me parece el futuro, pero no sin la capacidad de mantener conjuntos de carpetas de trabajo separados.

Hola,
Solo he visto que Sublime Text tiene soporte para proyectos con un archivo de proyecto . ¿Cómo se equipara eso a lo que se pide aquí? Suena como una solicitud de vscode para admitir archivos de proyecto dentro de un espacio de trabajo. Anteriormente hubo un comentario sobre una extensión que podría manejar cosas en ese sentido para un gerente de proyecto .

Honestamente, también uso Atom y uso la función de carpetas múltiples (incorporada) que me permite tener carpetas de documentación y mi carpeta de proyecto actual abiertas al mismo tiempo. Realmente parece una fruta más fácil para habilitar la primaria y un montón de secundarias. Probablemente una simple flecha o comience a indicar primario. Gracias. Buen día.

Por lo que vale, aquí está mi caso de uso. Trabajo en un juego que se divide en tres repositorios; un repositorio de Git para el motor, un repositorio de hg para el código del juego + contenido y un repositorio de hg para el código del juego que es genérico en muchos proyectos. También hay un repositorio de hg para los complementos de Sublime Text de la compañía. El repositorio genérico es un subrepo del repositorio del juego.

En mi próximo lugar de trabajo, espero volver a trabajar con muchos repositorios.

Es muy conveniente tener todos estos en la misma instancia del editor, y creo que tendría sentido que todos ellos obtuvieran el SCM adecuado en VS Code.

Esperaría que la búsqueda busque en todas las carpetas asignadas de forma predeterminada. Una buena ventaja sería poder activar / desactivar qué carpetas buscar, temporalmente. (Por ejemplo, cuando solo estoy interesado en encontrar cosas en el motor del juego)

Hay mucha gente que dice que VS Code no debería tener soporte para esto porque A) No lo necesitan y B) VS Code es un editor de texto simple. La primera razón no es buena: hay pocas funciones que todos puedan utilizar. La segunda razón ... VS Code no es solo un simple editor de texto, tiene depuración, SCM, complementos. Otros "editores de texto simples" como Sublime tienen soporte para múltiples carpetas. Y como alguien que es inflexible sobre el rendimiento, no veo cómo la adición de esta función afectaría al rendimiento de manera significativa, especialmente para las personas que de todos modos solo usan una carpeta. ¿Podemos centrar la discusión en cómo queremos que funcione la función en lugar de por qué no la queremos?

@Srekel, ¿puedes incluir una captura de pantalla de cómo trabajas así en tus editores actuales? Suena como una mezcla de carpetas y proyectos que utilizan complementos y funciones integradas. Con suerte, la gente de ese campo A apenas notará cambios para incorporar este tipo de función. Para la gente del campo B , tienen razón. Puede hacer las cosas rápidamente con la aplicación lista para usar si no necesita estar atascado. Mantenerse cerca de eso probablemente ayude a tener ciclos de actualización tan rápidos y elementos de interfaz despejados.

Algunas cosas sobre cómo lograr esto incluyen:

• comprender la relación de alcance, contexto, sesión, puntos de vista y estar al día .
• los límites superiores (¿más de 256 carpetas?)
• áreas clave afectadas (pestañas del editor, configuraciones, scm, git, extensiones).
• anulación de la configuración del espacio de trabajo o conflictos.

Sería bueno hablar aquí sobre algunas de las cosas que VSCode da por sentado en estas áreas que necesitan compensación. Gracias. Buen día.

+1

+1. Tengo más de 30 módulos, cada uno con un repositorio de git propio al que me gustaría tener acceso y trabajar en un solo entorno. Pensé que eso es lo que hacen la mayoría de los desarrolladores de js / node. Con VSCode esto es imposible, lamentablemente un factor decisivo para mí.

+1

Ha estado abierto desde 2015 y aún no se ha solucionado. Es simplemente la característica más buscada en cualquier editor, pero lamentablemente vscode no la tiene.

+1

Estoy constantemente confundiendo una ventana de VS Code con otra cuando hago tabulaciones de comandos.

Todos los demás editores que conozco tienen esto (Atom, Sublime, Brackets ...)

Agregar un enlace simbólico a mi proyecto es un truco y me obligaría a actualizar mi .gitignore. Abrir el directorio principal es molesto porque entonces mi panel de archivos se inunda con otros proyectos que no me importan.

Plan de iteración de abril que muestra la tarea "Investigar en espacios de trabajo de múltiples raíces y carpetas" como terminada. ¿Cuáles son los resultados de la investigación?
@bpasero @tyriar

+1

Lo siento si estoy demasiado ansioso. Están ocupados liberando código ahora.

Hola,
El cuadro de diálogo Abrir carpeta debe considerarse Carpetas abiertas. Entonces, si estoy en una carpeta principal en particular, puedo en el cuadro de diálogo resaltar dos o más de sus subcarpetas para abrirlas al mismo tiempo. Sería una adición bienvenida con la incorporación de esta función. Gracias. Buen día.

+ otro

Nunca antes había visto tantos comentarios de bajo esfuerzo en un hilo de GitHub, especialmente post-emojis. Dios mío.

Realmente me gustaría esta función. Como alguien más ya habrá dicho, muchos proyectos modernos son modulares, por ejemplo, frontend en un repositorio / proyecto y backend / api en otro. A menudo querrá trabajar en ellos como uno solo.

Esta es la única razón por la que no he renunciado a Atom.

Los microservicios y las plataformas sin servidor, combinados con el antiguo mantra de que los repositorios son baratos, son la razón por la que esto es imprescindible. No es inusual tener ~ 30 repositorios [pequeños] abiertos y trabajar en archivos de varios proyectos al mismo tiempo; esperar que las personas cambien entre tantas ventanas o descargar la disposición de la vista de archivos al administrador de ventanas del entorno de escritorio no va a funcionar.

Hola,
¿Cómo gestionas tus 30 repositorios ahora
¿Está haciendo esto debido a otras limitaciones en su entorno? tal vez el lenguaje de programación no tiene intellisense? ¿Quizás una extensión que pueda leer la API para brindarle firmas funcionales ayudaría?
Un lenguaje como F # tiene una función llamada proveedores de tipos, uno de los cuales puede hacer precisamente eso y facilitar la programación de la web. Esto no es para disminuir su necesidad de múltiples carpetas, solo que probablemente todavía tenga al menos un puñado de otros problemas con un espacio de trabajo activo tan grande. Gracias. Buen día.

@ pr-yemibedu, creo que lo que dice @martinjco es que no tiene los archivos abiertos, pero tendría acceso rápido a los repositorios si tuviéramos una estructura de múltiples raíces. Imagínese, solo CMD + P a cualquier archivo que necesite;)

El problema con la situación actual es que TENEMOS que tener los archivos abiertos o al menos cambiar entre las 30 ventanas diferentes porque VScode no lo admite.

De hecho, volví a usar Atom recientemente debido a la función que faltaba. Estoy trabajando en un proyecto con 9 repositorios en este momento. No quiero que se abran 9 viudas de VScode al mismo tiempo, pero solo quiero usar un acceso directo para ir al archivo que necesito.

De acuerdo con el comentario de @dariusrosendahl. Soy un codificador novato y tengo que hacer referencia a proyectos anteriores para escribir otros nuevos. Con suerte, eso cambiará pronto, pero en sublime puedo tener fácilmente de tres a cuatro carpetas de proyectos y compararlas para abrirlas en la misma sesión.

Si podemos conseguir eso en Visual Studio, sería genial.

Hola,
Estoy de acuerdo con los puntos señalados, ya que pueden ver que mis publicaciones anteriores favorecen esta característica. Había una declaración exacta sobre la que estaba comentando martinjco:

No es inusual tener ~ 30 repositorios [pequeños] abiertos y trabajar en archivos de varios proyectos al mismo tiempo;

Lo que muestra nuno1895 es cómo uso Atom hoy cuando necesito trabajar en varias carpetas pero en un proyecto de enfoque principal simple. De hecho, utilizo tanto VS2015, gedit, vim, notepad y notepad ++ para el desarrollo activo. Hay puntos fuertes en cada uno que aún no tienen equivalente en sus contrapartes.

Solo estaba tratando de entender si hay un punto central que pueda quedar claro. Todos queremos que esto funcione y sea favorecido por los desarrolladores que dedicarían tiempo a ello. Por eso preguntaba cómo se maneja esto hoy. 9 vs 30 probablemente no me hubiera llamado tanto el interés de responder, pero me gusta saber qué están comparando las personas con vscode y si vale la pena incluso mirar otra herramienta.

Solo he visto que se habla de Atom y SublimeText como base para la comparación y con capturas de pantalla útiles. Se agradecen más discusiones, pulgares y comentarios para que esto sea aceptado e implementado. Gracias. Buen día.

Un punto que puede no haber sido enfatizado lo suficiente es la capacidad de "cambiar" rápidamente entre conjuntos de carpetas (proyectos). Se llama "Proyecto de cambio rápido" en Sublime. Cuando hace clic en ese elemento del menú, aparece una ventana emergente con una lista de todos sus proyectos, cuando selecciona uno de los proyectos, el editor muestra las carpetas y todos los archivos abiertos como los dejó por última vez.
Por ejemplo, si estaba trabajando en el Proyecto A y tenía los archivos app.js e index.html abiertos y luego cambiaba al Proyecto B, cerraría el Proyecto A y mostraría el Proyecto B. Si luego vuelvo al Proyecto A, lo hará muéstrame la (s) carpeta (s) y la aplicación.js y el index.html como los había dejado (incluso las ediciones no guardadas están allí).
Si necesito tener ambos proyectos abiertos al mismo tiempo, puedo abrir dos instancias del editor.
La clave es que puedo mantener todas mis cosas en cubos separados y puedo cambiar entre ellos rápidamente.

+1

Hola,
Leí sobre esa característica. Cambiar proyectos sin navegar en Sublime Text señala algunos de los buenos y malos. Sería bueno codificar las múltiples carpetas abiertas en el archivo de configuración del espacio de trabajo. Si ese archivo parece estar en el lugar equivocado, entonces se puede crear algo como folder.json para conservar el estado actual de qué carpetas y archivos están disponibles y abiertos para el conjunto de trabajo actual. Gracias. Buen día.

Empecé a usar VSCode hace unos meses y, en general, estoy muy satisfecho. Agregaré mi voz al coro y diré que esta característica que falta es el gran rasguño para mí. ¿Hay _algunos_ otros editores decentes que tengan esta limitación? En cualquier caso, debería arreglarse. :)

Aquí está la configuración de mi nuevo trabajo:
Un repositorio para la tecnología principal. Digamos que la ruta es C: / mygamengine /
Un repositorio para el código del juego. Está sincronizado con C: / mygamengine / mygame
Un repositorio para el contenido del juego (texturas, etc.): C: / mygamengine / mygame_data

Los tres son idiotas. No están configurados como sub-repositorios, solo están sincronizados con esas carpetas.

Preferiblemente, me gustaría abrir la carpeta raíz en VS Code y hacer que automáticamente averigüe que son esencialmente tres proyectos diferentes, y que los archivos de mygame pertenecen a ese repositorio de git y no al de mygameengine.

Me gustaría poder establecer configuraciones para este espacio de trabajo que sean diferentes para cada repositorio (por ejemplo, es posible que desee ejecutar un linter en el proyecto del motor pero no en el código del juego). También sería bueno si la configuración del espacio de trabajo por defecto se estableciera en los tres proyectos.

Vaya, ¿esto todavía no se ha resuelto? Esperaba reemplazar Atom con VS Code ya que, según las revisiones, es mucho más rápido y no se retrasa como Atom.
Mi proyecto principal son dos repositorios de Git, uno back-end y el otro un front-end. Localmente, ambos están en la misma carpeta, pero si el código Atom o VS abre esa carpeta principal, no se reconoce el estado de Git.
En Atom, simplemente agrego ambas carpetas a mi espacio de trabajo y simplemente funciona.

: destellos: Actualización: destellos:

Ha pasado un tiempo desde nuestra última actualización, así que pensé en poner a todo el mundo al día. Yo mismo, @bpasero y el resto del equipo hemos identificado la mayoría de los problemas con la implementación de múltiples raíces y actualmente estamos trabajando en algunas maquetas y descubriendo más detalles de la UX.

¿Por qué tarda tanto?

Está tardando tanto porque esta función no es nuestra única responsabilidad y el trabajo involucrado en hacer que suceda la multiplicidad de raíces es bastante inmenso. Para empezar, todos los componentes dentro de VS Code se diseñaron bajo el supuesto de que solo hay una sola carpeta o ninguna carpeta abierta en un momento dado. Cuando tiene una base de código tan grande como la nuestra con una suposición como esta, se necesita mucho trabajo para hacerlo más flexible.

Para dar algunos ejemplos, estos son algunos de los mayores puntos débiles que hemos identificado hasta ahora:

• La API de extensión expone un solo workspace.rootPath , esto es insuficiente cuando agregamos soporte para carpetas multi-raíz. Queremos evitar romper estas extensiones y proporcionar una ruta de migración si es necesario.
• La forma en que la configuración del espacio de trabajo interactúa en un mundo de múltiples raíces es un poco diferente. Tome workbench.statusBar.visible por ejemplo, que actualmente está permitido en la configuración del espacio de trabajo. Ya no podríamos admitir esto, ya que conduciría a un comportamiento extraño / con errores si se define en 2 carpetas. Estamos en el proceso de descubrir cómo lidiar con este tipo de casos.
• El proveedor de SCM (git) necesita probablemente la mayor cantidad de trabajo de UX para admitir varias carpetas: ¿Necesitamos introducir el concepto de "proyecto activo"? ¿Debe establecerse explícitamente (haga clic con el botón derecho en la carpeta y configúrelo) o debe estar implícito (mirando la carpeta del archivo activo)? ¿Debería ser un concepto global o limitarse a esa característica específica? etc.

No queremos apresurarnos con una solución mal pensada, por lo que nos tomamos nuestro tiempo y realmente pensamos en los posibles problemas e implicaciones de cómo esto afectará a cada componente. Vendrá cuando esté listo.

Resumen de comentarios hasta la fecha

Pasé unas horas revisando el enorme hilo para recopilar los comentarios hasta ahora. Fue un poco difícil categorizar algunas de estas cosas, pero esto es lo que la gente buscaba en general (estoy parafraseando).

• Quiero la integración de git en varias carpetas
• El cambio de carpeta actual y / o la UX de administración de ventanas del sistema operativo es engorroso
• Quiero buscar en varias carpetas
• Quiero depurar varias carpetas

Preocupaciones

• ¿Las refactorizaciones funcionan en todos los proyectos o en un solo proyecto?
• ¿A qué proyecto me comprometo en Git?
• ¿En qué carpeta (s) se ejecutará mi búsqueda?
• No rompa la configuración del espacio de trabajo
• No rompa las extensiones: advierta a los desarrolladores de extensiones sobre la nueva API
• Una UX con pestañas estilo Slack no es suficiente para mí, eso es esencialmente solo mover la administración de ventanas del sistema operativo a VS Code: quiero poder acceder a todos los archivos de los proyectos en una sola ventana (es decir, un conjunto de grupos de editores)
• "En mi sentido, introduce muchas otras preocupaciones, múltiples raíces de proyectos para git, búsqueda ..... ESTO ES MUY MALO para la UX y potencialmente introducirá errores y complejidad al editor".

Otros comentarios

• Solo quiero abrir un subconjunto de repositorios en mi "carpeta git"
• Quiero una buena forma de buscar en una sola carpeta u organizar los resultados de la búsqueda por proyecto.
• Quiero poder navegar hasta el código de dependencia para leer rápidamente
• Quiero ejecutar diferentes versiones de TypeScript para diferentes carpetas
• VS Code es demasiado lento con repositorios gigantes
• Quiero mantener algunos proyectos siempre abiertos para usarlos como referencia (por ejemplo, un tema / plantilla)
• Quiero que VS Code reconozca los archivos .vscode / settings.json en cualquier directorio (esto ayudaría a una solución alternativa)
• Déjame definir una raíz de proyecto (búsqueda / depuración) y una raíz de git
• Sublime maneja la integración de git de múltiples carpetas con elegancia
• Carpetas con pestañas similares a la interfaz de usuario de Slack (es decir, algún paradigma de proyecto activo)
• Una sección separada en el explorador para cada carpeta
• Use una carpeta como principal y el resto como vinculadas / subcarpetas
• Quiero un proyecto de cambio rápido como en sublime (cambio rápido + mantener el diseño del espacio de trabajo)
• Este estilo de gestión del espacio de trabajo es particularmente útil para lo siguiente: módulo npm, julia, heroku PaaS, wordpress, drupal

Soluciones provisionales actuales

Estas son las principales soluciones alternativas actualmente:

• Abrir un padre mutuo
• Gerente de proyectos de Git
• Gerente de proyecto
• Enlace simbólico las carpetas como subdirectorios de la "carpeta maestra"

¿Cuándo comentar?

Evite los comentarios: +1: o "Quiero esto". Cuando se hace un comentario sobre este tema, se notifica a las 153 y contando personas que comentaron el, además de muchas más que presionaron el botón de suscripción. Los comentarios también enterrarán las actualizaciones del equipo, así que trata de tenerlo en cuenta. Sin embargo, comente si se suma a la conversación.

Una característica que podría decirse que tendría más utilidad que tener múltiples raíces es agregar la capacidad de tener conjuntos de trabajo configurables. Esto le permitiría abrir un padre mutuo, pero tiene muchas combinaciones de carpetas dentro de este proyecto.

Genéricamente, esto sería útil para cualquier proyecto para poder "concentrarse" en ciertos archivos / carpetas a la vez en bases de código más grandes sin tener que cambiar la configuración de toda la raíz cada vez.

¿NO tiene planes sobre esta función?

Puede ver el plan para esta función en el comentario de @Tyriar y en estos enlaces relacionados:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

Nos gustaría compartir nuestros diseños para esto y recibir sus comentarios. Para hacer esto, vamos a programar una serie de conferencias telefónicas en las que analizaremos nuestros diseños y analizaremos sus reacciones a los diseños.

Si desea participar en estas discusiones y ayudarnos a obtener el diseño correcto, comuníquese conmigo (envíeme un correo electrónico: stevencl en microsoft dot com) y los configuraré.

Esperamos programar estas discusiones para el jueves 1 de junio y el viernes 2 de junio.

@Tyriar @stevencl ¡ Gracias chicos! :aplaudir:

Gracias a todos por unirse a las sesiones de hoy. Las grabaciones de las sesiones se han publicado aquí.

• grupo 1 - https://youtu.be/48Y6tB3DN1g
• grupo 2 - https://youtu.be/kHL6Rt-dLm0

Mire los videos y comparta cualquier comentario adicional que tenga sobre los diseños.

@stevencl ¡ gracias por ejecutar los estudios y ponerlos a disposición!

Excelentes videos, gracias! Algunos comentarios:

• 👍👍👍 por el diseño simple general y la extensión natural de cómo funciona VSCode en la actualidad. Ustedes lidiaron con muchas situaciones complejas de una manera simple y elegante. ¡Felicitaciones por eso!
• Me gusta la notificación de SCM agregada en la esquina inferior izquierda, no se necesitan cambios desde mi punto de vista con una excepción: me saltearía la ventana emergente después de hacer clic en la notificación de SCM e iría directamente al panel de SCM. Menos clics = siempre mejor para mí.
• Las raíces de codificación de colores como sugirió Alexey es una idea interesante que podría ayudar.
• Búsqueda: el alcance de una carpeta será importante para mí, supongo que el campo actual "archivos para incluir" podría usarse para eso muy bien, solo quería estar seguro.
• Lo único de lo que no estoy seguro es la persistencia y la apertura de todos los additionalFolders cuando abro el path . Tiene sentido con el último ejemplo donde express-project es claramente el "proyecto maestro" pero no estoy seguro del ejemplo anterior: express y express-plugin sintieron iguales, como verdaderos hermanos, y no estoy seguro de esperar que abrir express también abriría express-plugin .
  
  
  
  • En cierto modo, la estructura de datos detrás de esto parece que debería ser solo una lista plana de rutas, no una "ruta" y luego "carpetas adicionales".
  
  
  • No estoy seguro de si el concepto de una ruta maestra es tan útil. En mis proyectos, probablemente no lo sea.
  
  
  • Para abrir el espacio de trabajo de múltiples raíces, esperaría un comando de nivel superior como _File> Open workspace_ además del actual _File> Open folder_.
  
  
  • En general, no estoy muy seguro de esto. Lo siento, no tengo sugerencias más concretas.
  
  

Gracias nuevamente, con esto, VSCode obtendrá nuevos superpoderes 😄.

Gracias por compartir los videos. Me gustaría apoyar el diseño de "una sección por carpeta raíz":

Al principio, esperaba el otro diseño (tipo texto sublime), pero después de ver la alternativa de "una sección por carpeta raíz", me quedó claro que este enfoque tenía las siguientes ventajas:

• Distinción y separación claras e inequívocas entre carpetas (especialmente si tengo más de 2 o 3 de ellas, que suele ser el caso cuando utilizo otros editores e IDE)
• Refuerza la noción de que una carpeta raíz es un (sub) proyecto separado
• Acceso rápido a los comandos del subproyecto (como "nuevo archivo", "actualizar" ... y, quizás en el futuro, hacer clic derecho para iniciar una tarea (por ejemplo, "reconstruir") en ese subproyecto específico;)
• Como mencionó el segundo grupo, con este diseño, es menos probable tener el problema de truncamiento de nombre de carpeta

Con respecto al concepto de "una sección por carpeta raíz" ... realmente no estoy seguro de que esto funcione bien para mí y para la mayoría de mis casos de uso. Siempre que tengo una situación de raíz múltiple, es común que tenga muchas ; no solo 2 o 3.
No estoy seguro de cómo escalará este enfoque.

También un argumento para el diseño actual en forma de carpeta es que es consistente con cómo se mostraría un monorepo. Por ejemplo, compare:

monorepo/      <- contains .git
  project1
  project2

vs.

microservices/
  project1      <- contains .git
  project2      <- contains .git

Esos dos realmente deberían ser tratados de manera bastante similar por VSCode: monorepo ya lo es (compromiso: natural, búsqueda: "archivos para incluir", varios archivos READMEs: su carpeta se muestra en la pestaña del editor, etc.). Multi-root debería seguir esto lo más cerca posible, en mi opinión, lo que el diseño actual hace muy bien.

@stevencl Una cosa que no entendí completamente: ¿la solución traerá un tratamiento de alcance (o incluso jerárquico) de las configuraciones .vscode ? Por ejemplo, si tuviera .vscode por carpeta de nivel superior, ¿se aplicarán esas configuraciones individualmente? ¿Se agregarán de alguna manera en la raíz del proyecto? ¿O sólo contará el .vscode "primario"?

Prefiero el diseño de "una sección por carpeta raíz", por las mismas razones enumeradas por @maddouri. Además, habiendo utilizado la otra alternativa (en Atom), es visualmente más difícil encontrar dónde comienza una nueva carpeta raíz cuando se abren y expanden varias carpetas altamente jerárquicas.

Gracias por las actualizaciones de diseño, ¡se ve realmente bien!

¿Existe la posibilidad de tener varios espacios de trabajo disponibles a la vez en la interfaz de usuario? Para que pueda cambiar fácilmente entre ellos. Por ejemplo, tienes algo como:

EXPRESS, EXPRESS-PLUGIN
  express/
    lib/
    test/
    package.json
  express-plugin/
    lib/
    test/
    package.json
CONNECT, CONNECT-PLUGIN

Y luego hacer clic / hacer doble clic en el divisor CONNECT, CONNECT-PLUGIN cambiaría a tenerlo como el espacio de trabajo activo. Esto permitiría cambiar fácilmente entre espacios de trabajo para las personas que tienen que lidiar con varios conjuntos de proyectos. No estoy sugiriendo que todos estén disponibles para búsqueda y SCM y todo eso, eso permanecería con el espacio de trabajo actual, que es el actualmente expandido.

Eso podría funcionar con tener las carpetas raíz resaltadas como se sugiere en el primer grupo, y tal vez tener los nuevos íconos de archivos / carpetas disponibles al pasar el cursor sobre esas carpetas.

Algunos comentarios sobre la configuración JSON, podría ser útil que la configuración del espacio de trabajo sea algo como:

workspaces: [
    {
        name: "Express Project",
        root: "file://C:/workspace/",
        folders: [
            "./express/",
            "./express-plugin/"
        ]
    }
]

Entonces, root convierte en la fuente para abrir las carpetas, en lugar de la ruta, pero la raíz en sí no se abre, solo cada carpeta. Entonces no tiene una "carpeta principal", pero aún conserva las rutas de archivo relativas. Esto supone que puede abrir un espacio de trabajo predefinido a través de la interfaz de usuario, en lugar de abrir la carpeta raíz y todas las carpetas adicionales con ella. El nombre se puede usar como divisor para evitar que un gran número de nombres de carpetas lo haga demasiado largo o se acorte de manera inútil.

Si se elige la solución "una sección por carpeta raíz", me gustaría sugerir que la carpeta raíz actualmente visible "se adhiera" a la parte superior de la barra lateral, en lugar de desplazarse hacia arriba fuera de la vista. Solo se desplazaría hacia arriba una vez que la carpeta raíz siguiente llegara a la parte superior de la barra lateral.

El 4 de junio de 2017, a las 6:47 a. M., Peter Petrov [email protected] escribió:

Prefiero el diseño de "una sección por carpeta raíz", por las mismas razones enumeradas por @maddouri. Además, habiendo utilizado la otra alternativa (en Atom), es visualmente más difícil encontrar dónde comienza una nueva carpeta raíz cuando se abren y expanden varias carpetas altamente jerárquicas.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

O podemos seguir el enfoque de Sublime, Atom, pero cambiar de color o mostrar de alguna manera qué carpeta es la raíz y / o pegarla en la parte superior. Por supuesto, ambos enfoques son buenos, pero tener muchas carpetas abiertas reduce el espacio, porque la barra con actualización, crear un nuevo archivo, etc.será visible, por eso es mejor no cargar la barra, pero de alguna manera mostrar qué carpeta es la raíz. PERO nuevamente, esta barra es realmente buena, porque es mucho más fácil ver las carpetas raíz abiertas y puedes actualizarlas y hacer otras cosas que están incluidas en la barra. Necesitamos ver cómo se ve, por ejemplo, con 10 carpetas abiertas con y sin barra.

@stevencl ¡ Gracias por publicar esas grabaciones! En general, estoy entusiasmado con la dirección en la que se dirige la función. Gracias por todo el tiempo y el esfuerzo dedicados hasta ahora. Aquí están mis comentarios / pensamientos:

• Prefiero el primer diseño con el diseño de la barra de nombre de carpeta única en "EXPLORADOR", sin embargo, me preocupa que si todos los nombres de carpeta se enumeran allí, se truncará muy rápidamente para mostrar el "agregar archivo" agregar carpeta ", etc., botones. Creo que simplemente pondría la cadena "Múltiple" o algo similar cuando hay más de una carpeta abierta; de lo contrario, solo hay una carpeta, así que ponga el nombre de la carpeta allí como se hace hoy (y oculte la raíz de la carpeta en el árbol).
• La desambiguación de los nombres de los archivos añadiendo el nombre de la carpeta en el título de la pestaña en el Editor, IMO, no es necesaria a menos que haya varios editores abiertos con el mismo nombre de archivo. Tenga en cuenta que este escenario no es infrecuente incluso con una sola carpeta abierta. Es bastante fácil obtener varios archivos (por ejemplo, .gitignore ) con el mismo nombre entre subcarpetas dentro de la misma raíz. Por lo tanto, este diseño (agregando el nombre de la carpeta principal) debe ser una característica separada, en mi opinión, y debe implementarse. Junto con esto, me encantaría ver una buena solución para https://github.com/Microsoft/vscode/issues/15048 porque esto hará que algunos títulos de pestañas sean aún más largos. :)
• Para los resultados de búsqueda, creo que es esencial que la búsqueda funcione en todas las carpetas raíz. Se podría agregar otro filtro para limitar la búsqueda a las raíces elegidas. Cuando se muestran los resultados, puede ser útil ver los resultados por raíz, por lo que tal vez sea una opción para ver una lista larga con los nombres de las carpetas raíz adjuntas, o ver una lista separada en secciones, una para cada carpeta raíz.
• Me parece extraño que esté proponiendo agregar 'espacios de trabajo' a la __configuración del usuario__. Realmente esperaba que esto terminara en la __configuración del espacio de trabajo__. Creo que estás diciendo que la configuración del espacio de trabajo también puede contener la nueva propiedad 'espacios de trabajo', lo cual es bueno. También es muy bueno que las rutas del espacio de trabajo puedan ser relativas. Simplemente no parece ser algo que pertenezca en absoluto a la configuración del usuario. Es una característica que se siente muy específica de los espacios de trabajo. Ah, pero ahora veo por qué también es válido en la configuración del usuario, porque me brinda una forma de almacenar estos espacios de trabajo cuando quiero carpetas "aleatorias" en mi HDD en un espacio de trabajo donde no hay una raíz común.
• Una cosa que parece perderse en los espacios de trabajo cuando se almacenan en la configuración del usuario es la capacidad de tener otras configuraciones específicas del proyecto atribuidas a un espacio de trabajo u otro. Por ejemplo, si tuviera un espacio de trabajo donde necesitara que el tamaño de la pestaña fuera 2 espacios y otro donde tuviera que ser 3, no podría hacer eso con espacios de trabajo en la configuración del usuario. Tendría que crear una carpeta en algún lugar, y luego poner una carpeta .vscode dentro de ella, y luego definir .vscode/settings.json para finalmente definir mi espacio de trabajo con el tamaño de pestaña apropiado anulado. En este punto, estoy pensando que crear un nuevo tipo de archivo de Proyecto VSCode que almacene todas estas configuraciones y se pueda abrir como un archivo especial se vuelve mucho menos engorroso que tener que crear esta jerarquía de carpetas para almacenar el espacio settings.json trabajo

En el primer diseño, para carpetas adicionales, la ruta (relativa o absoluta) entre paréntesis se puede agregar al nombre para diferenciar. Creo que será una solución sencilla.

@stevencl gracias por grabar las sesiones. Tenía muchas ganas de participar pero no estaba disponible en ese momento 😢

Me gustó la interfaz SCM propuesta. Tener una sección de resumen y una sección por carpeta me da, en mi humilde opinión, una interfaz mucho más fácil de detectar y trabajar con los cambios. Y me gusta la idea de tener un comportamiento consistente en toda la interfaz de usuario, por lo que la idea de Una sección por carpeta también debe usarse en la pestaña Buscar , en lugar de concatenar el nombre de la carpeta en cada resultado. Lo mismo para la pestaña Explorador .

Usar la Configuración de usuario para almacenar la _Multi-Carpeta_ es un poco extraño para mí, porque _no parece ser una configuración de usuario_: smile : additionalFolder _siempre_ forme parte de la Workspace Settings . Al hacerlo, cuando _Agregue una carpeta_, se agregará solo al Workspace Settings . Luego, al abrir una carpeta, simplemente busque .vscode\settings.json archivo y una entrada additionalFolders allí, para comprobar _si se trata de un espacio de trabajo de varias carpetas_. _Es similar al segundo ejemplo que usó, sobre los dos repositorios de git que faltan_.

SomeFolder.vscodesettings.json

{
    "editor.wordWrap": "off",
    "editor.codeLens": false,
    "editor.renderWhitespace": "all",
    "workbench.colorTheme": "Abyss",

    "additionalFolders": [
        "./express",
        "./express-plugin",
        "~/commons/other-stuff",
        "file:///C://Temp//oldlib"
    ]
}

Además, admite ubicaciones de _user-data_ como ~ y $home , lo que facilita compartir proyectos entre diferentes computadoras / plataformas.

Solo me perdí un punto: API . ¿Cómo se integrarían las extensiones con eso?

Gracias por los esfuerzos. Esperando los primeros lanzamientos de información privilegiada 👍

¡Gracias por la respuesta! Quería seguir la dirección de aprovechar una nueva propiedad de configuración additionalFolders para implementar "Multi Root" porque escuché algunos comentarios sobre esto en los comentarios anteriores.

La principal motivación para introducir una configuración en primer lugar es, en realidad, mantener las cosas simples y no introducir demasiados conceptos nuevos, al mismo tiempo que se tiene una solución que es poderosa y permite algunos escenarios interesantes. Aquí hay algunas decisiones de diseño y consecuencias:

Mantenlo simple
Creemos que abrir archivos y carpetas es el núcleo de VS Code. Por tanto, no queremos introducir un nuevo concepto de "Proyectos" de alto nivel. Por ejemplo, no pensamos que se necesita una acción de "Abrir proyecto", sino que pensamos que un proyecto es siempre una carpeta y, opcionalmente, puede tener carpetas adicionales asociadas. Con esta suposición, un entorno parece la forma natural de permitir eso. Siempre que abre esta carpeta, abre las carpetas adicionales con ella. Agregar y eliminar carpetas es un gesto simple y actualizará la configuración directamente.

La configuración es poderosa
Tener múltiples raíces como configuración permite muchos escenarios interesantes. Por ejemplo, puede poner la configuración additionalFolders en su espacio de trabajo y, como tal, compartir esto con otras personas (mediante el uso de rutas relativas, esto se muestra en los videos).
Además de eso, también tiene la libertad de configurar los proyectos en primer lugar: por ejemplo, en algunos casos no existe una relación clara entre una carpeta maestra y carpetas adicionales (por ejemplo, podría ser que algunas de ellas ni siquiera estén relacionadas con El uno al otro). En ese caso, puede crear una carpeta de "proyecto" que solo incluya un settings.json con las carpetas a las que se vincula:

allMyRandomProjects/ 
  .vscode
    settings.json <- contains additionalFolders setting  

Ahora, cuando abra allMyRandomProjects , le mostrará la lista de carpetas según la configuración. Incluso puede incluir algunas configuraciones en settings.json que deberían aplicarse a todas las carpetas mostradas.

Cambio de espacio de trabajo y ventanas múltiples
Sin lugar a dudas, necesitamos trabajar en un mejor cambio de espacio de trabajo y compatibilidad con múltiples ventanas en VS Code. Dado que tratamos un espacio de trabajo de múltiples raíces de la misma manera que cualquier otro espacio de trabajo con una carpeta, mejorar el cambio de espacio de trabajo y la compatibilidad con múltiples ventanas beneficiará a cualquier usuario, incluso a aquellos que no aprovechan los espacios de trabajo de múltiples raíces.
Tendremos que buscar formas mejores y más fáciles de cambiar entre carpetas y ventanas abiertas independientemente de la raíz múltiple.

En mi próximo comentario, proporcionaré algunos comentarios sobre los comentarios individuales realizados.

La búsqueda de

@maddouri @TurkeyMan @pesho , @dgileadi @stefcameron parece claro que algunas personas prefieren un solo árbol y otras prefieren múltiples secciones en el explorador. Por lo tanto, podríamos terminar con una configuración para esto, hay ventajas y desventajas para ambas soluciones y el usuario debe decidir cuál es mejor para el escenario.

@borekb la forma en que se aplica la configuración cambiará un poco dependiendo de si se encuentra en una configuración de múltiples raíces o no: la configuración del usuario siempre se aplica a todas las carpetas abiertas como antes. La configuración del espacio de trabajo se tomará de la carpeta principal ("maestra") y se aplicará a todos los archivos y carpetas que estén asociados a ella. Ahora, aún puede definir configuraciones en cualquiera de las carpetas adicionales a través de la configuración del espacio de trabajo, aunque es posible que no las admitamos todas. Por ejemplo, una configuración como update.channel: none no se puede admitir por carpeta. Lo que tendremos que hacer es identificar las configuraciones que podemos admitir a nivel de carpeta (por ejemplo, files.exclude , todas las configuraciones del editor) y realizar los cambios necesarios para habilitarlas. Esta es una de las principales áreas de trabajo en las que tenemos que invertir, especialmente porque las extensiones también pueden definir configuraciones que queremos admitir en un ámbito por carpeta.

@BTMorton me parece que quieres formas más fáciles de cambiar de espacio de trabajo. Esto es algo que deberíamos considerar independientemente de la raíz múltiple para cualquier transición de carpeta que pueda hacer un usuario.

@stefcameron , mantendremos la configuración additionalFolders suficientemente abierta como para eventualmente agregarle metadatos adicionales. Por ejemplo, podría pensar en poder proporcionar un nombre para dicha configuración para que el cambio entre proyectos se realice por nombre y no por carpeta principal.

Una cosa que aún no hemos mencionado en los videos es cómo las extensiones pueden admitir carpetas de múltiples raíces. Otro objetivo principal con el soporte de múltiples raíces (además de "mantenerlo simple") es: no romper extensiones

Hoy en día, las extensiones tienen una API simple para acceder al espacio de trabajo abierto actualmente ( workspace.rootPath: string ). Esta propiedad puede ser null en caso de que no se abra ninguna carpeta.

Ahora, con la introducción de la configuración additionalFolders , una extensión aún puede depender de la propiedad workspace.rootPath configurada (si se abre una carpeta), o no (cuando no se abre ninguna carpeta). Dado que additionalFolders es en realidad una configuración, una extensión es gratuita para leer e incluso escribir en esta configuración con las API que ya tenemos alrededor de las configuraciones. Incluso se emite un evento cuando cambia esta configuración, lo que permite una reacción dinámica al usuario que cambia esta configuración.

La lectura de esta configuración permite que una extensión conozca carpetas adicionales en el área de trabajo. Por ejemplo, la extensión de Travis CI podría optar por mostrar un estado agregado en todas las carpetas.

Escribir esta configuración habilita algunos escenarios interesantes para las extensiones: por ejemplo, podría tener una extensión de administrador de proyectos que agregue y elimine carpetas dinámicamente a su espacio de trabajo y, como tal, permita transiciones de proyectos dentro de la ventana, por ejemplo, mostrando una lista de proyectos a través de una interfaz de usuario de selector .

En un momento dado, probablemente presentaremos alguna API de extensión nueva real para tratar con carpetas de múltiples raíces. Enterrar esto dentro de una configuración para que las extensiones lean / escriban es un poco extraño. Pero para empezar, las extensiones ya pueden explorar la configuración additionalFolders para aprovecharla si es posible. También trabajaremos en estrecha colaboración con los autores de extensiones para comprender sus escenarios y cómo apoyarlos mejor.

@bpasero ¿El concepto de carpetas adicionales también se agregará a LSP, o VS Code simplemente iniciará un servidor de idioma por carpeta adicional?

@felixfbecker, esto es algo que todavía tenemos que invertir y explorar para encontrar una buena solución para las extensiones de idioma. Una vez que pensamos en API adicionales para extensiones, también debemos pensar en lo que esto significa para el LSP.

Sin embargo, vale la pena mencionar que hoy en día ya puede haber situaciones en las que los usuarios abren un archivo desde una carpeta que no está abierta como espacio de trabajo (por ejemplo, Archivo> Abrir> algún archivo.xyz). Idealmente, una extensión de idioma puede mostrar el mismo nivel de características de idioma para dicho archivo, incluso si la carpeta de ese archivo no está abierta.

Al principio, abrir un archivo desde uno de los additionalFolders se comportaría de manera muy similar a abrir un archivo que no está en la carpeta que abrió inicialmente. TypeScript, por ejemplo, puede manejar bien este caso: simplemente avanzan desde el archivo actualmente abierto hasta que se encuentra un archivo tsconfig.json y luego lo tratan como un proyecto. Funciones como buscar referencias funcionan sin problemas:

Sería bueno si cualquier extensión de idioma pudiera funcionar simplemente saliendo del archivo actualmente activo en lugar de forzar tener un contexto de proyecto explícito.

@bpasero gracias por los comentarios. Por lo tanto, parece que en el modelo actual, siempre habrá una carpeta "maestra" : incluso en el ejemplo allMyRandomProjects , esta es básicamente la carpeta maestra, aunque en su mayoría está vacía. Esto tiene algunas implicaciones sutiles, pero necesito pensarlo un poco más para proporcionar comentarios útiles.

En general, creo que VSCode debería admitir monorepo frente a múltiples repositorios de una manera bastante similar, según el comentario anterior: https://github.com/Microsoft/vscode/issues/396#issuecomment -306040485.

Por cierto, ¿cómo se define exactamente "raíz"? Si abro la carpeta A que contiene las subcarpetas B y C, ¿qué diferencia hay de definir A como path y B y C como additionalFolders ? ¿Es la intención de VSCode tratar esas dos situaciones de manera bastante diferente o básicamente igual? (Creo que debería ser una experiencia muy similar).

@bpasero

Al principio, abrir un archivo desde una de las carpetas adicionales se comportaría de manera muy similar a abrir un archivo que no está en la carpeta que abrió inicialmente. TypeScript, por ejemplo, puede lidiar bien con este caso: simplemente avanzan desde el archivo actualmente abierto hasta que se encuentra un archivo tsconfig.json y luego lo tratan como un proyecto. Funciones como buscar referencias funcionan sin problemas:

Sin embargo, TypeScript no usa LSP. En LSP, los servidores de idiomas tienen un rootUri y, por ejemplo, PHP usará este rootUri para buscar archivos que necesiten indexarse. No tiene un archivo como tsconfig.json que denotaría un "proyecto". Entonces, si hay archivos que no se abren a través de didOpen pero tampoco por debajo de rootUri , entonces estos no se considerarían para inteligencia de código, de ahí mi pregunta si LSP se extenderá para esto.

Solo para aclarar, ¿abrir múltiples raíces crearía un archivo ./.vscode/settings.json si aún no existiera?
Por lo que he leído aquí hasta ahora, parece que estamos diciendo que sí.

Entiendo por qué es útil evitar agregar el concepto de proyectos, pero quizás sería bueno que guardar un espacio de trabajo sea opcional, aunque en este caso, 'guardar' solo significa crear un archivo de configuración en la carpeta raíz.

Creo que podría sorprender a un usuario que no ha estado siguiendo este hilo si abre una segunda carpeta y crea un archivo de configuración. Abrir carpetas es el tipo de cosas que creo que la mayoría de los usuarios esperan que sean de solo lectura.

Gracias por todos los comentarios a todos, esto es muy útil.

@saborrie : buena pregunta sobre hasta qué punto las personas se sorprenderían con la creación de una configuración al agregar una carpeta. Tendremos que investigar eso para ver si ese es el caso (obviamente con personas que no han estado siguiendo este hilo :-)).

@borekb : hemos hablado sobre el escenario que mencionó (abrir una carpeta que contiene una o más subcarpetas) y nos hemos inclinado a tratar esto de la misma manera que abrir un espacio de trabajo de múltiples raíces. Sin embargo, el desafío es determinar cuándo tratar una situación como multi-root y no solo como una carpeta que contiene otras carpetas.

También me interesaría lo que otros piensen sobre esto.

@borekb menciona un buen punto, también diría que si abre una carpeta que contiene varios repositorios de git, nuestra vista SCM debería poder mostrarle la misma vista que obtendría si configurara esto explícitamente a través del additionalFolders propiedad. Creo que podemos comenzar a explorar esta evolución de la interfaz de usuario con carpetas que tienen configurada la configuración additionalFolders y luego expandirla a más casos de uso. Otro escenario interesante y relacionado es cómo elegimos presentar submódulos en un repositorio.

También creo que eventualmente queremos admitir la configuración de .vscode en cualquier nivel de jerarquía de carpetas una vez que hayamos resuelto los desafíos que conlleva.

Hablaría menos sobre la relación maestro-detalles cuando hablo de múltiples raíces porque la mayoría de la UX tratará la carpeta principal de la misma manera que las carpetas adicionales. La carpeta maestra es en realidad solo el contenedor de la configuración de carpetas adicionales y será el controlador principal para la configuración global del espacio de trabajo. Para compatibilidad con versiones anteriores, también será el que enviamos a las extensiones como rootPath .

@felixfbecker, ¿eso significa que no puedo hacer un "Buscar referencias" o características de lenguaje similares cuando abro solo un archivo PHP de mi proyecto, necesito abrir esa carpeta para obtener estas características? No estoy muy metido en PHP, pero si existe un concepto de dependencias entre archivos, no podría navegar a otro archivo PHP desde un solo archivo, ¿necesito abrir la carpeta primero?

@saborrie NO agregaríamos una configuración de espacio de trabajo por defecto cuando agrega carpetas. Una de las razones por las que decidimos poner esto en la configuración del usuario es para que un espacio de trabajo no se "ensucie" con la configuración de múltiples raíces. Es posible poner esta configuración en el espacio de trabajo, pero deberá hacerlo manualmente. No sucederá por defecto.

@bpasero Ok, sí, seguir con el guardado en la configuración del usuario en lugar de la configuración del espacio de trabajo evitaría que se ensucien las carpetas del espacio de trabajo; supongo que aún se guardaría antes de requerir que el usuario realice explícitamente una acción de guardado, aunque ¿sí?

Eso me deja con dos preguntas de seguimiento:

1) ¿Qué pasaría cuando un usuario abre un espacio de trabajo con additionalFolders definido en la configuración del espacio de trabajo? ¿Se sincronizaría esto con su configuración de usuario? y ¿anularía la entrada para esa raíz del espacio de trabajo si existiera en la lista del espacio de trabajo de configuración del usuario? ¿O viceversa?

2) ¿Poner esta lista de espacios de trabajo en la configuración del usuario es una mejor opción que evitar inicialmente almacenar espacios de trabajo en cualquiera de estos archivos de configuración JSON? En el sistema actual de una sola carpeta, cuando se vuelve a abrir una carpeta desde el elemento de menú File > Open Recent , las pestañas que estaban abiertas anteriormente se recuerdan, por lo que puedo decir, esto no se almacena en ningún usuario -Archivo de configuración editable, ¿no podrían almacenarse las rutas adicionales de la misma manera hasta que un usuario las guarde explícitamente?

- Perdón por el inglés, usé Google Translator -

Bueno, revisé el diseño (sí, un poco de dificultad para entender el inglés). Perdón entonces...

No me gustó el diseño presentado por @maddouri , principalmente debido a los problemas encontrados en este número (# 25352, # 25354). Creo que será más complejo incluso si tienes que usar el teclado para acceder a las carpetas en el modelo mostrado.

Prefiero este modelo, que por la idea puedo navegar entre las diferentes carpetas del proyecto usando las teclas de flecha y si necesito crear una carpeta / archivo en la carpeta principal, puedo usar la tecla de menú en el teclado, justo en la carpeta principal. carpeta.

Y / o con las opciones de archivo nuevo, actualización de carpeta nueva y Contraer todo.

En cuanto al título que aparece en la parte superior, prefiero que se enfoque en el archivo actual con la carpeta en la que se encuentra, o en lugar de mostrar todas las carpetas principales abiertas más el archivo actual, similar a esta imagen.

Y una pregunta: ¿Seguirá existiendo Open Editores?

@bpasero

¿Significa eso que no puedo hacer "Buscar referencias" o funciones de lenguaje similares cuando abro un solo archivo PHP de mi proyecto, necesito abrir esa carpeta para obtener estas funciones? No estoy muy metido en PHP, pero si existe un concepto de dependencias entre archivos, no podría navegar a otro archivo PHP desde un solo archivo, ¿necesito abrir la carpeta primero?

Eso es correcto, si solo abre un solo archivo, no puede ir a la definición de un archivo en un archivo diferente que no está abierto, sino solo a los que están por debajo de rootUri . Esto se debe a que en PHP cada archivo puede volcar símbolos en el espacio de nombres global, y los espacios de nombres son en realidad prefijos de nombres para clases. No hay restricciones sobre cómo los espacios de nombres y los nombres de clases deben corresponder a directorios y nombres de archivos (solo algunas convenciones), y no hay declaraciones de importación como en TS, solo alias de espacios de nombres. La carga de clases ocurre en tiempo de ejecución a través de "cargadores automáticos" registrados. Eso significa que para un servidor de idiomas en la definición de acceso, un símbolo podría definirse en cualquier archivo. Entonces, el servidor de idioma indexará todos los archivos en rootUri al inicio y luego trabajará con el índice para responder a las solicitudes. Lo que sí funciona es si tiene un proyecto abierto y crea un nuevo archivo no guardado; obtendrá inteligencia para eso, porque obtuvo rootUri y el nuevo archivo a través de textDocument/didOpen . Pero los símbolos definidos en archivos no abiertos que no sean menores a rootUri no serán considerados.

La configuración del espacio de trabajo de additionalFolders dentro del espacio de trabajo siempre tiene prioridad. Sin embargo, dada la naturaleza de esta configuración, solo puede anular las carpetas adicionales para la carpeta abierta actualmente cuando esta configuración se especifica dentro del espacio de trabajo (esto se muestra en los videos al tener path: "." para el "maestro").

Tener esto como el estado de la interfaz de usuario almacenado de manera similar a, por ejemplo, cuántas pestañas se abren fue una opción que discutimos, pero no encontramos que tenga muchas ventajas sobre una configuración. Algunas razones:

• esto no se puede compartir (ni a través de la configuración del espacio de trabajo ni a través de una extensión de sincronización de configuración)
• esto no es algo a lo que las extensiones puedan acceder hoy fácilmente (la API de configuración existe, la API de estado de IU no)

¿Hay alguna razón en particular por la que no desee esta configuración interna?

@Tekbr sí, "Open Editors" funcionará como antes

@felixfbecker, ¿la extensión PHP podría adoptar fácilmente algo como rootUri: string[] ? ¿O prefiere que el servidor de lenguaje PHP se inicie varias veces por cada carpeta abierta (por ejemplo, VS Code se multiplexaría en el nivel de carpetas abiertas a servidores de N idioma?)

@bpasero PHP podría funcionar con rootUris: string[] bastante facilidad. Sin embargo, es posible que otros servidores de idiomas no. Generar varios servidores de idiomas significaría que cada carpeta funciona de forma aislada (sin saltar a la definición, buscar todas las referencias entre ellas). Quizás un enfoque sería un nuevo ServerCapability que decida si VS Code generará uno o varios servidores de idiomas.

Me gusta el concepto de configuración de carpetas adicionales. Para mí, tener una sola carpeta raíz es suficiente. Si quiero una funcionalidad de desarrollo completa en un proyecto asociado, puedo abrir una nueva ventana de vscode.

Lo que necesito de las carpetas adicionales es una funcionalidad limitada. Por ejemplo, podría querer una definición de símbolo de un proyecto asociado para usar en el proyecto raíz, pero no necesito ni quiero la capacidad de cambiarle el nombre o encontrar todas las referencias en la carpeta adicional.

@bpasero Solo estoy abogando por considerar hacer que la creación de un espacio de trabajo en la configuración sea opcional (y optar por participar). Esencialmente, en lugar de cambiar automáticamente la configuración cuando un usuario agrega una carpeta, comience con ella solo en el estado de IU y luego permita a los usuarios guardar esto en la configuración de alguna manera. Quizás también permite elegir si va a la configuración del espacio de trabajo o al usuario.

No estoy completamente en contra de almacenar completamente en configuraciones, solo estoy haciendo mi parte para cuestionar la decisión de no usar el estado de la interfaz de usuario, en caso de que se haya pasado por alto.

@bpasero @saborrie Si tomamos esa ruta, agregaría que cuando se le solicite guardar en la configuración, debería haber una opción para "recordar mi elección" (para guardar espacios de trabajo en la configuración, ya sea la configuración del usuario o la configuración del proyecto). Me decepcionaría abrir una ventana de VSCode, cargar algunas carpetas, hacer que todo funcione como quiero y luego se reinicia o se bloquea y he perdido toda mi configuración para esa combinación de carpetas porque el espacio de trabajo nunca se guardó al disco.

# 396 (comentario)

@Tekbr sí, "Open Editors" funcionará como antes

Gracias por la respuesta, @bpasero.

TL; DR: use una vista de árbol siempre que tenga sentido en lugar de agregar el nombre de las raíces a cada elemento.

Pocas cosas, realmente no me gusta la forma en que agregas la carpeta al final, realmente me gustaría que fuera una opción porque probablemente me gustaría tenerla así express\.editorconfig y express-plugin\.editorconfig así que tal vez puedas ofrecer la siguiente opción: editor.tabName: "${root}\${filename}"

Otra cosa que me gustaría y la mencionas en el video es la coloración sobre las raíces para que coincida con las pestañas, así que 👍 para esto.

Buscar:

En la vista Search , realmente pensaría que estás cometiendo un error en lo que respecta a la experiencia, en mi opinión, debería mostrarse como un árbol, así:

[-] express
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 
[-] express-plugin
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 

Las razones de esto son:

1. Puede ver fácilmente dónde están los archivos independientemente de la longitud de sus nombres.

2. Puede colapsar las raíces que no quiere ver.

Creo que también se ajusta más al tipo de diseño que aplicaste al Explorer .

Tareas:

Por Tasks preferiría tener este tipo de vista:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Pocos puntos:

1. En mi opinión, no debería tocar / cambiar los nombres de las carpetas, lo que significa que "express-plugin" debería mostrarse exactamente como se muestra en Explorer y no como "Express Plugin".

2. Moverse entre tareas con el teclado también se puede hacer de tal manera que ignore la selección de las raíces, por lo que si baja de express\"Run Tests" en el ejemplo, el siguiente elemento que se seleccionaría es express-plugin\Compile opuesto a express-plugin

PD: Aún no he visto el video completo, pero estas solo cosas que me vinieron a la mente

¿Qué pasa si todas las carpetas raíz que incluye en su espacio de trabajo tienen el mismo nombre?
p.ej

• / dev / project / public / src
• / dev / framework / src
• / dev / algún-componente / src

Entonces tendrías un espacio de trabajo con:

[+] src\
[+] src\
[+] src\

Según la forma _sublime_ de incluir carpetas en un espacio de trabajo, cada raíz de carpeta virtual tiene:

• Camino
• Nombre (opcional): este es el nombre de la carpeta si se excluye, pero se puede mostrar como cualquier cosa
• Filtro de exclusión para archivos / carpetas

Consulte la nota https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (arriba) para ver un ejemplo de los metadatos asociados con esta forma de hacer las cosas.

Me gustaría saber que esta función aún se encuentra en la etapa de desarrollo.

@ifzm Lo es y si lee las últimas notas de la versión (mayo de 2017 (versión 1.13)), sabrá que están trabajando activamente en ello.

@eyalsk Lo siento, no miré con atención, esta es una característica interesante: D

No estoy loco por el concepto additionalFolders , aunque entiendo el deseo de mantener las cosas simples.

Me parece extraño que una de un conjunto de carpetas almacene la configuración del "espacio de trabajo".

Imagínese las siguientes carpetas raíz:

• sitio web
• api
• móvil

... ¿qué carpeta debe contener la configuración additionalFolders ? ¿Por qué?

Prefiero la idea de un área de trabajo / administrador de proyectos, donde la configuración se almacena en una ubicación compartida / general. Realmente no creo que esto sea complicado desde una perspectiva de UX, y la terminología existente workspace podría reutilizarse / ampliarse.

No relacionado: Estoy totalmente de acuerdo con los comentarios de @eyalsk sobre las listas anidadas (y el nombre de las pestañas).

@ glen-84 en ese caso, puede tener una cuarta carpeta en el disco llamada "my-mobile-website-project" que tiene esta configuración y enlaces a todas las demás carpetas.

@bpasero Lo entiendo, pero en realidad es solo un truco.

Elaborar:

Estoy ocupado trabajando en website y decido que quiero hacer algunos cambios en api . Si hago clic en Add Folder , se asociará el api con el website , de modo que abrir el website en el futuro abre el api también. Necesito entender cómo funciona esto, y cuando lo haga, tengo que abrir una instancia separada de VSC, crear una carpeta vacía con el nombre apropiado, agregarle ambas carpetas de "proyecto" y luego cerrar la instancia inicial.

Por el contrario, podría simplemente ir Add Folder , y podría (opcionalmente) solicitarme un nombre de espacio de trabajo para usar en el futuro para abrir ambas carpetas al mismo tiempo.

workspaces.json (ejemplo)

{
    "workspaces": {
        "My company workspace": {
            "folders": {
                "/path/to/website": {
                    "folder-setting1": "value1"
                },
                "/path/to/api": {
                    "folder-setting1": "value1"
                }
            },
            "settings": {
                "workspace-setting1": 123
            }
        }
    }
}

Me siento más flexible y menos incómodo para mí.

@ glen-84 entendido. Ir con la solución propuesta hace que el uso de VS Code sea más complejo, por eso optamos por este concepto. La razón principal es que de repente no solo hay "Abrir archivo" y "Abrir carpeta", sino también "Abrir proyecto". Mantenernos con las primitivas que tenemos es el enfoque más sencillo sin introducir nuevos conceptos.

Dicho esto, todo el trabajo que hacemos ahora para admitir varias carpetas es un buen trabajo también para escenarios como el que propones. Si alguna vez queremos apoyar su escenario, los pasos para llegar allí son mucho menos pesados ​​porque la interfaz de usuario ya es adecuada para él. También podría imaginar que tal vez una extensión podría introducir tal noción de espacios de trabajo y simplemente agregamos las API necesarias para respaldar esto.

Primero, hagamos la experiencia de usuario correcta sin introducir nuevos conceptos y luego pensemos en otros escenarios en torno a las carpetas múltiples. Hay muchas cosas que mirar primero (extensiones, configuraciones, interfaz de usuario de SCM, etc.).

su solución propuesta hace que el uso de VS Code sea más complejo

Tengo que estar en desacuerdo con esto. Si un usuario está confundido por una característica opcional de "Proyecto abierto" (o espacio de trabajo), es probable que se sienta confundido por muchas características existentes en VSCode. Esto no es complicado desde la perspectiva del usuario (si alguien que lee esto no está de acuerdo, por favor dígalo).

También podría imaginar que tal vez una extensión podría introducir tal noción de espacios de trabajo y simplemente agregamos las API necesarias para respaldar esto.

La extensión ya existe y ya se ha mencionado varias veces. El autor incluso tiene un soporte de múltiples carpetas de seguimiento de tickets abierto . Esta extensión tiene más de 370k instalaciones y una calificación de 4.7. Incluso con una interfaz de usuario simplista que utiliza la paleta de comandos, hay pocas señales de confusión a juzgar por los comentarios.

Primero hagamos la experiencia de usuario correcta sin introducir nuevos conceptos y luego pensemos en otros escenarios en torno a las carpetas múltiples.

Eso es lo suficientemente justo. De cualquier manera, se trata de admitir varias carpetas raíz dentro de la misma ventana; el método real de administración de estos grupos de carpetas podría abordarse en una etapa posterior.

¿Consideraría crear una encuesta pública para recopilar opiniones de los usuarios sobre el tema (estoy al tanto de los videos de YouTube, pero me refiero a este aspecto por sí solo), o ya se ha tomado la decisión de ir con el additionalFolders concepto?

Estoy de acuerdo con @ glen-84. No entiendo el problema de la complejidad. Sí, puede hacerlo más complejo, pero este es un editor de código. Creo que es el 95% de los programadores los que lo están usando, lo que podría entender fácilmente la idea de proyectos. Debería haber poca preocupación por confundir a la gente todos los días porque todos los días la gente no lo usa.

Si bien una extensión es algo así como una solución, las extensiones también son de segunda categoría en comparación con las mejoras implementadas de forma nativa (es decir, no se pueden agregar opciones a los menús, solo la paleta de comandos, etc.).

@ glen-84, se tomó la decisión de optar por la configuración additionalFolders basada en la opinión del equipo de desarrollo, los estudios de usuarios que hicimos (esos 2 videos) y los comentarios que recibimos en este número.

@pltrant hace que el uso de múltiples raíces sea más complejo porque constantemente tienes que pensar en abrir una carpeta o abrir un proyecto. Cosas como "Abrir reciente" de repente requerirían más atención si la entrada elegida es una carpeta o un proyecto, o peor aún, tendría dos selectores y tendría que decidir cuál usar.

No estoy seguro de cómo tener un entorno es más complejo. Básicamente, no tiene que preocuparse por la configuración, solo agrega y elimina carpetas a su configuración y la configuración se actualiza en segundo plano. Yo diría que nunca se mira el valor de ese entorno en la mayoría de los casos.

@ glen-84 Con respecto a su ejemplo de un proyecto con 3 carpetas de la misma importancia, creo que cuál debería contener la configuración additionalFolders debería decidirse por dependencia. Si la carpeta API no depende de otro proyecto, cuando se abre, debe abrirse como una sola carpeta y no debe contener ninguna configuración adicional de Carpetas. Pero cuando abre la carpeta móvil , supongo que depende de la carpeta API. Por lo tanto, agrega la configuración en la carpeta móvil para abrir la API como una carpeta adicional cuando se abre en vscode. Lo mismo ocurre con el sitio web. Si depende de la API, agregue la configuración allí. Si no es así, no se necesitan ajustes.

No creo que haya una apertura de carpeta adicional recursiva o en cascada. También me gusta la idea de que las extensiones lean otros formatos de proyectos como Visual Studio Solutions y sugieran / coloquen configuraciones adicionales de Carpeta. Y siempre puede abrir la carpeta principal común de todos.

@stevencl vio ambos videos.

1. La alternativa 2 con la desambiguación parece la más clara. Parece que esto podría ser plegable (es decir, una de las raíces del árbol), lo que permitiría ver muchos proyectos a la vez. Si necesita una maqueta, hágamelo saber.

2. La alternativa 2 es más eficiente desde una perspectiva de bienes raíces de pantalla. No tendrá la misma información (nombre del proyecto) repetida en la parte superior, como en la opción 1 y luego se muestra en la raíz de cada proyecto.

3. Los resultados de búsqueda y Git podrían comportarse de la misma manera ... como un árbol plegable. Los resultados se agruparían (junto con el estado) bajo su título correspondiente. Supongo que si desea un resumen navegable (como mostró para GIT, esa sería una opción que podría existir en la búsqueda (cuántos archivos encontró) y el área del proyecto (esto podría albergar los botones de acción).

Entonces, en resumen, soy un fanático de las raíces plegables individuales con la posible adición del resumen navegable. Una especie de combinación de la Alternativa 2 y este ejemplo

Espero que, lo que sea que elijan, hagan que la experiencia sea similar en los distintos mecanismos. Dice que había dos alternativas, pero en realidad hay 4 ya que GIT y Search eran diferentes. Estoy de acuerdo con quien hizo este comentario.

Re: compartir la información multiproyecto. Creo que sería útil, como lo tiene, sería razonable para comenzar, haría que solo usara tareas de trago, o tareas que VS Code pudiera entender.

Gracias por todo su esfuerzo en esto.

La implementación del espacio de trabajo de múltiples raíces se rastrea en el # 28344 y en este hito de junio.

@gulshan ,

Puede haber casos en los que no haya dependencias. Por ejemplo, si estoy trabajando en website y decido agregar mobile para trabajar en él al mismo tiempo. No hay dependencias entre los dos, pero ahora website convierte en el "padre". Si estuve trabajando en mobile primero, entonces se convertiría en el padre. Es un poco arbitrario. Las carpetas también pueden ser para proyectos completamente ajenos.

Independientemente, respeto la decisión de los desarrolladores de VSC, incluso si no necesariamente estoy de acuerdo con ella.

Gracias por todos los continuos comentarios. Como se mencionó anteriormente, estamos rastreando el trabajo en el número 28344. Tendremos en cuenta estos comentarios mientras seguimos trabajando en esto, especialmente al diseñar la experiencia SCM. Como se discutió en los videos y como se mencionó anteriormente varias veces, queremos lograr consistencia a lo largo de la experiencia.

Con respecto al problema de la complejidad que @ glen-84, @pltrant y otros han planteado, gracias por las sugerencias y respuestas detalladas. Entendemos los comentarios y continuaremos monitoreando esto mientras trabajamos en la función.

La discusión sobre esto ha sido realmente útil y nos ha dado algunas cosas en las que pensar para nuestro diseño actual. Por ejemplo, quizás deberíamos considerar permitir que los usuarios elijan la carpeta 'principal' cuando agregan una segunda carpeta a un espacio de trabajo. Tal vez solicitemos esto cuando el espacio de trabajo esté cerrado, tal vez sea una configuración. Hay muchas cosas en las que pensar para optimizar la experiencia.

Sin embargo, como menciona

Además, una vez que algo está en VS Code, es mucho más difícil eliminarlo (con el tiempo la gente se acostumbra y depende de él). Por lo tanto, dedicamos mucho tiempo a considerar cuidadosamente lo que agregamos a VS Code y solo agregamos algo cuando estamos seguros de que el costo de agregar nuevos conceptos valdrá la pena. Así que ahora mismo queremos determinar qué tan exitoso puede ser un diseño para múltiples raíces que no agrega nuevos conceptos.

Una vez más, gracias por los valiosos comentarios. Sin un diálogo como este, sería mucho más difícil diseñar esta experiencia.

Es increíble lo atentos y receptivos que son todos ustedes en el equipo; es muy apreciado!

Lo que probablemente no se haya dicho todavía con respecto a la complejidad es que de todos modos está agregando algo. Creo que estas dos opciones se discuten actualmente:

1. Proyectos explícitos.
2. Algo que se parece a varias carpetas simples pero que en realidad no lo es: hay un concepto importante de carpeta principal que se refiere a cosas como rootUrl para extensiones y posiblemente otras cosas (herencia de la configuración del espacio de trabajo, por ejemplo). Creo que, por lo general, el usuario de VSCode deberá comprender este concepto y tal vez sería más fácil ser claro y directo al respecto en lugar de intentar abstraerlo.

De hecho, preferiría la tercera forma, realmente no presentar nada nuevo, solo manejar cosas como múltiples repositorios .git y búsquedas y tareas y cosas así de una manera transparente, algo así como los primeros dos tercios de los videos sugirió (me gustaron mucho los wireframes). Sin embargo, luego me di cuenta de que rootUrl debe considerarse para las extensiones, que es probablemente la razón principal por la que esto es complicado.

Si no fuera por rootUrl , comenzaría con las actualizaciones de la interfaz de usuario propuestas en los wireframes más la persistencia local del espacio de trabajo de múltiples raíces, de la misma manera que todas las demás carpetas persisten en "Abrir reciente".

Me gustaría repetir que, desde mi punto de vista, el estado ideal es donde VSCode funciona con varias carpetas, independientemente de si son raíces SCM o no (monorepo vs. múltiples repositorios, ver arriba). Creo que los wireframes propuestos más un trabajo central adicional como heredar la configuración .vscode serían suficientes para "v1" de soporte multi-raíz. "Proyectos" o "carpetas principales + adicionales" podrían aparecer más tarde, en mi opinión. Sin embargo, lo que estoy diciendo podría caer en rootUrl , no estoy seguro de eso, solo quiero transmitir mi opinión general sobre esto.

¡Es genial que intente resolver este difícil problema y mantener la simplicidad tanto como sea posible!

Tengo un proyecto de nodo de backend y frontend, y tengo abiertos 2 editores de VisualCode, lo cual es una carga de recursos significativa.

Vi ambos videos y estoy de acuerdo con un comentario anterior de que estos proyectos múltiples no necesitan tener nada que ver entre sí. Quizás uno podría ser un proyecto de nodejs mientras que el otro es C ++.

No me gustó la idea de que uno de los proyectos se convirtiera en el proyecto "maestro", con los proyectos adicionales añadidos. Cada proyecto debe ser igual y no estar relacionado.

Esperaba poder abrir una carpeta y luego abrir otra carpeta (no AGREGAR). La carpeta simplemente se agregará como en el video 1, y las raíces simplemente se mostrarán (pero mostrarán las rutas completas en una información sobre herramientas al pasar el mouse por la carpeta raíz). Estos proyectos no tendrían ninguna relación. Seleccionar uno u otro provocaría un cambio de contexto. Sería como si estuviera cambiando entre 2 instancias de Visual Code, ambas configuraciones, esquemas de color y lo que no.

La forma de conservar estos múltiples proyectos sería guardarlo como un nuevo archivo de proyecto, que hace referencia a los otros dos proyectos, pero sin modificar ninguno de los 2 proyectos en sí. En otras palabras, los 2 proyectos permanecen independientes, autosuficientes y desconocen el 3er proyecto (archivo de configuración) que los hace referencia.

Una vez que se haya guardado / creado este tercer archivo, debería ser posible crear configuraciones que anulen las configuraciones del proyecto A y B. Las configuraciones no creadas dependerán nuevamente del proyecto activo.

Al compartir el proyecto, uno puede compartir el archivo del proyecto que hace referencia a los otros dos. Cuando faltan en el sistema de archivos, pero contienen una referencia a sus URL de github, debe preguntar al usuario si desea recuperarlos (de forma predeterminada, como una subcarpeta en la raíz de ese archivo de proyecto maestro, pero el usuario puede buscar un archivo deseado. ubicación para cada uno).

La capacidad de buscar en varios proyectos debería ser opcional, y la capacidad de ejecutar y depurar varios proyectos simultáneamente sería muy útil, pero parece realmente demasiado complejo para una primera versión, y tal vez tal caso de uso debería requerir ejecutar 2 instancias de todos modos. Por ahora.

Cómo debería verse esto en la interfaz de usuario es el paso dos, pero funcionalmente así es como espero que funcione. No me gusta la idea de modificar el proyecto A para hacer referencia a B o viceversa, y eso es lo que entendí que era la intención. Para el desarrollo ágil, estaría feliz si pudiera trabajar en 2 proyectos en 1 ventana en lugar de tener que ejecutar 2 instancias, pero no más que eso por ahora. Quizás ni siquiera con el tercer archivo de proyecto principal, pero solo con cambio de contexto.

Gracias por los continuos comentarios. Existe un tema definido sobre el retraso de la persistencia de un espacio de trabajo de varias carpetas hasta que el usuario realice alguna acción explícita (como guardar). Tendremos que pensar más en esto e investigar más.

También sugeriría a los desarrolladores que echen un vistazo a Eclipse IDE sobre cómo
maneja esta funcionalidad, la descubrieron hace mucho tiempo y funciona
estupendo.

El martes 13 de junio de 2017 a las 9:11 a.m., Steven Clarke [email protected]
escribió:

Gracias por los continuos comentarios. Hay un tema definido sobre
retrasar la persistencia de un espacio de trabajo de varias carpetas hasta que
acción del usuario (como guardar). Tendremos que pensar más en esto
e investigar más.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
.

-
Daniel Sokolowski
Arquitecto Técnico

Stantive Technologies Group Inc.
Teléfono: +1 (613) 634-7410
http://www.stantive.com

Aviso de confidencialidad:
La información transmitida está destinada únicamente a la persona o entidad a
a la que se dirige y puede contener información confidencial y / o privilegiada
material. Cualquier diseminación de retransmisión de revisión u otro uso de o
tomar cualquier acción en base a esta información por personas o
se prohíben entidades distintas del destinatario previsto. Si recibiste
esto es un error por favor contacte al remitente inmediatamente por devolución electrónica
transmisión y luego elimine inmediatamente esta transmisión, incluidas todas
adjuntos sin copiar distribuir o divulgar los mismos.

Proyecto Master
Estoy en contra de tener un proyecto MASTER. El cambio de contexto ocurre con frecuencia cuando se trabaja con diferentes microservicios. Esto se aplica a los siguientes puntos sobre Linting y SCM.

Persistencia del espacio de trabajo
Creo que en la primera iteración, no deberíamos tener que conservar el espacio de trabajo. Preferiría iteraciones en una o dos versiones de esta función antes de introducir configuraciones o capas de persistencia para minimizar cualquier tipo de migraciones complejas o destructivas.

Linting / Configuración
El linting específico del proyecto debe tener un espacio de nombres en archivos en los directorios correspondientes. Por ejemplo, el Proyecto A usa más bonito mientras que el Proyecto B usa estándar. El cambio entre ambos contextos debe ser perfecto sin que las reglas entretejidas entren en conflicto entre sí.

Buscar
Me encantaron algunos de los wireframes para este en el que los resultados de búsqueda estaban en todos los proyectos y estaban ordenados por proyecto.

_Project A_
file1: matched substring
file2: matched substring
...

_Project B_
file3: matched substring
file4: matched substring

SCM
En este caso, me inclino más a mostrar un desglose por proyecto con cada cambio de scm.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

Siento que estos enfoques son más transparentes e intuitivos.

El consenso (basado en comentarios recientes y otras cuestiones) parece estar en contra de la idea de additionalFolders , al menos en la versión inicial.

Si bien entiendo que ya se ha tomado la decisión, ¿consideraría intentar implementar esta función como un conjunto de API, dejando la persistencia para una iteración posterior? Por lo tanto, API para agregar / abrir carpetas y actualizaciones del explorador, búsqueda, tareas y vistas de SCM para respaldar esto.

Ha hablado de lo difícil que es eliminar algo del producto (si un concepto de proyecto / espacio de trabajo falla de alguna manera), pero la realidad es que esto se aplica por igual (si no más) al concepto additionalFolders .

La implementación de additionalFolders y "proyectos / espacios de trabajo" como extensiones le permitiría recopilar datos de uso sin comprometerse con un solo modelo. Una de estas extensiones (o una solución híbrida) podría integrarse posteriormente en el producto.

¿Se han solucionado los problemas con el medio ambiente en Mac OS? Todavía no puedo usar Homebrew npm y demás sin abrir VSCode desde la línea de comando a través de code y esto seguramente causará estragos en el soporte de múltiples raíces.

Sí, esto también es imprescindible para mí. No entiendo los problemas de la gente con eso. Puede que no sea la forma en que trabaja una persona, pero eso no significa que la gestión del espacio de trabajo preferido de otra persona sea menos válida. Simplemente detesto las respuestas de "¿Por qué quieres hacer eso?" en lugar de "Averigüemos cómo agregar una función que tienen todos los demás editores de código del mundo".

De vuelta a Atom, supongo.

@saborrie https://github.com/Microsoft/vscode/issues/24961 (obtengo el mismo problema tanto en Insiders como en versiones regulares). Si puedo ayudar a depurarlo, estoy listo.

@akutz estos muchachos se han

Hola @cliffrowley ,

Me alegro de oirlo. Recientemente eché otro vistazo a VSCode, ya que he estado usando Atom desde siempre (y Sublime antes de eso). Recientemente, Atom ha sido problemático y en un hilo de Reddit vi que VSCode era realmente una gran opción en estos días. Así que me sorprendió que no fuera compatible con una función básica.

Simplemente acumulando aquí: esta es realmente la única característica que me impide considerar cambiar de IntelliJ / WebStorm a VSCode a tiempo completo ... principalmente porque, como se mencionó en un póster anterior, trabajo con arquitecturas distribuidas todo el día y necesito múltiples administraciones de Git integradas a mi editor (porque soy muy vago 😆)

Me encanta que todos estén trabajando en esto y no puedo esperar a verlo en acción.

Me gusta vscode, pero esta "característica faltante" me impide cambiar completamente de atom a vscode

Una primera versión ya está en la compilación Insiders. Ve a buscarlo :)

+1 Necesita esta función

¡La primera versión de vista previa es muy buena gente!
Sin embargo, ya hay un pequeño problema antes de comenzar a probar correctamente ...
Cuando agrego dos carpetas "raíz" con el mismo nombre de dos proyectos separados, no hay nada que distinga estas carpetas.

por ejemplo, agrego /dev/www/myproject/src y luego agrego /dev/libraries/mycomponent/src
Todo lo que veo son dos carpetas raíz llamadas src .

> src
> src

Creo que necesitamos una forma de cambiar el nombre para mostrar de las carpetas raíz.
Que luego mostraría:

> My Project (/src)
> Component 1 (/src)

Pensamientos

VSCode muestra parte del nombre de la carpeta cuando abre dos archivos con el mismo nombre, ¿eso también podría funcionar con carpetas?

@doublehelix discutimos esto recientemente pero no teníamos ningún lugar para rastrear el problema. Creé https://github.com/Microsoft/vscode/issues/29871 , gracias 😄

@Tyriar Realmente encuentro la funcionalidad de búsqueda confusa por decir lo menos y creo que debería mostrar los resultados de manera similar a como se muestran en el Explorer como he dicho antes .

No sé si ustedes miraron lo que algunas personas y yo dijimos anteriormente o si vendrán más cambios, pero personalmente no me gusta la forma en que agregan el nombre de la raíz cada vez en lugar de ordenar las cosas en un árbol. -como vista cuando sea posible.

@eyalsk Es un trabajo en progreso, estaré mirando más resultados de búsqueda en julio: # 29977

El proyecto vscode se basa en una carpeta.
Por lo tanto, puede configurar la configuración de cada proyecto por separado, y puede usar el Git integrado directamente, o no, no puede.

PyCharm: corazón:: corazón:: corazón:

+1

Tengo que felicitarlo, querido equipo de VSCode.
¡Finalmente puedo deshacerme de Atom desde que los espacios de trabajo de múltiples raíces aterrizaron en Insiders Builds!
Desde hace dos años, .gitignore, etc.no se respetan en Atom cuando se busca en espacios de trabajo de múltiples raíces y ¡lo hizo bien desde el principio!

¿Se realiza un seguimiento de la persistencia de los espacios de trabajo en otro problema?

Ayer, el equipo de VS Code lanzó una nueva versión de VS Code con la función Multi Root Workspaces 🎉.

El resultado de este trabajo es lo que llamamos un "Producto mínimo viable" (MVP) para permitir las pruebas en varios espacios de trabajo de carpetas raíz.

En realidad, solo está disponible en la compilación Insiders, por lo que puede descargarlo aquí Descargar VS Code Insiders

Explorador de archivos

Buscar

Suponga que cada carpeta agregada al espacio de trabajo es un repositorio de git separado: ¿la versión actual de Multi Root Workspaces maneja el control de fuente diferenciado de esos repositorios?

@Weyzu estamos trabajando en la adopción de SCM para escenarios de múltiples raíces en este hito. Nuestro pensamiento inicial es que la vista SCM debe ser compatible con múltiples repositorios, lo cual no es necesariamente lo mismo que con múltiples carpetas como en el explorador y la búsqueda: ya cuando abre una sola carpeta en VS Code, podría tener múltiples repositorios dentro . Creemos que la vista SCM debería mostrar estos repositorios de una buena manera para que pueda ver los cambios salientes / entrantes para cada repositorio, así como para poder enviar archivos de cada repositorio.

El resultado debería proporcionar una mejor experiencia tanto para escenarios de múltiples raíces como para escenarios de raíz única donde varios repositorios están contenidos en una raíz.

El resultado debería proporcionar una mejor experiencia tanto para escenarios de múltiples raíces como para escenarios de raíz única donde varios repositorios están contenidos en una raíz.

Excelente enfoque, chicos rockeras!

@bpasero impresionante! Definitivamente me interesaría ver cómo lo hacen sus chicos. IntelliJ / WebStorm tiene algo similar en el que detecta automáticamente las raíces de Git y las alinea adecuadamente en la parte inferior derecha, y personalmente me encantó usarlo.

¿Estaban pensando en algo parecido o en algo un poco más elaborado?

Todavía estamos resolviendo la UX para esto y lo mantendremos informado sobre los resultados.

¿No podría funcionar aquí una raíz del sistema de archivos virtual? Actuaría efectivamente como si la raíz de VFS fuera el directorio principal para varias rutas dispares.

Quería dar una actualización sobre nuestro trabajo multi-root porque hoy es el primer día en el que nuestra UX multi-root revisada ha sido lanzada desde adentro y muchos de ustedes que se acostumbraron al comportamiento "antiguo" podrían estar confundidos sobre lo que está pasando.

Defectos de la vieja solución
La solución anterior para múltiples raíces introduciría una nueva configuración workspace (en el settings.json global) que permite agregar carpetas adicionales a una sola carpeta raíz. La configuración se ve así en caso de que no lo haya notado:

{
  "path to folder": [
      "additionalFolder1",
      "additionalFolder2"
   ]
}

A esta solución la llamamos carpeta "maestra" con carpetas adicionales ("detalle").

Esta fue la solución más sencilla sin introducir muchos conceptos nuevos, pero también tiene fallas:

• nunca más podría abrir la carpeta maestra como una sola carpeta porque la configuración persistió
• no pudo eliminar la carpeta maestra del explorador
• algunas configuraciones de la carpeta maestra aplicadas a todas las demás carpetas
• su configuración se contamina con elementos de configuración de múltiples raíces
• es difícil permitir que se abran un par de carpetas al mismo tiempo (por ejemplo, cuando abre 3, ¿qué carpeta maestra deberíamos tomar?)

Nuestra solución
Creemos que se necesita un concepto de espacio de trabajo más explícito para escenarios de múltiples raíces y, como tal, en la información privilegiada de hoy verá aparecer una nueva interfaz de usuario:

La idea es que los espacios de trabajo de múltiples raíces requieren que se cree una acción explícita. De la misma manera que puede estar en un espacio de trabajo vacío (sin carpeta abierta, barra de estado violeta) o en un espacio de trabajo de una sola carpeta (barra de estado azul claro), también puede estar en un espacio de trabajo de múltiples raíces (estado azul oscuro bar). Esta tercera forma de abrir un espacio de trabajo en VS Code permite tener tantas carpetas como quieras. Estos espacios de trabajo se pueden guardar en un archivo (por ejemplo, myWorkspace.code ) y también incluyen la configuración del espacio de trabajo. Sin embargo, no está obligado a guardarlos, siempre que no desee guardarlos, aparecerán como "Espacios de trabajo sin título".

Para abrir un espacio de trabajo, puede abrir el archivo del espacio de trabajo guardado o seleccionar de la lista abierta recientemente:

Todo esto es código muy joven y UX muy joven, así que espere algunos cambios durante las próximas semanas. Sabemos que aún quedan algunas cosas por resolver (por ejemplo, ¿cómo podemos hacer que la transición de una sola carpeta a varias carpetas sea más fluida)?

Un par de cambios que ya se realizaron hoy y que afectarán a la versión interna de mañana según los comentarios:

• cambiar el nombre de .code a .code-workspace como extensión para espacios de trabajo
• tener una lista unificada de carpetas y espacios de trabajo (por ejemplo, en Archivo> Abrir reciente) en lugar de distinguir entre carpetas y espacios de trabajo

Estén atentos para más por venir 👍

Además de esto, ahora tenemos una carpeta .vscode por carpeta de proyecto que contiene el archivo settings.json . Este archivo puede contener lo siguiente:

// Place your settings in this file to overwrite default and user settings.
{
      "editor.wordWrap": "on",
      "files.autoSave": "onFocusChange",
       "editor.fontSize": 15
}

El problema aquí es que cuando queremos trabajar con varios usuarios (sesión RDP diferente) en el servidor en las mismas carpetas del proyecto, compartimos la misma configuración. Puede que este no sea el comportamiento previsto. Puede que me guste que mi tamaño de fuente sea mayor que el de mi colega

Entonces, en mi opinión, también debe tener en cuenta que diferentes usuarios pueden estar trabajando en las mismas carpetas pero con diferentes configuraciones en settings.json .

@ DarkLite1 mencionas un buen punto. En nuestro diseño de configuración para multi-root, intentamos identificar configuraciones que podemos admitir por carpeta y configuraciones que no podemos admitir. Por lo general, decimos que las configuraciones que se dirigen al editor o un recurso específico se pueden admitir por carpeta porque está claro desde qué carpeta se abrió el editor. Otras configuraciones que no serán compatibles son más la personalización del banco de trabajo (por ejemplo, mostrar la barra de estado o no).

Su ejemplo es sobre la configuración editor.fontSize que realmente admitimos por carpeta incluso en un espacio de trabajo de múltiples raíces. Creo que podría ser un escenario válido que un usuario quiera tener un tamaño de fuente más grande para una carpeta que contiene mucha documentación de rebajas (¿incluso una fuente diferente tal vez?). Entonces, creo que no deberíamos evitar respetar esta configuración por carpeta también en un entorno de múltiples raíces.

Si desea mantener editor.fontSize como configuración de espacio de trabajo personal, creo que no debería registrarse en el repositorio.

Con el nuevo concepto de espacios de trabajo, puede hacer lo siguiente:

• Archivo> Espacios de trabajo> Nuevo espacio de trabajo
• Elige tu carpeta
• Abrir la configuración del espacio de trabajo
• Cambiar editor.fontSize: 15

A partir de ese momento, su espacio de trabajo llevará esta configuración, pero no se la está forzando a nadie más.

Desde la perspectiva de UX, sería conveniente si pudiera arrastrar y soltar carpetas en una ventana de VS Code sin tener que crear explícitamente un espacio de trabajo primero (es algo que hago todo el tiempo en Sublime). Invariablemente trabajo en varios proyectos al mismo tiempo y, dependiendo de en qué esté trabajando, cada día habrá un conjunto de proyectos diferente (superpuesto).

Los espacios de trabajo introducirían un concepto que no es nativo de mi forma de trabajar, y tendría que realizar un seguimiento de las diferentes configuraciones del espacio de trabajo (según tengo entendido), lo que parece crear un desorden de configuración en las carpetas de mi proyecto.

Además, creo que hablo en nombre de muchos usuarios si diría que cosas como la búsqueda, la configuración son globales de forma predeterminada (se aplican a todas las carpetas abiertas), aunque sería bueno si tuviera la opción de buscar localmente en una carpeta ( Siempre encontré esto complicado en Sublime).

@SanderMertens Puede que te hayas perdido esto, pero @bpasero escribió;

Estos espacios de trabajo se pueden guardar en un archivo (por ejemplo, myWorkspace.code) y también incluyen la configuración del espacio de trabajo. Sin embargo, no está obligado a guardarlos, siempre que no desee guardarlos, aparecerán como "Espacios de trabajo sin título".

Ahora, no estoy seguro de si tendrías la capacidad de arrastrar y soltar carpetas, pero por lo que obtengo, la gente podría abrir carpetas arbitrarias sin crear un espacio de trabajo.

No puedo esperar a que esta función se incluya en la versión estable.

¡Hurra! 😄

Actualmente no puede arrastrar una carpeta al explorador para agregarla, pero esto está en nuestro trabajo pendiente. La complicación con esta interacción es que no conocemos la intención del usuario: ¿abrir la carpeta en la ventana o agregarla al espacio de trabajo?

La transición de 1 carpeta a muchas carpetas actualmente es un paso más explícito en comparación con lo que hacen otros editores (debe ir a Archivo> Espacios de trabajo> Guardar espacio de trabajo y elegir las carpetas que desee). Hay un par de razones por las que queremos seguir con el comportamiento actual por ahora hasta que se estabilice la raíz múltiple. La razón principal es que multi-root es un cambio importante para todas nuestras extensiones. Si bien el explorador funciona y puede buscar en todas las carpetas, la mayoría de las extensiones no funcionarán correctamente hasta que se adopte la nueva API de múltiples raíces. Como tal, no queremos que sea demasiado fácil al principio ingresar a multi-root por accidente. Es un gesto explícito del usuario ingresar a espacios de trabajo de múltiples raíces y en ese modo podríamos querer llamar la atención sobre el hecho de que algunas extensiones aún no están funcionando.

Otra razón es la configuración del espacio de trabajo: imagina este flujo:

• comienza con 1 carpeta que tiene configuraciones de espacio de trabajo
• agrega una segunda carpeta (suponga que esto funciona sin cambio de contexto y recarga de ventana)
• abres la configuración del espacio de trabajo
  => la configuración del espacio de trabajo en raíz múltiple ahora se almacena en alguna ubicación fuera de las carpetas porque puede tener múltiples
  => probablemente necesitemos preguntarle al usuario si el usuario quiere migrar la configuración del espacio de trabajo a esa nueva ubicación

Entonces, pase lo que pase, ingresar a multi-root no es una operación liviana actualmente. Podríamos revisar esto cuando el polvo se asiente y se adopte ampliamente el uso de múltiples raíces, pero por ahora creemos que este modelo es mejor y evita la frustración.

@bpasero Creo que, de forma predeterminada, una vez que arrastra una carpeta al explorador, no debería guardarla automáticamente en el espacio de trabajo, aunque pueda existir una y esta debería ser una acción explícita en la que el usuario haga clic en la carpeta (s) que él / ella arrastrado y luego agréguelo explícitamente al espacio de trabajo y si tiene pocas carpetas no relacionadas, podría ser sensato proporcionar otra acción para guardarlas todas a la vez.

Todo depende de los casos de uso que uno quiera cubrir. He descubierto por experiencia que KISS es siempre el mejor enfoque. Presentar Workspaces suena genial como feature pero ¿cuál es el beneficio real y cuáles son las desventajas?

Una desventaja que me viene a la mente al introducir y usar Workspaces es que necesita almacenar sus datos (configuraciones) en algún lugar y requiere mantenimiento / conciencia del usuario.

Suponga que el único objetivo es brindar a los usuarios la capacidad de trabajar con varias carpetas en una sesión de VS Code. Nada menos, nada más.

Caso de uso más común:
No hay concepto de Workspaces . El usuario simplemente abre una carpeta adicional, o tantas como quiera, y se abren en la vista de la izquierda como lo hace una sola carpeta. Espera que su configuración sea la misma en todas partes. independientemente de dónde se encuentren sus archivos. Y no quiere ningún desorden adicional de archivos de configuración de VS Code entre sus archivos de proyecto, como lo indica @SanderMertens , yo y probablemente otros también.

Desafíos / Problemas / Preguntas:

• ¿Por qué hay tantos archivos de configuración diferentes? Configuración de usuario, configuración del espacio de trabajo? En mi humilde opinión, todo debe almacenarse en el mismo lugar. Preferiblemente en el usuario su carpeta / perfil personal, por lo que cada usuario en el sistema puede tener su propia configuración. Bonificación extra. no abarrotan los archivos del proyecto y varios usuarios pueden hacer lo suyo. ¿Borrar el perfil? ¡Excelente! Borrón y cuenta nueva para VS Code también.

Creo que Workspaces son un poco de ingeniería excesiva si quieres:
Velocidad, simplicidad y un editor que simplemente funciona, sin complicar demasiado las cosas ni entender conceptos adicionales. Si los usuarios de Sublime u otros editores no usan este concepto en su flujo de trabajo, eso debería ser una indicación de que están pensando demasiado. O podría significar que se inventó algo realmente asombroso que otros editores también implementarán, pero tengo mis dudas.

Lo siento si esto suena como una perorata, esa no es mi intención en absoluto. Pero creo que podemos hacerlo mejor con respecto al acceso a múltiples raíces / carpetas.

@ DarkLite1 gracias por tomarse el tiempo para brindar comentarios sobre nuestra nueva estrategia para espacios de trabajo.

Estoy de acuerdo con todos sus puntos y también quiero una solución simple. Los espacios de trabajo como concepto son nuestro primer paso hacia una solución de múltiples raíces que funciona con nuestros patrones existentes (configuración del espacio de trabajo, extensiones, etc.). Dado que este es el primer paso, espere algunos bordes más ásperos (por ejemplo, la transición de 1 a N carpetas no es tan liviana como podría ser). Nuestro objetivo es facilitar esta transición y no hacerla más compleja de lo necesario en el futuro. Y tampoco queremos obligar a un usuario a administrar estos espacios de trabajo (es por eso que tenemos "Espacios de trabajo sin título" que viven mientras la ventana esté abierta y desaparecerán una vez que cierre esa ventana).

Hay un par de cosas en torno a los espacios de trabajo de múltiples raíces a tener en cuenta que tal vez no sean tan obvias. Espero que la siguiente explicación detallada ayude a comprender nuestro proceso de diseño:

Configuración del espacio de trabajo
Admitimos tener configuraciones dentro de una carpeta de espacio de trabajo (carpeta .vscode ). Por mucho que a algunos usuarios no les guste este tipo de configuraciones que terminan en archivos .gitignore o en el repositorio, hay muchos que confían en esta funcionalidad. No podemos simplemente dejar de admitir configuraciones que se encuentran dentro de las carpetas porque los usuarios confían en ellas. Ahora, para escenarios de múltiples raíces, está claro que tenemos que encontrar un nuevo lugar para la configuración del espacio de trabajo. Se nos ocurrió el concepto de un archivo de espacio de trabajo que contiene estas configuraciones. Siempre que el espacio de trabajo no se guarde en ningún lugar, reside en una carpeta que contiene otros datos específicos de VS Code y, cuando guarde el archivo, la configuración estará dentro de ese archivo.

Ahora imagine que comienza con 1 carpeta en VS Code que tiene la configuración del espacio de trabajo definida y desea agregar una segunda carpeta. ¿Qué debemos hacer ahora? ¿Ignora la configuración del espacio de trabajo de la primera carpeta? ¿Pedir al usuario que migre la configuración? Decidimos hacer de esto un cambio de contexto explícito para dejar en claro que abrir un espacio de trabajo conlleva su propia configuración de espacio de trabajo en una ubicación diferente.

Y ahora imagina que pasaste de 1 carpeta a 2 carpetas y movimos la configuración del espacio de trabajo a otro lugar. Imagine que realiza cambios en la configuración de este espacio de trabajo. Ahora que desea volver de 2 carpetas a 1, ¿esperaría migrar la configuración del espacio de trabajo a la carpeta?

Otro ejemplo: hace la transición de 1 a 2 carpetas y configura los ajustes del espacio de trabajo. Ahora cierra la ventana. Creo que se enojaría con nosotros si no pudiera volver a este espacio de trabajo de alguna manera porque configuró cuidadosamente los ajustes para este espacio de trabajo. Entonces, aunque no le gusta el concepto de un espacio de trabajo, una vez que configure los ajustes para él, creo que desea que ese espacio de trabajo viva.

Espero que estos ejemplos hagan que sea un poco más fácil entender por qué KISS no es tan fácil para nosotros como podría pensarse.

Extensiones
Todas nuestras extensiones siempre funcionaron en contra de una API que proporciona una única ruta de espacio de trabajo porque hasta ahora no admitíamos espacios de trabajo de múltiples raíces. Como usuario, podría pensar que cambiar de 1 carpeta a 2 carpetas es una operación muy simple y liviana, pero para las extensiones puede significar muchas cosas: las extensiones de idioma que hasta ahora asumían que solo hay una carpeta de repente tienen que ser conscientes de múltiples carpetas. Y además de eso, estas carpetas pueden ir y venir de forma muy dinámica en cualquier momento.

La introducción de un concepto de espacio de trabajo real nos da más espacio y tiempo para ampliar y ayudar a las extensiones a adoptar este concepto. Por ejemplo, podríamos deshabilitar extensiones que aún no han adoptado espacios de trabajo de múltiples raíces para evitar que sucedan cosas extrañas (por ejemplo, una extensión de idioma solo funciona en una carpeta e informa errores incorrectos en la otra).

Primero tratemos de estabilizarnos en el soporte multi-raíz con estos nuevos espacios de trabajo y luego revisemos cuán ligeras podemos hacer las transiciones. Una vez que tengamos las extensiones a bordo y descubramos nuestra historia de configuración, creo que podemos hacer el cambio a una experiencia más ligera.

PD: ya que hace referencia a otros editores con respecto a su soporte multi-raíz, solo quería señalar que estos editores también vienen con un concepto de proyecto o espacio de trabajo que puede guardar en un archivo y compartir con otros. Normalmente, no ve estos conceptos porque pasar de 1 a N carpetas es una operación muy ligera. Sin embargo, diría que las personas que dependen de esta función comienzan a moverse a espacios de trabajo / proyectos guardados como una forma de administrar el trabajo. Por ejemplo, a menos que guarde el espacio de trabajo / proyecto y cierre la ventana, toda esta información se pierde.

@bpasero gracias por

Como no estoy completamente familiarizado con Sublime, me tomé la libertad de verificar cómo manejan esto. Y tienes razón, también usan Workspaces e incluso archivos Project . Lo único que me molesta un poco es que coloca archivos de VS Code entre mi proyecto. Pero como mencionaste, si otros confían en esto, hay que tener en cuenta que esto podría ser lo mejor. Solo me pregunto por qué estos archivos de configuración no son específicos del usuario. Puedo imaginar a un colega abriendo VS Code en la misma estructura de carpetas, pero queriendo tener su propia configuración.

Si Workspaces son el camino a seguir, y parece que lo son, sería lógico que al abrir la aplicación se recargue la última configuración utilizada. Incluso si se trata de un Workspace no guardado. Hace la vida un poco más simple, supongo.

¿Por qué elegí VS Code? Debido a que es multiplataforma, ya que uso Linux en casa y Windows en el trabajo, ¡este podría convertirse en mi editor predeterminado! Como beneficio adicional, soy un desarrollador de PowerShell y también hay una extensión para ello. ¡Así que dos grandes victorias allí! Además de eso, para el curso de Java que estoy siguiendo, Red Hat está haciendo una extensión también para VS Code. Entonces, una vez que conozca mejor VS Code, con sus atajos y todo, se beneficiará en todos los ámbitos.

La aplicación y sus extensiones todavía están un poco en estado beta o incluso alfa en algunos puntos, pero aún así, ¡buen trabajo, chicos! Realmente aprecie los esfuerzos y vea el progreso en las compilaciones de Insider todos los días. Sigan con el gran trabajo y tengan un buen fin de semana.

Gracias por esa explicación @bpasero , creo que ahora entiendo mejor cuál es la complejidad.

Un enfoque podría ser tratar conceptualmente cualquier conjunto de proyectos con la misma configuración que un espacio de trabajo. Además de eso, puede abstenerse de agregar una carpeta .vscode siempre que el proyecto no difiera de la configuración predeterminada. Eso deberia:
1) deshacerse de la mayor parte del desorden en los proyectos
2) evitar la mayoría de los conflictos de configuración al agregar proyectos (en el caso simple, no habrá configuración)

Creo que el concepto de espacio de trabajo explícito como se discutió es una buena solución al problema mencionado. Con estas dos reglas simples, minimizo los casos de uso en los que las personas se encuentran con este problema.

Para mí, al observar los comentarios en el hilo y mis casos de uso, veo _Multi-folder_ y _Workspaces_ como dos conceptos diferentes, y tal vez también deberían tratarse por separado.

No debería obligar a _crear un espacio de trabajo_ solo para agregar otra carpeta a la ventana actual. Solo debería agregar la nueva carpeta en el árbol y dejar el espacio de trabajo recién creado como una _información interna_. Si el usuario decide guardar el espacio de trabajo, realmente se crea el espacio de trabajo. E incluso si no guardo el espacio de trabajo, al reabrir la carpeta superior, _recordaría_ mi espacio de trabajo temporal_ y también abriría las otras carpetas, tal como recuerda los archivos abiertos cuando abre una carpeta hoy. Por cierto, me pregunto cómo podría abrir varias carpetas en la línea de comandos.

Para mis casos de uso, la carpeta múltiple es solo una forma de ver más de una carpeta a la vez en la misma ventana, no un enfoque _Project Group / Solution_. Entonces, cabría una solución más simple. Pero entiendo cómo otros necesitan un _Workspace_, con su propia configuración y así: thumbsup :

Lo que más me molesta de este nuevo concepto de espacios de trabajo (en comparación con la primera iteración con User Settings ) es lo mismo que me molestaba cuando usaba Sublime Text. El hecho de que usted _pueda_ guardar los archivos .code-workspace _en cualquier lugar_, y ahora tengo que administrar un lugar común para almacenarlos. Sería mucho más simple, en mi humilde opinión, que encajaría automáticamente, en uno de estos dos lugares:

• dentro de la carpeta user-data-dir , como User Settings y Keybindings
• dentro de la _ Carpeta superior_

Para ser claros, entiendo el concepto de espacio de trabajo más complejo que necesitan otros usuarios. Solo quería un enfoque más simple para un concepto de múltiples carpetas más simple.

Me gusta esta opción, agregue esta opción.

Porque la carpeta interior no es muy impresionante.

o agregue la capacidad de cambiar esta opción.

¡Me gusta la idea del espacio de trabajo! ¿Alguna idea de cuándo estará listo?

¿Se espera en este punto que la información de git en la esquina inferior izquierda no refleje con precisión la rama git de cualquier repositorio en el que se encuentre el archivo actualmente enfocado? No vi nada sobre "múltiples raíces de git" en las notas de la versión v1_15.

He estado usando esta función con la compilación de Insider durante unos días y debo decir que es todo lo que quería que fuera. Experiencia de usuario muy limpia y no puedo esperar hasta que esté en la compilación principal para poder convertir a todo mi equipo a esto.

Cuando se trabaja con NodeJS y se abren varios módulos NPM a la vez, la forma en que se pone todo junto en una ventana es un gran ahorro de tiempo.

¡Grandes apoyos para el equipo!

¿Por qué esta función aparece en mis notas de lanzamiento con un gif y una explicación, pero no está disponible en el editor real?

@ShashankaNataraj que se basa en la compilación

Nuestra hoja de ruta para el trabajo de múltiples raíces en curso está capturada en https://github.com/Microsoft/vscode/issues/28344 y continuará hasta agosto, septiembre y probablemente también octubre.

Mantendremos esta función disponible solo para personas con información privilegiada hasta que:

• podemos proporcionar una experiencia adecuada de SCM, depuración y tareas habilitadas para múltiples raíces
• Adoptamos API y funcionalidad de múltiples raíces para las extensiones con las que enviamos y a las que contribuimos activamente (por ejemplo, Go)
• los autores de la extensión tuvieron suficiente tiempo (por ejemplo, un hito) para adoptar las nuevas API de múltiples raíces

Por favor, comprenda que queremos evitar enviar esta función a estable y tener una experiencia de extensiones rota porque apresuramos esta función demasiado pronto.

Gracias por ser chicos profesionales, ¡gran trabajo!

@bpasero Estoy un poco preocupado por los autores de extensiones que actualizarán los complementos a la vez. ¿Reciben algunos correos electrónicos especiales sobre cambios de última hora?

Gracias

@FelikZ , consulte nuestra hoja de ruta (https://github.com/Microsoft/vscode/issues/28344). Para el lanzamiento de septiembre, planeamos adoptar las extensiones que enviamos en VS Code y, mientras estamos trabajando en eso, agregamos las API y utilidades necesarias para hacerlo.

Durante septiembre este es el plan:

La actualización interna de hoy viene con algunos cambios en el archivo .code-workspace que quería resumir aquí. Los espacios de trabajo existentes con el formato anterior se migrarán automáticamente al nuevo formato.

El formato antiguo se veía así:

{
    "id": "1500007676869",
    "folders": [
        "file:///Users/bpasero/Development/Microsoft/monaco",
        "file:///Users/bpasero/Development/Microsoft/vscode-distro",
        "file:///Users/bpasero/Development/Microsoft/vscode-docs",
        "file:///Users/bpasero/Development/Microsoft/vscode-extension-sdk"
    ]
}

Y el nuevo formato es:

{
    "folders": [
        { "path": "/Users/bpasero/Development/Microsoft/monaco" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-distro" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-docs" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-extension-sdk" }
    ]
}

ID del espacio de trabajo
El ID del espacio de trabajo se usa para asociar un par de cosas con el espacio de trabajo:

• todo el estado de la interfaz de usuario (por ejemplo, archivos abiertos)
• todo el estado del archivo sucio (también conocido como salida en caliente)
• estado de extensiones (si corresponde)

Decidimos eliminar la propiedad id del archivo del espacio de trabajo y, en su lugar, calcular id automáticamente en función de la ruta absoluta del archivo del espacio de trabajo en el disco. Esto tiene un par de ventajas y desventajas, pero al final creemos que las ventajas hacen que esta sea una mejor solución:

• era extraño que pudieras editar el id en el archivo simplemente escribiendo otro valor
• No estaba muy claro cómo tratar el id cuando se comparte el archivo del espacio de trabajo con otros (¿debería cambiarse el id ? ¿Debería el id ser un uuid?)
• no fue posible copiar un archivo de espacio de trabajo y abrirlo en una ventana separada, tuvo que cambiar el id primero en el archivo copiado
• como consecuencia, la acción "Guardar espacio de trabajo como" tendría que preguntar al usuario si la copia debe tener un id o no

Una desventaja de este enfoque es que una vez que mueva o cambie el nombre de un archivo de espacio de trabajo, se perderá el estado asociado. Los archivos sucios ("salida en caliente") se volverán a abrir después de un reinicio, pero se abrirán en una ventana vacía y ya no estarán asociados con la ventana del área de trabajo. Seguimos pensando que podemos mejorar este comportamiento, aunque se comporta de manera coherente con lo que sucede hoy cuando cambia el nombre de una carpeta con el estado de la interfaz de usuario asociado y los archivos sucios.

Carpetas
Decidimos revisar el formato de la propiedad folders .

• ya no le pedimos que utilice URI de recursos, sino solo rutas de archivo para facilitar la edición
• cambiamos las entradas de la propiedad folders para que sean objetos de modo que podamos asociar metadatos a las entradas según sea necesario (por ejemplo, cada carpeta podría tener una propiedad name adicional)

Finalmente, también ha aterrizado el soporte para rutas relativas. Puede ingresar una ruta de archivo relativa y se resolverá en la carpeta principal del archivo del espacio de trabajo. Tenga en cuenta que debido al error https://github.com/Microsoft/vscode/issues/33188 , actualmente estamos reescribiendo rutas relativas a rutas absolutas al realizar cambios en el archivo del espacio de trabajo.

@bpasero es increíble. ¿Cuándo funcionará la propiedad adicional name ? En este momento tengo dos carpetas con el mismo nombre en mi espacio de trabajo y es horrible.

@DaniloPolani ver https://github.com/Microsoft/vscode/issues/29871

Una actualización del manejo de rutas relativas : comenzando con la compilación interna de hoy, escribiremos rutas al archivo del espacio de trabajo como una ruta relativa si la ubicación del archivo del espacio de trabajo es un padre del objetivo. En otras palabras, las rutas ahora siempre serán relativas a menos que tengamos que usar la notación " ../ " para expresar la ruta.

Dado que los espacios de trabajo sin título siempre se encuentran en el directorio de datos de VS Code, las rutas allí siempre serán absolutas. Pero una vez que guarde un espacio de trabajo sin título en una ubicación, reescribiremos las rutas si es posible.

Si tiene curiosidad sobre los cambios en los espacios de trabajo de múltiples raíces que se realizaron durante este sprint, consulte las notas de la versión actualizadas .

+1

+1

@bpasero En mi .code-workspace , o usando la ruta del archivo como ID en su lugar) no es adecuada.
Cambiar el nombre de un archivo .code-workspace , o cualquiera de sus carpetas principales, o moverlo, y perder el estado de la interfaz de usuario es, en mi opinión, totalmente poco intuitivo. Creo que las personas que no saben cómo funciona eso bajo el capó no tendrían ni idea de la razón por la que perdieron su estado de interfaz de usuario anterior y cómo recuperarlo.
¡Eso no debe estar vinculado a la ruta absoluta de los archivos en el sistema de archivos en absoluto!

Esto también se aplica a la forma en que el estado de la interfaz de usuario se relaciona con la ruta de la carpeta que se encuentra actualmente en la versión estable. Al principio estaba muy confundido, hasta que busqué en Google.

En mi opinión, en caso de que se trate de una sola carpeta, el estado de la interfaz de usuario debe guardarse dentro de la carpeta .vscode . Si estamos tratando con un espacio de trabajo de múltiples raíces, el estado de la interfaz de usuario debe guardarse como un archivo separado en la misma carpeta que el archivo .code-workspace usando las convenciones de nomenclatura apropiadas (o tal vez dentro de ese archivo, aunque se mezclan configuraciones y estado puede no ser una buena idea).

Si se implementa correctamente, esto permitiría a los usuarios tener acceso completo a los estados de la interfaz de usuario, adjuntar nuevos estados de la interfaz de usuario a un espacio de trabajo determinado (raíz múltiple o no), etc.
Me encantaría poder sincronizar el estado de la interfaz de usuario entre diferentes computadoras, por ejemplo, trabajar en la oficina, luego ir a casa, tomar una computadora portátil o lo que sea y continuar exactamente donde lo dejé.
Tener varios estados de interfaz de usuario adjuntos a un espacio de trabajo y cambiar fácilmente entre ellos (menú / combinación de teclas / comando / etc.) cuando se trabaja en diferentes funciones también sería increíble. Quizás diferentes archivos .code-uistate dentro de .vscode enumeran automáticamente, o muchos archivos .code-uistate prefijados de acuerdo con el .code-workspace , o enumerados en una matriz.

Estoy pensando en esto como una extensión de cómo funcionan los proyectos y los espacios de trabajo en Sublime Text. Misma funcionalidad, diseño diferente. En este caso, un espacio de trabajo de VS Code sería similar a un proyecto Sublime, y los diferentes estados de la interfaz de usuario de VS Code serían similares a los espacios de trabajo de Sublime.

Respecto a estos temas:

era extraño que pudieras editar la identificación en el archivo simplemente escribiendo otro valor

Si totalmente. Eliminar el ID de allí fue la elección correcta.

no estaba muy claro cómo tratar la identificación al compartir el archivo del espacio de trabajo con otros (¿debería cambiarse la identificación? ¿Debería ser un uuid?)

Bueno, si tenemos myproject.code-workspace y myproject.code-uistate entonces depende del usuario decidir si compartir su estado de IU o no. No más pensar en qué significa ese ID, cómo se genera, si necesita ser un UUID para evitar conflictos al compartir, etc.
¿Quiere compartir la configuración y la configuración de la carpeta? Envíe myproject.code-workspace , no se preocupe.
¿Quieres compartirlo todo? Envíe ambos archivos.

no fue posible copiar un archivo de espacio de trabajo y abrirlo en una ventana separada, primero tuvo que cambiar la identificación en el archivo copiado

Si desea comenzar con un estado de interfaz de usuario nuevo con la misma configuración de carpeta y configuraciones, simplemente duplique su archivo .code-workspace .

como consecuencia, la acción "Guardar espacio de trabajo como" tendría que preguntar al usuario si la copia debe tener una identificación diferente o no

Eso fue complicado ya que el usuario no sabía cuál era esa identificación. Quizás sería más sencillo tener dos opciones "Clonar espacio de trabajo con estado actual" y "Nuevo espacio de trabajo en blanco". Pero eso es UX y tendrías que hacer un análisis al respecto.

De acuerdo con Franc, mantenga todos los archivos de configuración del proyecto dentro de la configuración
carpeta en los proyectos, eche un vistazo a Eclipse IDE que tiene el derecho
Acercarse. Tiene el concepto de configuración de proyecto y espacio de trabajo con
proyecto que sobrescribe los valores predeterminados en el espacio de trabajo. Workspace es solo una carpeta con
carpetas que representan proyectos. Entonces tenga la carpeta .vscode en el espacio de trabajo
carpeta, y cada proyecto tiene su propia carpeta .vscode . Y por favor no
solo vota esto por mencionar Eclipse IDE.

El lunes, 18 de septiembre de 2017 a las 8:52 p.m., Franco Gallardo Grazio <
[email protected]> escribió:

@bpasero https://github.com/bpasero En mi humilde opinión, la forma en que se manejan los estados de la interfaz de usuario
(si está usando una cadena de identificación en el archivo .code-workspace, o usando
la ruta del archivo como ID en su lugar) no es adecuada.
Cambiar el nombre de un archivo .code-workspace, o cualquiera de sus carpetas principales, o mover
alrededor, y perder el estado de la interfaz de usuario es, en mi opinión, totalmente intuitivo. yo
creo que la gente que no sabe cómo funciona eso bajo el capó tendría absolutamente
no tengo ni idea de la razón por la que perdieron su estado de interfaz de usuario anterior y cómo obtener
volver.
Eso no debe estar vinculado a la ruta absoluta de los archivos en el archivo.
sistema en absoluto!

Esto se aplica a la forma en que el estado de la interfaz de usuario se relaciona con la ruta de la carpeta actualmente en el
versión estable también. Estaba muy confundido sobre eso al principio, hasta que
busqué en Google.

En mi opinión, en caso de que se trate de una sola carpeta, se debe guardar el estado de la interfaz de usuario
dentro de la carpeta .vscode. Si se trata de un espacio de trabajo de varias raíces,
El estado de la interfaz de usuario debe guardarse como un archivo separado en la misma carpeta que el
archivo .code-workspace utilizando convenciones de nomenclatura adecuadas (o tal vez
dentro de ese archivo, aunque mezclar la configuración y el estado podría no ser una
buena idea).

Si se implementa correctamente, esto permitiría a los usuarios tener acceso completo
a los estados de la interfaz de usuario, adjunte nuevos estados de la interfaz de usuario a un espacio de trabajo dado (multi-raíz o
no), etc.
Me encantaría poder sincronizar el estado de la interfaz de usuario entre diferentes computadoras, digamos
trabajar en la oficina, luego ir a casa, agarrar una computadora portátil o lo que sea y
continuando exactamente donde lo dejé.
Tener varios estados de interfaz de usuario adjuntos a un espacio de trabajo y cambiar fácilmente entre
ellos (menú / combinación de teclas / comando / etc) cuando se trabaja en diferentes funciones
sé genial también. Quizás diferentes archivos .code-uistate dentro de .vscode
enumerados automáticamente, o muchos archivos .code-uistate prefijados según
el espacio de trabajo principal .code, o listado en una matriz.

Estoy pensando en esto como una extensión de cómo los proyectos y los espacios de trabajo
trabajar en Sublime Text. Misma funcionalidad, diseño diferente. En este caso un
El espacio de trabajo de VS Code sería similar a un proyecto Sublime, y las diferentes
Los estados de la interfaz de usuario de VS Code serían similares a los de los espacios de trabajo de Sublime.

Respecto a estos temas:

era extraño que pudieras editar la identificación en el archivo simplemente escribiendo
otro valor

Si totalmente. Eliminar el ID de allí fue la elección correcta.

no estaba muy claro cómo tratar la identificación al compartir el archivo del espacio de trabajo
con otros (¿debería cambiarse la identificación? ¿Debería ser uuid?)

Bueno, si tenemos myproject.code-workspace y myproject.code-uistate
entonces depende del usuario decidir si compartir su estado de interfaz de usuario o no.
No más pensar en lo que significa esa identificación, cómo se genera, si es necesario
un UUID para evitar conflictos al compartir, etc.
¿Quiere compartir la configuración y la configuración de la carpeta? Enviar myproject.code-workspace,
no hay necesidad de preocuparse.
¿Quieres compartirlo todo? Envíe ambos archivos.

no fue posible copiar un archivo de espacio de trabajo y abrirlo en una
ventana, tenía que cambiar la identificación primero en el archivo copiado

Si desea comenzar con un nuevo estado de interfaz de usuario con la misma configuración de carpeta y
la configuración simplemente duplica su archivo .code-workspace.

como consecuencia, la acción "Guardar espacio de trabajo como" tendría que preguntar al
usuario si la copia debe tener una identificación diferente o no

Eso fue complicado ya que el usuario no sabía cuál era esa identificación. Quizás lo hubiera
Ser más sencillo tener dos opciones "Clonar el espacio de trabajo con
State "y" New Blank Workspace ". Pero eso es UX y tendrías que hacer un
análisis sobre eso.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
.

-
Daniel Sokolowski
Arquitecto Técnico

Stantive Technologies Group Inc.
Teléfono: +1 (613) 634-7410
http://www.stantive.com

Aviso de confidencialidad:
La información transmitida está destinada únicamente a la persona o entidad a
a la que se dirige y puede contener información confidencial y / o privilegiada
material. Cualquier diseminación de retransmisión de revisión u otro uso de o
tomar cualquier acción en base a esta información por personas o
se prohíben entidades distintas del destinatario previsto. Si recibiste
esto es un error por favor contacte al remitente inmediatamente por devolución electrónica
transmisión y luego elimine inmediatamente esta transmisión, incluidas todas
adjuntos sin copiar distribuir o divulgar los mismos.

@danielsokolowski Entiendo la noción de un proyecto que sobrescribe un espacio de trabajo para la configuración. En vscode tiene configuraciones generales, configuraciones de usuario (sobre escritura general) y configuraciones de espacio de trabajo (sobre escritura de usuario o general). Cada proyecto ya tiene la oportunidad de tener su propia carpeta .vscode (la configuración del espacio de trabajo reside en ella). ¿Está sugiriendo una carpeta adicional que anidaría proyectos solo para compartir información de configuración? Eso parecería similar a un archivo / carpeta de " solución " en términos de Visual Studio.

@fgallardograzio Tener una configuración de proyecto entremezclada con configuraciones en el mismo archivo forzará el acoplamiento. Las cosas de la interfaz de usuario suenan mucho mejor como otra característica separada de este ticket de emisión. Ahora que la compilación de Insiders tiene un buen diseño de las raíces adicionales en el archivo, tal vez una extensión pueda llenar el espacio para la parte de la interfaz de usuario. Gracias. Buen día.

@Yemi , sí, entonces Elcipse me permite abrir diferentes espacios de trabajo que son
simplemente carpetas que contienen varias subcarpetas para representar proyectos. yo
utilizar personalmente dos espacios de trabajo, uno para desarrollar Eclipse IDE y otro para
todos mis proyectos relacionados con el trabajo. La principal conclusión es que la configuración es solo
archivos legibles por humanos almacenados en sus respectivas carpetas de configuración - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
esto es muy lógico para mí.

Un comentario / consejo que vale la pena mencionar para cualquier IDE, en situaciones en las que tenga
proyectos independientes, diga workspace/your-awesome-library que desea
incluir como parte de otro proyecto decir
workspace/my-wiget/libraries/your-awesome-library uno puede usar uniones
o hardlinking dependiendo del sistema operativo: encuentro este más limpio que git / hg subrepos
conceptos.

El martes 19 de septiembre de 2017 a las 10:33 a.m., Yemi Bedu @ P&R [email protected]
escribió:

@danielsokolowski https://github.com/danielsokolowski Entiendo el
noción de un proyecto que sobrescribe un espacio de trabajo para la configuración. En vscode usted
tener configuraciones generales, configuraciones de usuario (sobre escritura general) y espacio de trabajo
configuración (sobre escritura de usuario o general). Cada proyecto ya tiene el
oportunidad de tener su propia carpeta .vscode (la configuración del espacio de trabajo reside en ella).
¿Está sugiriendo una carpeta adicional que anidaría proyectos solo para
compartir información de configuración? Eso parecería similar a una " solución "
archivo / carpeta en términos de Visual Studio.

@fgallardograzio https://github.com/fgallardograzio Tener un proyecto
La configuración entremezclada con los ajustes en el mismo archivo forzará
acoplamiento. La interfaz de usuario suena mucho mejor como otra característica separada de
este boleto de emisión. Ahora que la compilación Insiders tiene un buen diseño del
raíces adicionales en el archivo, tal vez una extensión pueda llenar el espacio para la interfaz de usuario
parte. Gracias. Buen día.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
.

-
Daniel Sokolowski
Arquitecto Técnico

Stantive Technologies Group Inc.
Teléfono: +1 (613) 634-7410
http://www.stantive.com

Aviso de confidencialidad:
La información transmitida está destinada únicamente a la persona o entidad a
a la que se dirige y puede contener información confidencial y / o privilegiada
material. Cualquier diseminación de retransmisión de revisión u otro uso de o
tomar cualquier acción en base a esta información por personas o
se prohíben entidades distintas del destinatario previsto. Si recibiste
esto es un error por favor contacte al remitente inmediatamente por devolución electrónica
transmisión y luego elimine inmediatamente esta transmisión, incluidas todas
adjuntos sin copiar distribuir o divulgar los mismos.

¿Esta función aún no se agregó?

Esto es muy importante para mi. Estoy trabajando en un proyecto que se compone de 2 repositorios separados: el frontend web y la API. Sería bueno si pudiera abrir ambas carpetas en un solo "proyecto".

Claro, podría resolver esto clonando los 2 repositorios en una sola carpeta y abriendo esa carpeta, pero esto no funciona para todos los casos. Especialmente si tiene varios proyectos que dependen de un solo repositorio (es decir, comparten la misma API).

Esta característica también sería útil para aquellos que usan código como documentación.

@JamesTheHacker por un tiempo usa vscode-insiders que admiten múltiples proyectos al mismo tiempo. Y puede sugerir funciones según lo que sienta con la versión privilegiada para mejorarla

Cuando se envíe, la versión de VSCode probablemente debería pasar a 2.0. Solo digo :)

Pregunta rápida sobre esta función:

Esta función permite agregar varias carpetas con repositorios a un espacio de trabajo existente. ¿También admitiría una configuración de mono-repositorio, por lo que quiero abrir varios proyectos en un mono-repositorio, pero como están en un repositorio, no tienen un repositorio de git propio. Entonces, desde el punto de vista del proyecto, no tienen una carpeta .git , una de las carpetas ancestrales las tiene.

Podría preguntarse por qué no abrir la carpeta mono-repo como una carpeta grande y simplemente trabajar allí. Hay dos respuestas:

1. (menos interesante para mí) hay demasiados proyectos en el mono-repositorio, y solo me interesan algunos de ellos.
2. Muchos complementos asumen que un proyecto contiene solo un ... proyecto. Por ejemplo, solo un paquete npm. Entonces buscan cosas en la _ raíz_ del proyecto. Ejemplos: el complemento npm para VSCode, el complemento mocha para vscode y muchas funciones en el propio VSCode; por ejemplo, no puedo especificar una ruta en el launch.json que sea relativa al archivo actual, es decir, "la carpeta node_modules que es el antepasado más cercano del archivo actual".

Después de esta explicación contextual, mi pregunta es simple: ¿esta función respaldaría proyectos cuya carpeta .git es un antepasado de su raíz? Si es así, entonces sería posible utilizar esta función en un repositorio único.

@borekb Sí. No sé cómo la gente de Microsoft administra sus versiones, pero creo que es una característica lo suficientemente masiva para una importante

Después de esta explicación contextual, mi pregunta es simple: ¿esta función respaldaría proyectos cuya carpeta .git es un antepasado de su raíz? Si es así, entonces sería posible utilizar esta función en un repositorio único.

Esto ya es compatible desde hace bastante tiempo, si simplemente abre una subcarpeta de un repositorio de git.

+1

Sublime y Atom lo hacen. No hay mejor razón. Esta es la NUEVA MS, háganlo chicos, tengo completa fe en ustedes. :)

Hola,
@inestyne, si lee publicaciones anteriores como las de @Jeyanthinath , ya sabría usar VSCode Insiders para evaluar esta función. Incluso hay una hoja de

Simplemente lea el hilo y use Insiders OMG. Me voy a dar de baja ... los trolls que no leen son imposibles. Gracias @ pr-yemibedu

Sensible

Dado que este hilo tiene 2 años de duración, y la función parece estar en la compilación de Insiders ahora, ¿hay alguna manera de marcar este hilo para que sea más obvio que leer el hilo completo desde la parte superior?

Una cosa que falta es la capacidad de abrir una nueva ventana con un nuevo espacio de trabajo desde la CLI.

@jearle Se debe code-insiders <folder> , ¿no?
code-insiders -a <folder> es necesario para agregar la carpeta a la ventana actual.

@Jeyanthinath gracias! ¡ He estado haciendo lo mismo que

@Tyriar para obtener la funcionalidad que quería, tengo que ejecutar los siguientes comandos:

code .; code -a .

code . abre la carpeta como un espacio que no es de trabajo, y luego code -a . adjunta a la ventana previamente abierta como un espacio de trabajo que me permite abrir la misma carpeta más de una vez.

Personalmente, creo que esto también debe cambiarse. Estoy trabajando con ionic y un servidor personalizado en dos repositorios git diferentes y no es muy fácil. La capacidad de tener al menos dos "pestañas de proyecto" abiertas o algo sería genial.

Cambié de Atom por los errores y la lentitud que tenía.

@ dark-swordsman puedes habilitar nativeTabs en mac

@felixfbecker ¿ es esto posible en Windows?

Editar: Busqué completamente en el archivo de configuración y no hay ninguna opción para eso. Por eso estoy preguntando.

Edit2: Además, no hay un recurso claro sobre cómo habilitar vs insiders

Hola,
@ dark-swordsman no habilitas VS Insiders. Es una compilación de VSCode que tiene algunas características adicionales que no han finalizado para ser estables y de alguna manera le brinda un espacio de nombres de editor adicional para trabajar (puede instalarlos uno al lado del otro sin conflictos de configuraciones o extensiones). Gracias. Buen día.

El soporte para espacios de trabajo de múltiples raíces ahora está habilitado de forma predeterminada en la versión estable.

Consulte nuestra documentación para obtener una explicación completa de todas las funciones que lo acompañan. Los autores de extensiones deben consultar nuestra wiki que explica las nuevas API de extensión para que su extensión esté lista para espacios de trabajo de múltiples raíces. Estamos contentos de que algunas extensiones ya hayan comenzado a adoptar la nueva API multi-root, ¡gracias por eso!

No dude en presentar problemas para múltiples raíces a medida que los encuentre, todavía estamos planeando hacer ajustes y proporcionar API adicionales para que las extensiones funcionen con espacios de trabajo de múltiples raíces en el futuro.

Esto es genial, pero ¿cuándo estará disponible? Dices que está en la versión estable, pero tengo la última versión estable (1.17.2) y no puedo actualizarla. Además, en la documentación a la que acaba de hacer referencia, dice que todavía está en la compilación de Insider y pronto estará en la versión estable.

Entiendo que puede pasar un tiempo antes de que se publique la próxima compilación, pero vi esta notificación esperando que esté disponible.

Editar: Pido disculpas por mi impaciencia. Solo estaba tratando de abrir una nueva ventana de forma manual (vuelva a llamar al .exe) y no funcionaba, pero no miré en Archivo> Abrir ventana nueva. Esto funcionará por ahora. Esperamos el lanzamiento de la próxima compilación. 👍

@bpasero Por favor, cierre este problema abierto # 35849 ya que la funcionalidad esperada ha sido parte de esta característica # 396.

Solo una pregunta rápida. ¿Es posible, cuando he abierto más carpetas, cambiar qué carpeta quiero compilar? De momento siempre es el primero en versión estable.

EDITAR: Esto podría ser para el creador de la extensión PlatformIO, pero estoy preguntando por ambos lados. Por si acaso...

@DJManas parece que esto depende de la extensión que estés usando para decidir, por lo que debes preguntarle al autor de la extensión.

@bpasero Ok, lo hice en paralelo, gracias por responder.