Vscode: Anidamiento de archivos

fyi @bpasero

El escenario más ideal para esto es que cualquier cosa que comience con el mismo texto que un archivo principal, menos la extensión, se anida, así;

File1.cs
--- File1.File2.cs
--- File1.File3.cs
------ File1.File3.File4.cs

No hay planes por el momento. Cerrando hasta que reconsideremos esto.

Esta es una característica importante para proyectos grandes. Estoy usando asp.net vNext para el proyecto Angular y ahora sigo la estructura automáticamente (nombrando):

--app.component.ts
----app.component.ts.sass
----app.component.ts.html
--login.component.ts
----login.component.ts.sass
----login.component.ts.html

En VS Code Explorer obtuve:

--app.component.ts
--app.component.ts.sass
--app.component.ts.html
--login.component.ts
--login.component.ts.sass
--login.component.ts.html

Crear carpetas para cada componente es una mala solución para un proyecto angular (deberá cambiar las referencias).

Necesitamos esta función para pasar a VS Code.

De acuerdo, al menos ts + js + archivos de mapas (por ejemplo, como lo hace webstorm)

Sería genial tener anidado de archivos para ts + js + map + style.

Actualmente estamos ocultando los archivos .js y .map, lo que hace que verificarlos sea una molestia. Incluso con solo ts + css, la barra lateral todavía se siente hinchada.

De acuerdo Deseo anidar archivos como este (especialmente para ng2)

HTML
--css
--ts
- etc ...

¡Por favor reconsidere esto! Este es un tema tan importante.

Hay tantos casos en los que los archivos generados simplemente saturan el espacio de trabajo. ¡Mecanografiado! ¡Mecanografiado que también usas! es un buen ejemplo. O LESS / SASS -> css. O Jade -> Html

Existe la opción de ocultar condicionalmente los archivos generados. Por ejemplo:

"files.exclude": {
    "**/*.js": {"when": "$(basename).ts"}
}

Este mismo principio podría aplicarse a sus archivos CSS y Map.

Y estoy usando esa opción. El problema surge cuando quiero ver el
archivos ocultos. Además, no está claro si los archivos ocultos son realmente
ahí (que la generación está trabajando ...), lo que me hace abrir la carpeta
en el explorador donde los archivos tampoco están agrupados ... otra cosa es que
algunos de mis colegas no se sienten cómodos con no ver la mitad de los archivos en
el proyecto y nos gustaría utilizar la misma configuración para todo el equipo.

Por alguna razón, la mayoría de los otros editores consideraron que esta función era lo suficientemente útil como para
implementarlo así que ¿por qué no vs código?

Me gustaría señalar que esta no es una característica complicada. Estoy
bastante seguro de que se puede hacer en un día. (Estaba pensando en hacer un tirón
solicitud, pero puede requerir algunos pequeños cambios en la arquitectura alrededor
FileStat)

El domingo 25 de septiembre de 2016, Andrew Sheehan [email protected]
escribió:

Existe la opción de ocultar condicionalmente los archivos generados. Por ejemplo:

"archivos.excluir": {
"* _ / _. js": {"cuando": "$ (nombre base) .ts"}
}

Este mismo principio podría aplicarse a sus archivos CSS y Map.

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

+1

alguna extensión que pueda hacer el trabajo?

¿Por qué está esto cerrado? No está implementado y sería una gran característica.

@uxsoft

Por alguna razón, la mayoría de los otros editores consideraron que esta función era lo suficientemente útil como para
implementarlo así que ¿por qué no vs código?

Tal vez porque necesitan una razón para que la gente use el estudio visual real :-)

Esto no debería haberse cerrado, reabriendo. Aunque puede haber duplicados mientras tanto.

@stevencl @chrisdias @seanmcbreen @egamma fyi necesitamos algo de dirección y guía de PM aquí si queremos convertir el explorador de archivos en una vista lógica. Un PR inicial fue creado por @playerx en https://github.com/Microsoft/vscode/pull/13754

Mis 2 centavos por el momento: deberíamos pensar en una solución para los escenarios que nuestros usuarios quieren resolver y mi sensación es que solo apoyar para mostrar archivos similares en el mismo nivel debajo de un archivo raíz no es suficiente. La gente puede querer algo poderoso como el explorador de soluciones en VS.

@bpasero , mis disculpas, pero la pregunta que hiciste no es correcta. hay dos tipos diferentes de funciones:

N1. Convierta el explorador de archivos en una vista lógica
Ejemplo: puede vincular el archivoA ("directorioX / archivoA") al archivoB, que se coloca en el directorioY

N2. Brinde soporte al explorador de archivos para mostrar archivos reales de una manera más elegante y brinde a los desarrolladores la capacidad de habilitar esta función, por ejemplo:

La característica N1 y la característica N2 no son lo mismo, es una parte muy importante aquí, no se cubren entre sí.

Gracias

@playerx Mencioné el explorador de soluciones porque en la descripción de este problema se hace una referencia a Visual Studio 2015 y, que yo sepa, solo existe el explorador de soluciones.

Independientemente de VS, nuestro propio proyecto está poniendo todos los archivos MAP y JS generados en una carpeta out , no al mismo nivel que los archivos TS y estoy seguro de que hay otros proyectos que hacen lo mismo. Mi punto es que esperaría anidar esos archivos debajo de los archivos TS de la misma manera que lo hace cuando están en el mismo nivel.

Para mí, el anidamiento no se trata de agrupar archivos con la misma extensión, se trata de mostrar archivos juntos que lógicamente pertenecen juntos (también conocidos como "recursos derivados"). ¿Tiene sentido?

@playerx N2 se ve mucho mejor. Para los usuarios de angular 2 cli, esto no debería requerir esa convención de nomenclatura. Tal vez podría haber algún patrón configurable como en la configuración de ocultar archivos.

Angular2 cli crea archivos como este:

my.component.ts
my.component.html
my.component.scss / css / less

@mbeckenbach buen ejemplo, gracias

@bpasero anidando archivos generados, en archivos TS es un gran ejemplo, gracias

Quiero pedirles a todos que pongan aquí todos los ejemplos prácticos posibles (no teóricos, por favor), que usaríamos en la vida cotidiana y hagamos una solución basada en esos ejemplos.

Sea la pregunta:
¿Cómo hacer que Explorer sea "más inteligente" para visualizar una imagen real de la estructura de los archivos, de una manera más elegante?

@bpasero okey? Sigo intentando no mezclar Feature N1 y Feature N2.

Escenario 1:
antes de:

my.component.ts
my.component.html
my.component.scss
my.component.spec.ts

después (opción 1):

my.component.ts
- my.component.html
- my.component.scss
- my.component.spec.ts

después (opción 2):

my.component.ts
- my.component.html
- my.component.scss
my.component.spec.ts

después (opción 3):

my.component.html
- my.component.ts
- my.component.scss
my.component.spec.ts

Escenario 2:
antes de:

webpack.config.js
webpack.config.commin.js
webpack.config.dev.js
webpack.config.prod.js

después:

webpack.config.js
- webpack.config.commin.js
- webpack.config.dev.js
- webpack.config.prod.js

@playerx Una adición: también genera este archivo: my.component.spec.ts

Había ocultado los archivos de especificaciones porque no realizo pruebas unitarias en proyectos de demostración. :-)

gracias, Escenario 1 actualizado, seleccione la opción posterior que elegiría usar

Escenario 1 La opción 1 encajaría mejor en mi opinión.

1. Un componente angular 2 puede existir sin el archivo html (plantillas en línea)
2. Permitiría nombres de archivos adicionales como, por ejemplo, my.component.animations.ts si el equipo angular decide extraer más partes en varios archivos algún día

Escenario 1, Opción 1 ftw! +1 debido a las convenciones de nomenclatura angular2

@seveves Definitivamente quiero tener esta función, pero debo decir que las convenciones de nomenclatura de Angular 2 son simplemente terribles. El soporte de esta función no debe basarse en una guía de estilo arbitraria específica del marco que dicta convenciones de nomenclatura basadas en la necesidad de ergonomía del desarrollador en las herramientas de construcción del módulo ES previas que ya no son relevantes para el marco que incluso las usa. Nuevamente, quiero ver soporte para esta función, pero creo que esa es la razón incorrecta.

@aluanhaddad - para no salirse demasiado del tema aquí, pero ¿tiene un ejemplo de cuál sería una mejor convención de nomenclatura para los 4 archivos especificados en los escenarios?

Todos los archivos tienen el mismo nombre fuera de la extensión (+ archivo .spec), que obviamente no es específico de angular2. La pregunta que se plantea es cuál es el orden de prioridad de las extensiones con archivos con nombres similares: cuál se consideraría el principal para agrupar.

Creo que con este escenario (tipos del lado del cliente), la prioridad sería: TS, JS, HTML, [tipos de estilo]. Siempre tendrá un archivo TS o JS, pero no necesariamente una plantilla o estilo

¡¡Esto sería realmente genial !!

@playerx comentó el 15 de octubre de 2016 • editado

Por la sugerencia:

N1. Convierta el explorador de archivos en una vista lógica
Ejemplo: puede vincular el archivoA ("directorioX / archivoA") al archivoB, que se coloca en el directorio

Estoy bastante seguro de que está disponible en cualquier sistema operativo actual; Windows ha admitido "Junctions" para algunas versiones ahora, e incluso tiene un comando MKLINK ahora.

Dado eso, no veo una necesidad real para la opción N1, y recomendaría el comentario de ciel (comentado el 13 de mayo de 2016) de anidación basada en la extensión.

¿Qué tal usar un conjunto de reglas configurables más o menos como:

"*.component.ts": [  
   "$(basename).component.html",  
   "$(basename).component.spec.ts",  
   "$(basename).component.js",  
   "$(basename).component.js.map",  
   "$(basename).component.spec.js",  
   "$(basename).component.spec.js.map"
]

Otra opción es usar patrones RegEx en su lugar.

Esto anidaría los archivos que coincidan con los patrones en el orden especificado por los patrones. Esto abre un amplio conjunto de opciones de configuración, no se limita a la convención Angular 2 (ni siquiera se limita a ts / js / html) y proporciona previsibilidad y consistencia.

Creo que la introducción de vistas de soluciones como en Visual Studio agrega una complejidad innecesaria a VSCode y hace que pierda su experiencia de edición liviana.

@aluanhaddad - para no salirse demasiado del tema aquí, pero ¿tiene un ejemplo de cuál sería una mejor convención de nomenclatura para los 4 archivos especificados en los escenarios?

De verdad, no cambiaría mucho desde un punto de vista lógico.

my.component.html
- my.component.ts
- my.component.scss
my.component.spec.ts

se convertiría

my.html
- my.ts
- my.scss
my.spec.ts

😆
porque es muy obvio que es un componente ...

Me opuse a las convenciones de nomenclatura de Angular 2 de John Papa. Me opongo a que nombre componentes, tuberías, servicios, módulos y el resto de las tonterías redundantes. Se le ocurrieron esas convenciones para Angular 1 cuando estaba usando configuraciones de Grunt para agrupar manualmente módulos, controladores, servicios y directivas envueltos en IIFE (todo esto era una idea decente en ese momento). Lo suficiente fue habilitar la agrupación y otras tareas de Grunt para cargar primero todos los archivos .module para que los scripts que registraban controladores, servicios, etc. no explotaran al cargarse.

Dicho esto, su guía de estilo de Angular 1 era casi perfecta en todos los demás aspectos, y estos escenarios eran relevantes en ese momento, pero su guía de estilo de Angular 2 (la oficial) es terrible. Por otra parte, ¿quién podría escribir una elegante guía de estilo para algo tan feo por naturaleza?

Creo que File Nesting es imprescindible en el desarrollo moderno, especialmente en el desarrollo web ...

Por favor, por favor ... considere apoyarlo.

Parece que lo que realmente queremos aquí es un sistema de vista lógica configurado a medida junto al explorador físico.

Imaginemos que tenemos un proyecto con estructura (se complica intencionalmente):

- app
    - logic
        - helpers
            - {helper}.ts
            - {helper}.spec.ts
        - component-logic
            - {component-name}.ts
            - {component-name}.spec.ts
        - viewmodels
            - {viewmodel-name}.ts
            - {viewmodel-name}.spec.ts
    - views
        - {viewmodel-name}.html 
        - {shared-view-name}.html
    - styles
        - {some-common-style-file}.scss
        - {viewmodel-name}.scss
        - {shared-view-name}.html

Necesitamos un explorador de lógica que nos permita definir cómo agrupar el archivo y cómo mostrarlo. Los grupos pueden estar anidados, por lo que terminamos teniendo una vista que no está relacionada con la estructura de la carpeta. Imaginemos una configuración de vista tan lógica:

{
    "name": "Components",
      "root": "Defines groups to be displayed on the top of the tree",
    "root": ["viewmodelsDirectory", "helpersDirectory"],
    "groups": [{
        "name": "viewmodelsDirectory",
        "displayAs": "viewmodels",
        "groups": ["viewmodel"]
    }, {
        "name": "helpersDirectory",
        "displayAs": "viewmodels",
        "groups": ["helper"]
    }, {
        "name": "viewmodel",
          "headGroup": "Which file is on the top of the group. If omitted then this group displays as directory",
        "headGroup": "viewmodel",
        "pattern": "app\/viewmodel\/(*+)\.html",

          "files": "For each path that match pattern we build a file group",
        "files": [{
            "name": "viewmodel",
              "displayAs": "Pattern explaining how to display this entry. Might accept placeholders like {fileName}, {filesGroupName}, {fileNameWithExtension}, {Extension}",
            "displayAs": "{fileName}",
            "pattern": "app\/viewmodels\/\1\.ts",
            "optional": false
        }, {
            "name": "logic",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/logic\/component-logic\/\1-logic\.ts",
            "optional": false
        }, {
            "name": "view",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/views\/\1\.html",
            "optional": false
        }, {
            "name": "style",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/styles\/\1\.csss",
            "optional": true
        }]
    }, {
        "name": "helper",
        "headGroup": "helper",
        "pattern": "app\/logic\/helpers\/(*+)\.ts",
        "files": [{
            "name": "helper",
            "displayAs": "{fileName}",
            "pattern": "app\/viewmodels\/\1\.ts",
            "optional": false
        }]
    }]
}

Dentro de esta vista, nuestros archivos deben mostrarse como:

- viewmodels
    - {viewmodel-name}
        - view
        - style
        - logic
- helpers
    - {helper}

Tenga en cuenta que en el ejemplo actual, los archivos de especificaciones están completamente ocultos. Está hecho para que el usuario se centre en el código. En tal caso, el usuario tendría una vista lógica separada que le presentaría las pruebas unitarias de la forma que desee. Debe ser configurable a nivel de espacio de trabajo, usuario y extensión. El usuario debe poder cambiar rápidamente entre vistas tanto desde la interfaz como desde los atajos de teclado.

Esto es solo un borrador, pero espero que presente la idea con claridad.

Todavía tengo la esperanza de que esto funcione. Es muy importante para la organización.

Esto también se aplica cada vez más a Aurelia. Estructura muy similar a Angular 2+. Agregar anidación de archivos (configurable) reduciría una carpeta src completamente expandida con niños colapsados ​​en uno de nuestros proyectos promedio en aproximadamente 2/3 de longitud.

@ RichiCoder1 sí y, afortunadamente, Aurelia usa convenciones de nomenclatura lógicas y no redundantes :)
¿Ha comprobado la extensión aurelia vscode y su comando Abrir archivo relacionado ? No está realmente relacionado con la anidación, pero es muy útil.

También me encantaría cambiar el nombre de un grupo en una sola operación de cambio de nombre.

Esto se está volviendo muy importante a medida que comienza a trabajar en una gran aplicación angular, considere esto para incorporar vscode, en lugar de que ya lo tenga, si no, traiga una experiencia similar para el anidamiento de archivos que tenemos en vs

Hombre, esto realmente haría que la aplicación Angular en la que estoy trabajando sea mucho menos desordenada y obtusa. Espero sinceramente que estén considerando seriamente esto.

Como dije en otro número ...

La razón principal por la que quiero esto es por angular, donde tengo muchos archivos con nombres similares juntos;

/app
.../home.ts
.../home.component.ts
.../home.template.html
.../home.styles.scss
.../home.component.spec.ts
.../nav.ts
.../nav.component.ts
.../nav.component.spec.ts
.../nav.template.html
.../nav.styles.scss

Si pudiera anidarlos, sería genial.

También hago el patrón Comando / Mediador, por lo que termino con archivos que se parecen a ...

/src/
.../Identity/
....../CreateUserRequest.cs
....../CreateUserRequest.Handler.cs
....../ConfirmUserExistsRequest.cs
....../ConfirmUserExistsRequest.Handler.cs
....../ConfirmUserValidationRequest.cs
....../ConfirmUserValidationRequest.Handler.cs

Se vuelve bastante detallado y esta característica simplemente me alegraría el día.

Esta es la única razón por la que sigo usando WebStorm ...

Sí, nosotros también.

El 2 de junio de 2017, a las 10:10 a. M., MigFerreira [email protected] escribió:

Esta es la única razón por la que sigo usando WebStorm ...

-
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.

Pregunta tonta: ¿Alguien puede proporcionar una captura de pantalla de cómo se ve? No puedo imaginar cuál es el sentido detrás de eso.

Ah, está bien, gracias.

Esta se ha convertido ahora en la característica que más nos falta. Tengo compañeros de trabajo que no lo usarán porque no tiene esta función. Es un verdadero dolor de cabeza intentar encontrar un archivo en particular cuando muchos tienen nombres similares. Intentamos agregar más subcarpetas para cada componente (Angular), pero esa no es una solución ideal y volvimos a enumerar todos los componentes en las carpetas de características (y subfunciones).

Estoy presentando TypeScript y Angular a un gran proyecto de Dojo, y puedo decir que esta característica será muy importante para los usuarios de VSCode en nuestro equipo en los próximos meses.

Actualmente estoy trabajando en un proyecto Angular y poder agrupar archivos relacionados sería una excelente adición a un producto que ya es excelente. A medida que crece el proyecto Angular, más difícil se vuelve la navegación y actualmente obstaculiza la productividad.

Repetido de # 13754:

En mi opinión, la solución más elegante sería dejarlo en manos del proyecto. Como en .vscode/settings.json o tal vez project.json . Utilice algo como la sintaxis de exclusión de archivos. Esto permitiría la personalización por proyecto o por carpeta. Los mantenedores de marcos / herramientas, VSCode o un tercero podrían distribuir conjuntos de patrones para determinados flujos de trabajo.

De esta manera, VSCode no asume nada y no causa problemas a nadie. Podría detectar posibles candidatos para el anidamiento y mostrar una alerta que pregunte: "Parece que tiene archivos que deberían anidarse. ¿Desea aplicar uno de estos perfiles de anidamiento predeterminados?"

Si los desarrolladores quieren un anidamiento lógico, entonces pueden tenerlo. Si no lo quieren, simplemente no agregan la configuración.

Para capturar my-component.A.B debajo de my-component.ts (AngularJS 2):

"files.nest": {
    "**/*.*.*": {"when": "$(basename).ts"}
}

Para capturar my-component.dev.ts debajo de my-component.ts :

"files.nest": {
    "**/*.*.ts": {"when": "$(basename).ts"}
}

O para archivos generados (usando el esqueleto de navegación de Aurelia donde los archivos se generan en dist/ ):

// TypeScript => ES5
"files.nest": {
    "dist/src/**/*.js": {"when": "src/$(dir)/$(basename).ts"}
}

// ESNext => ES5
"files.nest": {
    "dist/src/**/*.js": {"when": "src/$(dir)/$(basename).js"}
}

// Less => CSS
"files.nest": {
    "dist/src/**/*.css": {"when": "src/$(dir)/$(basename).less"}
}

// Mappings
"files.nest": {
    "dist/src/**/*.map": {"when": "src/$(dir)/$(basename)"}
}

Con una sintaxis bien definida como esta, podría agregar cualquier esquema de anidamiento que quisiera, siempre que no sea excesivamente complicado. El último ejemplo se basa en el manejo de rutas de gulp ( $(path) = la ruta que comienza con el primer glob).

Me encantaría recibir información o comentarios sobre si esto se está considerando o no. Tal como está ahora, no usaré VS Code para ningún desarrollador de Angular o Aurelia hasta que sea una función incluida.

@threedaysmore No hay indicios de que el equipo de VSCode realmente lo esté considerando (ya que ha caído al final de la lista de trabajos pendientes). El PR # 13754 lo aborda, pero parece que @playerx lo ha eliminado, al menos temporalmente.

Creé un PR más actualizado: # 32061. Estoy buscando ayuda ya que mi manejo de algunas cosas (a saber, el modelo de árbol) tiene errores.

+1

+1

+1

No estoy seguro de cómo demostrar que estoy interesado en esta función. El +1, no parece ser una muy buena manera, ya que enviará spam al hilo (y la gente lo rechaza). ¿Cuáles son las formas recomendadas de dar un +1 o "me encantaría esta función" a un problema de github, simplemente para mostrar mi interés?

Simplemente agregue el pulgar hacia arriba para el comentario del primer autor, para indicar / aumentar la importancia de esta característica

@bpasero cerró mi solicitud de extracción # 32061: "Gracias por el PR, pero no lo aceptamos para esta gran área". (Por supuesto, mi solicitud de extracción fue bastante embrionaria).

¿Puede un mantenedor o cualquier otra persona ampliar esto? ¿O proporcionar alguna orientación sobre cómo se podría implementar como una solicitud de extracción o extensión?

@ firelizzard18 Quería mucho esta función, pasé un tiempo trabajando en eso y obtuve los mismos comentarios. Creo que hay alguna razón por la que no quieren esta función, pero no nos lo dicen :)

@bpasero
Creo que esta función merece más orientación por su parte (de los colaboradores), sobre cómo se puede hacer y, como puede ver, hay personas que pueden dedicar su tiempo para que esto suceda.

Sería genial tener anidación de archivos en VS Code también.
Recientemente cambié de VS 2017 a VS Code para programación Angular / frontend para mi aplicación ASP.NET Core, debido a un mejor soporte / integración Angular. Funciona mucho mejor, pero me falta mucho el anidamiento de archivos. :-(

¡Agregue la función de anidación de archivos a VS Code o brinde a otros la posibilidad de desarrollar una extensión!

https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/
o
https://marketplace.visualstudio.com/items?itemName=MadsKristensen.FileNesting

@bpasero Tengo curiosidad por saber si podemos obtener actualizaciones sobre esto del equipo. Ha habido mucha actividad de varias personas en el transcurso de varios años; fue cerrado, reabierto y se han rechazado varias implementaciones con una dirección mínima. ¿Sigue siendo esta funcionalidad deseada?

Hay casos de uso sólidos para las comunidades de React y TypeScript, y el sentimiento de los desarrolladores ha sido consistentemente positivo (lo que también me gustaría afirmar personalmente). Gracias de nuevo

@develleoper Creo que dejaron muy claras sus expectativas. Quieren que sea completamente personalizable para ser aceptado. No tiene sentido permitir nada que no le dé un control total sobre el explorador de archivos. La parte complicada es que debe permitir la creación / movimiento de archivos, mientras que la estructura en su IDE puede ser completamente diferente a la física. También creo que esperan que permita cambiar entre múltiples vistas (por ejemplo: puede tener contexto de archivo y contexto de pruebas unitarias. Escriba pruebas en una y luego cambie a otra para satisfacerlas).

Estoy bastante seguro de que están al tanto de los casos de uso, pero si miras la hoja de ruta, es posible que veas que sus planes son mucho más ambiciosos y útiles que este, por eso (supongo) por eso decidieron dejar este para la comunidad. .

Supongo que eres más que bienvenido a intentarlo: una gran oportunidad profesional en Micro $ a menudo está esperando al valiente;)

"Micro $ oft" LUL: me sorprende que los preadolescentes con experiencia limitada sigan este hilo.

_De todos modos_,

@waynebloss En mi opinión , esta función no debe dejarse como una extensión potencial que requiere un nuevo panel. Ese enfoque no solo requeriría volver a implementar el árbol de archivos con todas sus características actuales, sino también actualizarlo con las características futuras que se agreguen. Sí, el código del árbol de archivos actual podría bifurcarse en una extensión, pero eso no disminuye la carga de mantenimiento de rastrear futuras actualizaciones de funcionalidad.

Como mínimo, el árbol de archivos en sí mismo podría otorgar suficientes puntos de extensibilidad para implementar esto. (Agregar eso y construir una extensión para utilizarlo para esta función probablemente sería menos trabajo inicial de todos modos).

@RoyTinker estuvo de acuerdo: estaba pensando que un nuevo panel sería solo una solución hasta que se admitiera oficialmente el anidamiento de archivos.

@Wayofthesin No estoy seguro de a qué estás tratando de llegar. No creo que nadie se esté cuestionando seriamente si la comunidad quiere esta función, ya que hemos dejado muy claro que la queremos. Y lo que es igualmente claro, si lees la historia, es que la comunidad ha intentado implementar esto y los desarrolladores han dicho "No". @playerx hizo una solicitud de extracción y le dijeron "No". Bifurqué su solicitud de extracción y me fusioné en la rama maestra más nueva en ese momento, hice algunos ajustes y lo envié. Y le dijeron "No".

Por lo tanto, debería ser bastante evidente que la comunidad quiere esto y los desarrolladores no tienen interés en aceptar una contribución de la comunidad para ello.

@develleoper y otros, creo que los comentarios sobre @playerx s 's @bpasero PR decirnos mucho acerca de donde el equipo VSCode quiere ir con esto: https://github.com/Microsoft/vscode/pull/13754

Por sus comentarios, entiendo que @bpasero :

• quiere un enfoque integral que se adapte a todos los grupos que desean una visión lógica de algún tipo
• piensa en el anidamiento de archivos como una vista lógica (a diferencia de una vista física del sistema de archivos)
• cree que una vista lógica debería estar separada de una vista física del sistema de archivos

En mi opinión, aunque el anidamiento de archivos _es_ un cambio de vista lógico, también lo es la ocultación de archivos, y eso actualmente se admite en el árbol de archivos y se puede configurar a través de la configuración. Me parece que el anidamiento de archivos es solo otra forma de ocultar archivos, excepto que proporciona una forma de revelar esos archivos.

Además, Atom ahora admite la anidación de archivos a través de su paquete de vista de árbol; consulte https://github.com/atom/tree-view/issues/572

@ firelizzard18 He visto su solicitud de extracción. Solo comenté mis pensamientos. # 32061.

@RoyTinker comentó bastante bien lo que esperan. Se podría hablar de la creación de relaciones públicas, pero por lo que puedo ver, ni siquiera se ha cumplido la primera expectativa de @bpasero :

Independientemente de VS, nuestro propio proyecto está poniendo todos los archivos MAP y JS generados en una carpeta de salida, no al mismo nivel que los archivos TS y estoy seguro de que hay otros proyectos que hacen lo mismo. Mi punto es que esperaría anidar esos archivos debajo de los archivos TS de la misma manera que lo hace cuando están en el mismo nivel.

Como extra, agregaría: No piense en el explorador virtual como en el explorador de archivos. Es posible que alguien desee anidar los objetos exportados en un archivo mecanografiado.

Supongo que por eso no aceptaron los RP. No están interesados ​​en parchear el código existente. Buscan una solución flexible que no solo sea configurable sino también extensible. Parece que ellos mismos no tienen ni idea, pero saben muy bien lo que no quieren.

El problema que veo es que intentamos adivinar por qué no aceptan las relaciones públicas y no hay una respuesta y una guía claras. Todos los comentarios que hicieron ustedes son sus interpretaciones de lo que @bpasero piensa al respecto.

Tantas conversaciones y aún el silencio de los colaboradores, creo que eso no es bueno para el producto en sí.

@Wayofthesin , @playerx dio en el clavo: ambos tenemos claro el hecho de que @bpasero quiere algo más de lo que estamos brindando, pero @bpasero no ha @bpasero cerró mi PR con un comentario extremadamente vago. En @playerx 's caso, @bpasero comentó: 'Estamos en el juego final Actualmente, solamente voy a ser capaz de volver a este próximo mes', y no ha hecho ningún comentario adicional en el último año y medio.

Mi PR era un trabajo en progreso. Quería orientación de los desarrolladores sobre cómo seguir adelante. En cambio, obtuve una respuesta críptica y mi relaciones públicas cerró.

Mi comentario , al que hizo referencia en su revisión de mi PR, sugerí un plan para abordar los problemas de @bpasero con la (falta de) generalidad del enfoque de

Es una broma. Quería levantar un poco el ánimo. Investigue esto. Es realmente difícil trabajar con este tipo de vista de proyecto. No es difícil pero ineficaz.

+1, de acuerdo, esta función también será muy útil para el desarrollo de la mini aplicación wechat

¿Es esto muy difícil de hacer? Aproximadamente 2 millones de miembros de la comunidad Java necesitan esta función lo antes posible. POR FAVOR....!!!

Parece que VS Code tiene algún soporte para anidar archivos virtuales en la vista de árbol. El registro de cambios para la versión 1.29 incluía este punto:

Esto parece indicar que se ha creado una base para la agrupación de archivos.

@MortenChristiansen mmm ... No parece la misma característica '

Como sugerencia, Visual Studio 2017 tiene una función para anidar archivos a través de un archivo de configuración .filenesting.json . Quizás se podría implementar algo similar en términos de un archivo de configuración para VSCode

• https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/

Como ejemplo:

{
  "help": "https://go.microsoft.com/fwlink/?linkid=866610",
  "root": true,

  "dependentFileProviders": {
    "add": {
      "addedExtension": {},
      "pathSegment": {
        "add": {
          ".*": [
            ".js",
            ".css",
            ".html",
            ".htm",
            ".less",
            ".scss",
            ".coffee",
            ".iced",
            ".config",
            ".cs",
            ".vb",
            ".json"
          ]
        }
      },
      "extensionToExtension": {
        "add": {
          ".js": [
            ".coffee",
            ".iced",
            ".ts",
            ".tsx",
            ".jsx",
            ".vue"
          ],
          ".css": [
            ".less",
            ".scss",
            ".sass",
            ".styl",
            ".vue"
          ],
          ".html": [
            ".md",
            ".mdown",
            ".markdown",
            ".mdwn"
          ],
          ".map": [
            ".js",
            ".css"
          ],
          ".svgz": [
            ".svg"
          ],
          ".designer.cs": [
            ".resx"
          ],
          ".cs.d.ts": [
            ".cs"
          ],
          ".ts": [
            ".vue"
          ],
          ".scss": [
            ".vue"
          ],
          ".sass": [
            ".vue"
          ]
        }
      },
      "fileToFile": {
        "add": {
          ".bowerrc": [
            "bower.json"
          ],
          ".npmrc": [
            "package.json"
          ],
          "npm-shrinkwrap.json": [
            "package.json"
          ],
          "yarn.lock": [
            "package.json"
          ],
          ".yarnclean": [
            "package.json"
          ],
          ".yarnignore": [
            "package.json"
          ],
          ".yarn-integrity": [
            "package.json"
          ],
          ".yarnrc": [
            "package.json"
          ]
        }
      },
      "fileSuffixToExtension": {
        "add": {
          "-vsdoc.js": [
            ".js"
          ]
        }
      },
      "allExtensions": {
        "add": {
          ".*": [
            ".tt"
          ]
        }
      }
    }
  }
}

golpe 🏗

También sería bueno para archivos generados automáticamente en dart.

Esto también sería útil para las extensiones de Salesforce. Nuestros proyectos tienen un archivo *.meta.xml asociado con cada archivo de código, por lo que efectivamente hace que nuestro árbol de archivos tenga el doble de longitud. Nos encantaría poner ese archivo de metadatos debajo del archivo de origen.

No creo que sea un problema recopilar los requisitos / necesidades de los usuarios sobre la función de anidación.
No creo que sea un problema implementarlo. ¿Quizás alguna donación ayude a implementarlo más rápido en los lanzamientos oficiales?

Mirando mis archivos
Mecanografiado, web y estilos apilados.
Anidar estaría bien.

Lo siento chicos. No parece que estén interesados ​​en esto en absoluto.

Hombre, me encantaría ver esto también.

Extraño: el comportamiento de esta función está muy bien definido y claramente es muy necesario.

+1 vamos chicos

Esto no está sucediendo, chicos, así que probablemente cerraré el tema.

@isidorn ha dejado en claro que no les interesa y que no están tratando de hacerlo. Lo cual es lamentable. Esto es todo lo que me impide usar VSC ahora. Una aplicación Angular es tan detallada y desordenada sin anidar archivos.

Supongo que todavía estoy atrapado con WebStorm por ahora.

Sugiero que para mantener abierto este problema, podríamos abordarlo en un futuro no tan cercano.

@isidorn , dado el “futuro no tan cercano”, ¿puede brindar orientación sobre cómo se debe implementar? Me gustaría intentarlo, pero no obtuve ningún comentario sobre mi MR.

2019, ¿algo nuevo chicos?

Como desarrollador de Java, esto es lo principal que me impide migrar completamente a vscode.

En mis proyectos java, los directorios vacíos para los espacios de nombres de paquetes java ocupan la mitad (o más) de los espacios disponibles en el explorador. Siempre tengo que desplazarme hacia arriba / hacia abajo en el explorador, lo que lleva mucho tiempo cuando tienes que hacerlo tantas veces para cada iteración de desarrollo. Muchos IDE para el desarrollo de Java contraen estos directorios vacíos en un solo nombre de paquete, lo que facilita a los desarrolladores ver la estructura completa del paquete.

¿Es esto algo factible de implementar en vscode pero no priorizado debido a otras tareas de mayor prioridad? ¿O simplemente no es posible implementarlo debido a limitaciones en la arquitectura subyacente de vscode?

¿Alguna extensión para realizar esto? ¡Es una característica muy necesaria!

Abierto hace más de 3 años ... no parece que vayan a hacerlo ... Instalando webstorm ahora ...

esto y al pegar algunas cosas muy básicas que cree que se abordarán, tal vez eso sea lo que obtiene con el software gratuito y el código abierto. No tan bueno ... Ya que no hay piel en el juego.

Sí, respuesta muy decepcionante (o falta de) de un excelente equipo de desarrollo.

Hice un anidamiento personalizado, pero mi solicitud de extracción no se fusionará. Como el equipo de código VS tiene otros planes y no quiere hacer cambios en esa parte del código. Para mí, esta función también es importante, así que hice una compilación personalizada de Vs Code (la tienda de extensiones funciona) .Puede intentarlo

Simplemente agregue esta configuración a su settings.json:

    "files.nesting.enabled": true,
    "files.nesting.rules": {
        "(?<basename>.*)\\.ts$": [
            "$(basename)\\.spec\\.ts$",
        ],
        "(?<basename>.*)\\.html$": [
            "$(basename)\\.css$",
            "$(basename)\\.scss$"
        ]
    },

Es necesario reiniciar el código Vs cuando se habilita el anidamiento.

@floatas ¡ Gracias por tu código! ¿Qué opinas sobre hacer una extensión?

@ e-belair Lamentablemente, no es posible crear una extensión. La API para esta función no está disponible.

¡La función de anidación de archivos sería tan dulce! Espero que esto suceda :)

@floatas ¿Dónde está el PR?

@tariqporter # 72160

@floatas (https://github.com/microsoft/vscode/issues/6328#issuecomment-524030094)

Como el equipo de código VS tiene otros planes y no quiere hacer cambios en esa parte del código.

Ese sería el # 41627, en el que se trabajará primero como parte de la reescritura de la vista de árbol, lo que probablemente debería hacer esto más fácil de implementar después.

Creo que VS Code es genial, pero esta es una característica tan básica que no puede faltar.

Esperando con ansias también

lo necesito

¿Solo tienes curiosidad por saber si hay alguna actualización sobre esto? ¡Sería genial tener que limpiar la vista del árbol!

Sigo usando VS para Mac solo por esta función con las aplicaciones Blazor. ¿Por qué tanta resistencia del equipo?

¿Existe algún problema para realizar un seguimiento de la implementación de las API de extensión necesarias para que esto sea posible a través de ellas?

4 años después y ¿no hay avances en este tema? oO ..
Esto es alucinante para ser honesto ...

No puedo pensar en ningún IDE que haya usado que no sea compatible con esto de una forma u otra, ni puedo pensar en ningún proyecto en ninguna plataforma en la que haya trabajado donde esto no sería útil ... oO .. Esto hasta un punto en el que simplemente asumí que esto era un hecho en cualquier IDE ... supongo que no ...

¿El equipo solo está tratando de empujar a la gente hacia la competencia? ...
Me hubiera encantado reemplazar WebStorm con VSCode, pero supongo que eso no está sucediendo. Y entonces no estamos ni cerca de reemplazar VS o IDEA: S ...

Oh bien...

@jeme ¿Te imaginas que acosar a los desarrolladores va a tener algún efecto? Sé que si fuera un mantenedor, ignoraría categóricamente cualquier comentario antagónico. Si realmente desea ser constructivo y no solo una plaga, intente "Esta característica es muy importante para mí y me impide adoptar esta herramienta".

@ firelizzard18, entonces se estaría perdiendo la oportunidad de proporcionar a una base de clientes algo que se necesita urgentemente. Aprender a escuchar a todos los clientes es realmente un gran rasgo, elevarse por encima del frey, por así decirlo. Si lee los comentarios aquí, hay muchas personas que se comportan de la manera que usted dice que debería hacer que escuchen. Sin embargo, no están escuchando y después de 4 años las frustraciones aumentarán, especialmente si alguien realmente quiere cambiar pero no puede ver la manera porque el proyecto es demasiado grande para no tener los archivos anidados juntos. Realmente creo que el código visual es un software gratuito y nadie se preocupa realmente por hacer de esto una prioridad. Y eso es lo que obtenemos los usuarios por exigir software libre. No hay piel en el juego para que puedan hacer nada. Pago por un IDE si eso significa que se implementarán cosas como esta. Nuevamente sigo usando webstorm (por lo que pagué). Realmente deberían salir y decir que no lo haremos, por lo tanto, cerrar el boleto y terminar con eso.

Si lee los comentarios aquí, hay muchas personas que se comportan de la manera que usted dice que debería hacer que escuchen.

¿Y crees que ser antagónico va a cambiar las cosas?

Lo que estoy diciendo es que a una buena persona de negocios no le importa cómo se transmite el mensaje que escuchan. Así que no sería una buena persona de negocios si ignorara esos comentarios. Si alguna vez trabajó en una línea de atención al cliente para cualquier empresa de tecnología, lo entendería.

Finalmente, mi final general, si lo leíste decía, de cualquier manera, que no importa si los comentarios anteriores son agradables (si los comentarios anteriores son agradables) o no (el comentario sobre el que estás dando una conferencia) no lo van a hacer porque no no tiene piel en el juego, es gratuito. Realmente es un punto discutible y deberían cerrar el boleto.

¿Podemos centrar la sección de comentarios en posibles soluciones y conocimientos, en lugar de quejarnos de por qué este problema aún no se ha resuelto? Una forma de comunicarle el impacto de este problema es mediante la votación sobre la descripción del problema .

Gracias

Hay un PR abierto para esto (# 13754) ...
Si alguien declarara oficialmente una bifurcación y configurara un sitio estático básico con binarios para windows, apple y linux ... quizás un par de 1000 desarrolladores angulares se abalanzarían sobre él de la noche a la mañana, y si hay un pequeño botón de donación en algún lugar, también podría ganar algo de dinero. por el esfuerzo.
Personalmente, no necesito esta función en este momento, pero VSCode está bajo la licencia del MIT, la comunidad realmente quiere una función y algunos miembros de la comunidad han trabajado muy duro para implementar esta función.
Entonces...

¡Quizás ellos también puedan arreglar # 75181! El simple hecho de mostrar el panel del Explorador no debería hacer que se abran pestañas de archivos.

@BrunnerLivio te quejas de quejarte demasiado gracioso;). Esto comenzó porque alguien quería corregir o imponer su comportamiento moralista a otra persona sobre cómo alguien comunicaba su disgusto, necesidad o voto. Tu estas haciendo lo mismo. Nuevamente, es un programa gratuito que este problema no va a ninguna parte. No lo ha hecho durante 4 años. Todo el mundo habla de "ellos", esto es gratuito. Son las personas en este foro de lo que me di cuenta, hace aproximadamente un año. Y trabajo demasiado para tener tiempo para hacer esta mejora y prefiero pagar por el IDE, que es lo que hago con webstorm.

Personalmente, creo que sería bueno tenerlo, pero no molestaría a nadie por eso.
ya que es básicamente gratis, no es como si alguien los estuviera obligando a cumplir con un acuerdo de nivel de servicio o pagando dinero por soporte. Dado que la palabra "cliente" implica un producto comprado

Entonces las alternativas son

1. alguien que bifurque la fuente, agregue las características, emita una solicitud de extracción y luego pídales que la incluyan
2. Como otra opción, tal vez pruebe Visual Studio 2019 Community, que también es gratuito (pero no de código abierto) ya que tiene anidación
3. Use algo más hasta que se agregue

Creo que otra alternativa:

Cree una extensión que imite el árbol del Explorador con su propio panel y botón de la barra lateral y utilícelo.

Y así lo hice.

pt., 7.02.2020, 02:15 użytkownik Hecatron [email protected]
napisał:

Personalmente, creo que sería bueno tenerlo, pero no molestaría a nadie.
encima de eso
ya que es básicamente gratis, no es como si alguien los estuviera sosteniendo
a un acuerdo de nivel de servicio o pagando dinero por soporte. Ya que la palabra
"cliente" implica un producto comprado

Entonces las alternativas son

1. alguien que bifurque la fuente, agregue las características, emita un tirón
   solicitud, luego pídales que la incluyan
2. Como otra opción, tal vez pruebe Visual Studio 2019 Community, que es
   también gratis (pero no de código abierto) ya que tiene anidamiento
3. Use algo más hasta que se agregue

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/microsoft/vscode/issues/6328?email_source=notifications&email_token=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG43VMDVNBW63 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ACJ4R3YUKMXFVOO5NSXSQ6DRBSY3TANCNFSM4CDVJHVQ
.

algun avance de esto!! creo que es muy necesario en vscode!!

VS Code es un producto gratuito y Visual Studio, la versión completa, es un producto pago

@GeorgeTarazi Basado en su comentario, voy a asumir que nunca ha usado VSCode o que nunca ha usado Visual Studio. Porque si hubieras usado ambos, sabrías que son productos completamente diferentes. Visual Studio no es de ninguna manera la "versión completa" de VSCode.

Nadie quiere seguir recibiendo notificaciones sobre sus opiniones fuera de tema. Quizás los encargados del mantenimiento del repositorio deberían considerar bloquear la discusión sobre este tema por ahora.

Personalmente, encontré la edición de Visual Studio 2019 Community (gratuita) lo suficientemente buena para todo lo que necesito hacer
en comparación con las antiguas versiones Pro / Enterprise del pasado.
Esto tiene sentido cuando lo miras desde el punto de vista de MS que intenta impulsar dotnet como una alternativa de código abierto a Java, por ejemplo.
Aunque es probable que necesite una licencia para usar Studio 2019 desde una perspectiva comercial.

Sin embargo, uso tanto Studio 2019 como VSCode para diferentes casos de uso. VScode prefiero para python, Studio 2019 prefiero para dotnet.
VSCode si estoy trabajando en algo de código abierto, etc.
Es probable que el compilador no se comparta, al menos no para dotnet, ya que es una herramienta externa separada por cierto.
Además, ambos están escritos en diferentes idiomas, VSCode - Javascript, Studio 2019 probablemente una combinación de C # y CPP.

Supongo que la razón por la que la función aún no se ha transferido es ether

1. Su objetivo es implementar alguna otra característica primero, como algo relacionado con las extensiones o una dependencia que se necesita primero
2. Equipo diferente, nivel de recursos diferente
3. Debe escribirse desde cero, no se puede copiar y pegar entre diferentes idiomas.

@georgebatalinski Estoy de acuerdo con la mayor parte de lo que dices. Sin embargo, diré que el código visual me parece más útil para angular que para visual studio, específicamente hizo todo lo posible para ser más amigable con los desarrolladores para los spas de front-end. He estado usando productos VS desde los años 90, así que probablemente sea mayor que tú;) Me remonto a los días vb, incluso Qbasic. Yo personalmente estoy cansado de lo de yo, de mí, dámelo gratis. Me complacerá pagar por el código visual para obtener esta función adicional en particular. Pero nuevamente, todavía no estoy usando VC porque creo que esta función es solo necesaria para aplicaciones de mayor escala en mi opinión.

¿Se implementará esta característica?
Lo encuentro bastante útil cuando trabajo con proyectos web, ya que hay muchos archivos generados que abarrotan el espacio de trabajo (pero a veces es necesario mirarlos, por lo que esconderlos no es una solución).

¿Por qué no dejar al usuario la opción de deshabilitarlo / habilitarlo y elegir qué extensiones lo activan? :-)
Parece tan simple de implementar ...

@ funder7 No muy pronto. Los desarrolladores han expresado que tienen una visión ideológica diferente sobre cómo debería funcionar VS Code, por lo que esto no es exactamente una prioridad.

Gracias @tmarkovski , estoy usando esto ahora para eliminar los archivos generados rm -f *.js *.map ... Por cierto, descubrí esa característica en IntelliJ Idea, es muy útil cuando se trabaja con proyectos complejos.
Si eso no está en la forma en que el desarrollador ve la aplicación, al menos la mantendría deshabilitada de manera predeterminada, pero dejaría al usuario final la opción de habilitarla.
Mencioné Idea porque este tipo de características para mí son las que marcan la diferencia entre un software secundario y tu favorito.

De hecho, he descubierto que esto

        "**/*.js": {
            "when": "$(basename).ts"
        },

oculta los archivos generados, pero luego desaparecen y no se nota su presencia: /

Han pasado más de 4 años, lo cual es una eternidad en la tierra del software, ¿y todavía no hay planes para implementar esto? Esto es enorme para la productividad al reducir la carga mental al escanear a través de una enorme estructura de árbol de archivos. Permite archivos de interfaz de Typecript separados sin la carga de archivos adicionales que aparecen en el explorador.

¿Algún progreso para esta función?

¿Algún progreso para esta función?

El problema duplicado fue cerrado por un miembro del equipo de vscode la semana pasada, por lo que lo saben pero eligen ignorarlo.
Realmente luchando por ver por qué.

Realmente luchando por ver por qué.

Porque no es una prioridad para ellos. Como equipo, han decidido priorizar otras cosas. Puedes estar en desacuerdo con sus decisiones, pero todo este lloriqueo de " Dios mío, por qué " es desagradable y sin sentido.

Porque no es una prioridad para ellos. Como equipo, han decidido priorizar otras cosas. Puedes estar en desacuerdo con sus decisiones, pero todo este lloriqueo de "Dios mío _whhhhhy_" es desagradable y sin sentido.

Para mí, no tiene sentido que un desarrollador decida cómo otro debe escribir su código. Es por eso que las aplicaciones suelen tener una vista de "preferencias", donde puede configurar el entorno que desee. Dado que estamos hablando de una herramienta que se usa todo el día para fines de trabajo, no me parece estúpido pedir una función que haga que la lista de archivos sea más legible.

Los usuarios que solicitan funciones es la forma en que VSCode mejora, y tal vez si suficientes personas solicitan esta función, realmente sucederá. Pero quejarse no tiene sentido.

debe tener una función para espacios de trabajo grandes.

He estado echando otro vistazo a esto recientemente, por lo que puedo deducir, ha habido un par de solicitudes de extracción en el pasado que no han ido muy lejos.

• https://github.com/microsoft/vscode/pull/13754
• https://blog.floatas.net/blog/visual%20studio%20code%20file%20nesting/

Pero estoy empezando a pensar que debería ser posible implementar esto como una extensión basada en lo que he visto aquí.

• https://code.visualstudio.com/api/extension-guides/tree-view
• https://github.com/fernandoescolar/vscode-solution-explorer

Investigué algunas de las otras extensiones en vscode pero no encontré nada
Creo que lo que necesitamos es que alguien escriba una extensión que pueda mostrar lo mismo que la ventana del explorador de archivos predeterminada pero con anidación agregada, idealmente con soporte para leer archivos .filenesting.json que ya está en uso en Visual Studio 2019 (no código)

• https://docs.microsoft.com/en-us/visualstudio/ide/file-nesting-solution-explorer?view=vs-2019

javascript no es mi primer idioma, así que no estoy seguro de si alguna vez podré hacer algo por mí mismo
aunque creo que hay suficiente API de extensión expuesta para hacer esto, al menos en una pestaña del explorador separada a la izquierda

Hola @grbd , creo que el "gancho" para este desarrollo sería el punto donde el explorador de archivos está manejando carpetas: eso mostraría cómo se muestran los archivos anidados. Entonces este beaviour debería extenderse a archivos, en lugar de solo directorios.
Sería bueno agregar una configuración para indicar qué extensiones de archivo deben incluirse en el nuevo modo de visualización.
Nunca desarrollé nada para vscode, así que no puedo darte otra información ... Sin embargo, desarrollar una extensión parece una buena idea, y tal vez una vez que esté bien usado y probado, tal vez se mueva al código fuente de la aplicación principal.

Como punto de partida, probablemente miraría vscode-solution-explorer y lo copiaría / pegaría
ya que ya está haciendo algo similar al mostrar archivos en subdirectorios similar al explorador de archivos principal
la diferencia es que su intención es emular la vista de VStudio 2019 en lugar de anidar archivos.

la configuración para saber qué extensiones de archivo deben incluirse sería algo como .filenesting.json como mencioné anteriormente, o algún otro archivo relacionado con json.

Realmente luchando por ver por qué.

Porque no es una prioridad para ellos. Como equipo, han decidido priorizar otras cosas. Puedes estar en desacuerdo con sus decisiones, pero todo este lloriqueo de "Dios mío _whhhhhy_" es desagradable y sin sentido.

Te das cuenta de que estás en el problema de _feature request_, ¿verdad? Estarías en cualquier otro lugar, pero este es el lugar _real_ correcto para solicitar y hablar sobre ello (no tiene sentido quejarse). Nunca será una prioridad si piensan que la gente es feliz y no la necesita.

Explicaré por qué necesito "carpetas virtuales": estoy trabajando con una base de código C configurada a través de un archivo MAKE, que no puedo arriesgarme a cambiar. Sin embargo, el código es un desastre y tengo otras bases de código que mantener con el mismo problema.

Necesito organizar virtualmente los archivos en directorios virtuales para mantener mi cordura, y puedo hacerlo en: Code :: BLocks, Programmers Notepad (sí). Pero no puedo en VS Code.

Esto es un _must_ para las personas que no tienen el control sobre cómo organizan sus archivos en carpetas, lo cual es común en muchas organizaciones. No se trata de "hacerlo más bonito".

El resultado: soy mucho menos productivo usando VS Code. Ojalá pudiera usarlo, pero es solo un flujo de trabajo más lento.

Espero que el equipo cambie de opinión, no creo que esto deba ser manejado por un complemento, aunque técnicamente podría hacerlo. No quiero depender de un proveedor de complementos para una necesidad tan importante, invirtiendo tiempo en algo que podría romperse.

Entiendo que no es una prioridad, solo pido que, si desea que más usuarios puedan usar VS Code y sean productivos, lo considere en el futuro.

@grbd Me encantaría ayudar, pero esto parece mucho trabajo, no estoy seguro si tengo tanto tiempo.
Actualicé la bifurcación de anidación de archivos personalizados para que coincida con el maestro de hoy. Si alguien necesita un punto de partida con el anidamiento de archivos, también se agregaron binarios para probarlo.
https://github.com/floatas/vscode