Vscode: Aninhamento de arquivo

fyi @bpasero

O cenário mais ideal para isso é que qualquer coisa que comece com o mesmo texto de um arquivo principal, menos a extensão, seja aninhada, como este;

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

Sem planos no momento. Fechando até que reconsideremos isso.

Este é um recurso importante para grandes projetos. Estou usando o asp.net vNext para o projeto Angular e agora tenho a seguinte estrutura automaticamente (por nomenclatura):

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

No VS Code Explorer, obtive:

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

Criar pastas para cada componente é uma solução ruim para o projeto angular (você precisará alterar as referências).

Precisamos desse recurso para mudar para o VS Code.

Concordo, pelo menos arquivos ts + js + map (por exemplo, como o webstorm faz)

Seria ótimo ter um aninhamento de arquivo para o estilo ts + js + map +.

Atualmente, estamos ocultando os arquivos .js e .map, o que torna a verificação deles um incômodo. Mesmo com apenas ts + css, a barra lateral ainda parece inchada.

Concordo, desejo aninhamento de arquivo como este (especialmente para ng2)

Html
--css
--ts
- etc ...

Por favor, reconsidere isso! Esta é uma questão tão importante.

Existem tantos casos em que os arquivos gerados apenas bagunçam a área de trabalho. Texto datilografado! Texto datilografado que você também usa! é um excelente exemplo. Ou MENOS / SASS -> css. Ou Jade -> Html

Existe a opção de ocultar condicionalmente os arquivos gerados. Por exemplo:

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

Este mesmo princípio pode ser aplicado aos seus arquivos css e map.

E estou usando essa opção. O problema surge quando eu quero ver o
arquivos ocultos. Também não está claro se os arquivos ocultos são realmente
aí (que a geração tá funcionando ...), o que me faz abrir a pasta
no explorer onde os arquivos também não estão agrupados ... outra coisa é que
alguns dos meus colegas não se sentem confortáveis ​​em não ver metade dos arquivos em
o projeto e gostaríamos de usar as mesmas configurações para toda a equipe.

Por alguma razão, a maioria dos outros editores considerou este recurso útil o suficiente para
implementá-lo então por que não vs código.

Gostaria de observar que esse não é um recurso realmente complicado. Eu estou
tenho certeza de que pode ser feito em um dia. (Eu estava pensando em dar um puxão
pedido, mas pode exigir algumas pequenas mudanças na arquitetura em torno
FileStat)

No domingo, 25 de setembro de 2016, Andrew Sheehan [email protected]
escreveu:

Existe a opção de ocultar condicionalmente os arquivos gerados. Por exemplo:

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

Este mesmo princípio pode ser aplicado aos seus arquivos css e map.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/6328#issuecomment -249392536,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABzUP4LXESXZpGtY1iFZJmmy9J10k4-Uks5qta2DgaJpZM4IdUnr
.

+1

alguma extensão que pode fazer o trabalho?

Por que está fechado? Não está implementado e seria um ótimo recurso.

@uxsoft

Por alguma razão, a maioria dos outros editores considerou este recurso útil o suficiente para
implementá-lo então por que não vs código.

Talvez porque eles precisem de um motivo para as pessoas usarem o estúdio visual real :-)

Este não deveria ter sido fechado, reabrindo. Embora possa haver duplicatas enquanto isso.

@stevencl @chrisdias @seanmcbreen @egamma fyi precisamos de alguma orientação e orientação de PM aqui se quisermos transformar o explorador de arquivos em uma visão lógica. Um PR inicial foi criado por @playerx em https://github.com/Microsoft/vscode/pull/13754

Meus 2 centavos no momento: devemos pensar em uma solução para os cenários que nossos usuários desejam resolver e minha sensação é que apenas suportar para mostrar arquivos semelhantes no mesmo nível abaixo de um arquivo root não é suficiente. As pessoas podem querer algo poderoso como o explorador de soluções no VS.

@bpasero , minhas desculpas, mas a pergunta que você fez não está correta. existem dois tipos diferentes de recursos:

N1. Transforme o explorador de arquivos em uma visão lógica
Exemplo: você pode vincular o arquivoA ("diretórioX / arquivoA") ao arquivoB, que é colocado no diretórioY

N2. Dê suporte ao explorador de arquivos para mostrar arquivos reais de forma mais elegante e dê aos desenvolvedores a capacidade de habilitar este recurso, por exemplo:

O Recurso N1 e o Recurso N2 não são iguais, é uma parte muito importante aqui, eles não cobrem um ao outro.

Obrigado

@playerx Eu

Independente do VS, nosso próprio projeto está colocando todos os arquivos MAP e JS gerados em uma pasta out , não no mesmo nível dos arquivos TS e tenho certeza de que há outros projetos que fazem o mesmo. Meu ponto é que eu esperaria aninhar esses arquivos nos arquivos TS da mesma maneira que você faz quando eles estão no mesmo nível.

Para mim, aninhamento não é agrupar arquivos com a mesma extensão, é mostrar juntos arquivos que pertencem logicamente um ao outro (também conhecido como "recursos derivados"). Isso faz sentido?

@playerx N2 parece muito melhor. Para os usuários do angular 2 cli, isso não deve exigir essa convenção de nomenclatura. Talvez possa haver algum padrão configurável, como na configuração de ocultar arquivos.

Angular2 cli cria arquivos como este:

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

@mbeckenbach bom exemplo, obrigado

@bpasero aninhando arquivos gerados, em arquivos TS é um ótimo exemplo, obrigado

Eu quero perguntar a todos, vamos colocar todos os exemplos práticos possíveis aqui (não teóricos, por favor), que usaríamos no dia a dia e vamos fazer a solução com base nesses exemplos.

Vamos fazer a pergunta:
Como deixar o Explorer "mais inteligente" para visualizar imagem real da estrutura dos arquivos, de forma mais elegante?

@bpasero está bem? Ainda estou tentando não misturar o recurso N1 com o recurso N2.

Cenário 1:
antes de:

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

depois (opção 1):

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

depois (opção 2):

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

depois (opção 3):

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

Cenário 2:
antes de:

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

depois de:

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

@playerx Uma adição: ele também gera este arquivo: my.component.spec.ts

Eu tinha escondido os arquivos de especificações porque não faço testes de unidade em projetos de demonstração. :-)

obrigado, Cenário 1 atualizado, por favor, selecione qual opção você escolheria usar

O cenário 1, a opção 1, seria o mais adequado, em minha opinião.

1. Um componente angular 2 pode existir sem o arquivo html (modelos embutidos)
2. Permitiria nomes de arquivo adicionais como por exemplo my.component.animations.ts se a equipe do angular decidir extrair mais partes em vários arquivos algum dia

Cenário 1, opção 1 ftw! +1 por causa das convenções de nomenclatura angular2

@seveves Eu definitivamente quero ter esse recurso, mas devo dizer que as convenções de nomenclatura do Angular 2 são simplesmente terríveis. O suporte a esse recurso não deve ser baseado em um guia de estilo arbitrário específico de estrutura que dita convenções de nomenclatura com base na necessidade de ergonomia do desenvolvedor sob as ferramentas de construção do Módulo ES anteriores que não são mais relevantes para a estrutura que as está usando. Mais uma vez, quero ver o suporte para esse recurso, mas acho que é o motivo errado.

@aluanhaddad - para não sair do assunto aqui, mas você tem um exemplo de qual seria a melhor convenção de nomenclatura para os 4 arquivos especificados nos cenários?

Todos os arquivos têm o mesmo nome fora da extensão (arquivo + .spec), que obviamente não é específico do angular2. A questão colocada é qual é a ordem de prioridade das extensões com arquivos com nomes semelhantes: quais seriam consideradas as principais para agrupar.

Acho que com este cenário (tipos do lado do cliente), a prioridade seria: TS, JS, HTML, [tipos de estilo]. Você sempre teria um arquivo TS ou JS, mas não necessariamente um modelo ou estilo

Isso seria realmente legal !!

@playerx comentou em 15 de outubro de 2016 • editado

Para a sugestão:

N1. Transforme o explorador de arquivos em uma visão lógica
Exemplo: você pode vincular o arquivoA ("diretórioX / arquivoA") ao arquivoB, que é colocado no diretório

Tenho certeza de que isso está disponível em qualquer sistema operacional atual; o windows tem suporte para "Junctions" por alguns lançamentos agora, e até tem um comando MKLINK agora.

Dado isso, não vejo uma necessidade real para a opção N1, e eu recomendaria o comentário de ciel (comentado em 13 de maio de 2016) de aninhamento com base na extensão.

Que tal usar um conjunto de regras configuráveis ​​mais ou 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"
]

Outra opção é usar padrões RegEx.

Isso aninharia os arquivos que correspondem aos padrões na ordem especificada pelos padrões. Isso abre um amplo conjunto de opções de configuração, não está limitado à convenção Angular 2 (nem mesmo limitado a ts / js / html) e fornece previsibilidade e consistência.

Acho que a introdução de visualizações de solução como no Visual Studio adiciona complexidade desnecessária ao VSCode e o faz perder sua experiência de edição leve.

@aluanhaddad - para não sair do assunto aqui, mas você tem um exemplo de qual seria a melhor convenção de nomenclatura para os 4 arquivos especificados nos cenários?

Realmente, eu não mudaria muito do ponto de vista lógico

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

se tornaria

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

😆
porque é óbvio que é um componente ...

Eu estava me opondo às convenções de nomenclatura Angular 2 de John Papa. Eu me oponho à sua nomeação de componentes, tubos, serviços, módulos e o resto do absurdo redundante. Ele veio com essas convenções para Angular 1 quando ele estava usando configurações Grunt para empacotar manualmente módulos IIFE empacotados, controladores, serviços e diretivas (tudo isso era uma ideia decente na época). O suficiente era habilitar o empacotamento e outras tarefas do Grunt para carregar todos os .module arquivos primeiro para que os scripts que registraram controladores, serviços e assim por diante não explodissem no carregamento.

Dito isto, seu guia de estilo Angular 1 era quase perfeito em todos os outros aspectos, e esses cenários eram relevantes na época, mas seu guia de estilo Angular 2 (o oficial) é terrível. Então, novamente, quem poderia escrever um guia de estilo elegante para algo tão inerentemente feio?

Eu acho que o File Nesting é uma obrigação no desenvolvimento moderno, especialmente no desenvolvimento web ...

Por favor, por favor ... considere apoiá-lo.

Parece que o que realmente queremos aqui é um sistema de visualização lógica personalizado configurado ao lado do explorador físico.

Vamos imaginar que temos um projeto com estrutura (é complicado 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

Precisamos de algum explorador lógico que nos permita definir como agrupar arquivos e como exibi-los. Os grupos podem ser aninhados, então acabamos tendo uma visão que não está relacionada à estrutura de pastas. Vamos imaginar uma configuração de visualização 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 desta visualização, nossos arquivos devem ser exibidos como:

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

Observe que, no exemplo atual, os arquivos de especificações estão completamente ocultos. É feito para fazer o usuário focar no código. Nesse caso, o usuário teria uma visão lógica separada que apresentaria os testes de unidade da maneira que ele gosta. Deve ser configurável no nível de área de trabalho, usuário e extensão. O usuário deve ser capaz de alternar rapidamente entre as visualizações da interface e dos atalhos do teclado.

Este é apenas um rascunho, mas espero que apresente a ideia de forma clara.

Ainda estou realmente esperando que isso seja resolvido. É muito importante para a organização.

Isso também se aplica cada vez mais a Aurelia. Estrutura muito semelhante ao Angular 2+. Adicionar aninhamento de arquivo (configurável) cortaria uma pasta src totalmente expandida com filhos recolhidos em um de nossos projetos médios em cerca de 2/3 de comprimento.

@ RichiCoder1 sim, de fato e, felizmente, Aurelia usa convenções de nomenclatura lógicas e não redundantes :)
Você verificou a extensão vscode de aurelia e seu comando Open-Related-File . Não está relacionado ao aninhamento, mas é muito útil.

Eu também adoraria renomear um grupo em uma única operação de renomeação.

Isso está se tornando muito importante à medida que você começa a trabalhar em um aplicativo angular enorme, por favor, considere isso para trazer o vscode, vs já o tem, se não, traga uma experiência semelhante para aninhamento de arquivo que temos em vs

Cara, isso realmente tornaria o aplicativo Angular em que estou trabalhando muito menos confuso e obtuso. Eu sinceramente espero que vocês estejam considerando isso seriamente.

Como eu disse em outra edição ..

O maior motivo pelo qual quero isso é o angular, onde tenho muitos arquivos com nomes semelhantes 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

Se pudesse aninhar aqueles, seria ótimo.

Eu também faço o padrão Comando / Mediador, e assim acabo com arquivos que se parecem com ...

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

Ele fica muito prolixo e esse recurso só faria o meu dia.

Este é o único motivo pelo qual ainda estou usando o WebStorm ...

Sim, nós também.

Em 2 de junho de 2017, às 10:10, MigFerreira [email protected] escreveu:

Este é o único motivo pelo qual ainda estou usando o WebStorm ...

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Pergunta idiota: alguém pode fornecer uma captura de tela de sua aparência? Não consigo imaginar qual é o sentido por trás disso.

Ah, ok, obrigado.

Isso agora se tornou o maior recurso que faltava para nós. Tenho colegas de trabalho que não o usam por não ter esse recurso. É uma verdadeira dor quando você está tentando encontrar um arquivo específico quando muitos têm nomes semelhantes. Tentamos adicionar mais subpastas para cada componente (Angular), mas essa não é uma solução ideal e voltamos a listar apenas todos os componentes nas pastas de recursos (e sub-recursos).

Estou apresentando o TypeScript e o Angular a um grande projeto Dojo e posso dizer que esse recurso se tornará muito importante para os usuários do VSCode em nossa equipe nos próximos meses.

Atualmente estou trabalhando em um projeto Angular e ser capaz de agrupar arquivos relacionados seria uma excelente adição a um produto que já é excelente. Conforme o projeto Angular cresce, mais difícil se torna de navegar e atualmente atrapalha a produtividade.

Repetido de # 13754:

IMO, a solução mais elegante seria deixar isso para o projeto. Como em .vscode/settings.json ou talvez project.json . Use algo como a sintaxe de exclusão de arquivo. Isso permitiria a personalização por projeto ou por pasta. Os mantenedores da estrutura / ferramenta, ou VSCode, ou um terceiro podem distribuir conjuntos de padrões para determinados fluxos de trabalho.

Dessa forma, o VSCode não assume nada e não causa problemas para ninguém. Ele pode detectar possíveis candidatos para aninhamento e exibir um alerta perguntando: "Parece que você tem arquivos que devem ser aninhados. Deseja aplicar um desses perfis de aninhamento padrão?"

Se os desenvolvedores desejam um aninhamento lógico, eles podem. Se eles não quiserem, eles simplesmente não adicionam as configurações.

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

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

Para capturar my-component.dev.ts sob my-component.ts :

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

Ou para arquivos gerados (usando o esqueleto de navegação Aurelia onde os arquivos são gerados em 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)"}
}

Com alguma sintaxe bem definida como essa, eu poderia adicionar qualquer esquema de aninhamento que eu quisesse, desde que não fosse excessivamente complicado. O último exemplo é baseado na manipulação de caminhos do gulp ( $(path) = o caminho começando com o primeiro glob).

Eu adoraria algumas informações ou comentários sobre se isso está sendo considerado ou não. Do jeito que está agora, não vou usar o VS Code para nenhum Angular ou Aurelia dev até que seja um recurso incluído.

@threedaysmore Não há nenhuma indicação de que a equipe VSCode está realmente considerando isso (já que chegou ao fim do backlog). PR # 13754 aborda isso, mas parece que @playerx o abandonou, pelo menos temporariamente.

Criei um PR mais atualizado: # 32061. Estou procurando ajuda porque meu manuseio de algumas coisas (nomeadamente o modelo de árvore) é problemático.

+1

+1

+1

Não tenho certeza de como mostrar que estou interessado neste recurso. O +1, não parece ser uma maneira muito boa, pois vai spam no tópico (e as pessoas dão um polegar para baixo). Quais são as maneiras recomendadas de dar um +1 ou "eu adoraria esse recurso" para um problema do github, simplesmente para mostrar meu interesse?

Basta adicionar polegar para cima no comentário do primeiro autor, para indicar / aumentar a importância deste recurso

@bpasero fechou meu pull request # 32061: "Obrigado pelo PR, mas não o aceitamos para esta grande área." (Concedido, meu pedido de pull foi bastante embrionário.)

Um mantenedor ou qualquer outra pessoa pode expandir isso? Ou fornecer alguma orientação sobre como isso pode ser implementado como uma solicitação pull ou extensão?

@ firelizzard18 Eu queria muito esse recurso, passei algum tempo trabalhando nisso e recebi o mesmo feedback. Acho que há algum motivo pelo qual eles não querem esse recurso, mas eles não estão nos dizendo :)

@bpasero
Acho que esse recurso merece mais orientação de você (dos colaboradores), como isso pode ser feito e como você pode ver, existem pessoas que podem gastar seu tempo para fazer isso acontecer.

Seria ótimo ter o aninhamento de arquivos no VS Code também.
Recentemente, mudei do VS 2017 para o VS Code para programação Angular / front-end para meu aplicativo ASP.NET Core, devido ao melhor suporte / integração Angular. Funciona muito melhor, mas estou perdendo muito o aninhamento de arquivos. :-(

Adicione o recurso de aninhamento de arquivo ao VS Code ou dê a outros a possibilidade de desenvolver uma extensão!

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

@bpasero Estou curioso para saber se podemos obter alguma atualização sobre isso da equipe? Tem havido muita atividade de várias pessoas ao longo de vários anos; foi fechado, reaberto e teve várias implementações rejeitadas com direção mínima. Esta ainda é a funcionalidade desejada?

Existem casos de uso fortes para as comunidades React e TypeScript, e o sentimento do desenvolvedor tem sido consistentemente positivo (o que eu gostaria de afirmar, pessoalmente). obrigado novamente

@develleoper Acho que eles deixaram bem claras suas expectativas. Eles querem que seja totalmente personalizável para ser aceito. Não faz sentido permitir nada que não dê a você controle total sobre o explorador de arquivos. A parte complicada é que você deve permitir a criação / movimentação de arquivos enquanto a estrutura em seu IDE pode ser completamente diferente da física. Também acho que eles esperam que ele permita alternar entre várias visualizações (por exemplo: você pode ter contexto de arquivo e contexto de testes de unidade. Escreva testes em um e, em seguida, alterne para outro para satisfazê-los).

Tenho certeza que eles estão cientes dos casos de uso, mas se você olhar o roteiro, verá que seus planos são muito mais ambiciosos e úteis do que este, então é (eu acho) por que eles decidiram deixar este para a comunidade .

Acho que você é mais do que bem-vindo - uma grande oportunidade de carreira na Micro $ oft está esperando pela corajosa;)

"Micro $ oft" LUL - Estou surpreso que os pré-adolescentes com experiência limitada estejam seguindo este tópico.

_De qualquer forma_,

@waynebloss IMO, este recurso não deve ser deixado como uma extensão potencial que requer um novo painel. Essa abordagem não exigiria apenas a reimplementação da árvore de arquivos com todos os seus recursos atuais, mas também a atualização com quaisquer recursos futuros que sejam adicionados. Sim, o código da árvore de arquivos atual pode ser bifurcado em uma extensão, mas isso não diminui a carga de manutenção de rastrear futuras atualizações de funcionalidade.

No mínimo, a própria árvore de arquivos poderia conceder pontos de extensibilidade suficientes para implementar isso. (Adicionar isso e construir uma extensão para utilizá-lo para este recurso provavelmente seria menos trabalho inicial de qualquer maneira.)

@RoyTinker concordou - eu estava pensando que um novo painel seria apenas uma solução alternativa até que o aninhamento de arquivos fosse oficialmente suportado.

@Wayofthesin Não tenho certeza do que você está tentando chegar. Acho que ninguém está seriamente questionando se a comunidade deseja esse recurso, pois deixamos bem claro que sim. E o que é igualmente claro, se você realmente ler a história, é que a comunidade tentou implementar isso e os desenvolvedores disseram "Não". @playerx fez um pedido de pull e foi informado de "Não". Eu bifurquei sua solicitação de pull e mesclei o branch master mais novo naquele ponto, fiz alguns ajustes e enviei. E foi dito "Não".

Portanto, deve ser bastante evidente que a comunidade deseja isso e os desenvolvedores não têm interesse em aceitar uma contribuição da comunidade para isso.

@develleoper e outros, eu acho que os comentários de no @playerx '@bpasero s PR-nos dizer muito sobre onde a equipe VSCode quer ir com isso: https://github.com/Microsoft/vscode/pull/13754

A partir de seus comentários, entendo que @bpasero :

• quer uma abordagem abrangente que atenderia a todos os grupos que desejam uma visão lógica de algum tipo
• pensa no aninhamento de arquivos como uma visão lógica (em oposição a uma visão física do sistema de arquivos)
• acredita que uma visão lógica deve ser separada de uma visão física do sistema de arquivos

Em minha opinião, embora o aninhamento de arquivo _ seja_ uma mudança de visão lógica, a ocultação de arquivo também é, e isso é atualmente suportado na árvore de arquivos e pode ser configurado por meio de configurações. Parece-me que o aninhamento de arquivos é apenas outra forma de ocultar arquivos, exceto que fornece uma maneira de revelar esses arquivos.

Como um aparte, Atom agora suporta aninhamento de arquivo por meio de seu pacote de exibição em árvore - consulte https://github.com/atom/tree-view/issues/572

@ firelizzard18 Eu vi sua solicitação de pull. Eu apenas comentei meus pensamentos. # 32061.

@RoyTinker comentou muito bem o que eles esperam. Você poderia falar sobre a criação de RP, mas, pelo que eu posso ver, nem mesmo a primeira expectativa de @bpasero foi atendida:

Independente do VS, nosso próprio projeto está colocando todos os arquivos MAP e JS gerados em uma pasta de saída, não no mesmo nível dos arquivos TS e tenho certeza de que há outros projetos que fazem o mesmo. Meu ponto é que eu esperaria aninhar esses arquivos nos arquivos TS da mesma maneira que você faz quando eles estão no mesmo nível.

Como um extra, eu acrescentaria: Não pense no explorador virtual como um explorador de arquivos. Alguém pode querer aninhar objetos exportados em um arquivo de texto datilografado.

Eu acho que é por isso que eles não aceitaram os PRs. Eles não estão interessados ​​em corrigir o código existente. Eles procuram uma solução flexível que não seja apenas configurável, mas também extensível. Parece que eles próprios não têm ideia sobre isso, mas sabem muito bem o que não querem.

O problema que vejo é que tentamos adivinhar por que eles não aceitam RP e não há uma resposta e orientação claras. Todos os comentários que vocês fizeram são interpretações sobre o que @bpasero pensa sobre isso.

Tantas conversas e ainda silêncio dos colaboradores, acho que isso não é bom para o produto em si.

@Wayofthesin , @playerx acertou em sabemos que @bpasero não forneceu feedback suficiente para deixar claro para onde devemos ir. No meu caso, @bpasero fechou meu PR com um comentário extremamente vago. Em @playerx 's caso, @bpasero comentou, 'Estamos no final do jogo no momento, eu só será capaz de voltar a este próximo mês,' e não fez qualquer comentário adicional no último ano e meio.

Meu PR era um trabalho em andamento. Eu queria orientação dos desenvolvedores sobre como seguir em frente. Em vez disso, recebi uma resposta enigmática e meu RP foi fechado.

Meu comentário , que você mencionou em sua análise de meu PR, sugeri um plano para abordar os problemas de abordagem de

Estou brincando. Queria melhorar um pouco o clima. Por favor, investigue isso. É realmente difícil trabalhar com esse tipo de visão de projeto. Não é difícil, mas ineficiente.

+1, Concordo, este recurso será muito útil para o desenvolvimento de mini aplicativos do wechat também

Isso é muito difícil de fazer? Cerca de 2 milhões de membros da Comunidade Java precisam desse recurso o mais rápido possível. POR FAVOR....!!!

Parece que o VS Code tem algum suporte para aninhar arquivos virtuais na visualização em árvore. O registro de alterações para a versão 1.29 incluiu este ponto:

Isso parece indicar que uma base para o agrupamento de arquivos foi criada.

@MortenChristiansen mmm ... Não parece a mesma característica '

Como sugestão, o Visual Studio 2017 tem um recurso para aninhamento de arquivo por meio de um arquivo de configuração .filenesting.json . Talvez algo semelhante em termos de um arquivo de configuração possa ser implementado para VSCode

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

Como um exemplo:

{
  "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"
          ]
        }
      }
    }
  }
}

colisão 🏗

seria bom para arquivos gerados automaticamente no DART também.

Isso também seria útil para as extensões do Salesforce. Nossos projetos têm um arquivo *.meta.xml associado a cada arquivo de código, portanto, ele efetivamente torna nossa árvore de arquivos o dobro do comprimento. Adoraríamos colocar esse arquivo de metadados no arquivo de origem.

Não acredito que seja um problema reunir os requisitos / necessidades dos usuários sobre o recurso de aninhamento.
Não acredito que seja um problema implementá-lo. Talvez alguma doação ajude a implementá-lo mais rapidamente nos lançamentos oficiais?

Olhando meus arquivos,
Texto datilografado, web e estilos empilhados.
Aninhar seria bom.

Desculpem rapazes. Parece que não estão nem um pouco interessados ​​nisso.

Cara, eu adoraria ver isso também.

Bizarro - o comportamento desse recurso está muito bem definido e é claramente muito necessário.

+1 vamos, rapazes

Isso não está acontecendo, rapazes, então provavelmente encerrarei o problema.

@isidorn deixou claro que não está interessado nele e não está tentando fazer isso. O que é lamentável. Isso é tudo o que me impede de usar o VSC agora. Um aplicativo Angular é tão prolixo e confuso sem aninhamento de arquivos.

Acho que ainda estou preso ao WebStorm por enquanto.

Sugiro que, para manter este assunto em aberto, possamos resolver isso em um futuro não tão próximo.

@isidorn , dado “um futuro não tão próximo”, você é capaz de fornecer orientação sobre como isso deve ser implementado? Eu gostaria de tentar, mas não obtive nenhum feedback sobre o meu RM.

2019, algo novo pessoal?

Como um desenvolvedor java, isso é o que mais me impede de migrar totalmente para o vscode.

Em meus projetos java, diretórios vazios para namespaces de pacotes java ocupam metade (ou mais) dos espaços disponíveis no explorer. Eu sempre tenho que rolar para cima / para baixo no explorer, o que é meio demorado quando você tem que fazer isso muitas vezes para cada iteração de desenvolvimento. Muitos IDEs para desenvolvimento em java reduzem esses diretórios vazios em um único nome de pacote, tornando mais fácil para os desenvolvedores olharem para toda a estrutura do pacote.

Isso é algo viável de implementar no vscode, mas não priorizado devido a outras tarefas de maior prioridade? ou simplesmente não é possível implementar devido a limitações na arquitetura vscode subjacente?

Qualquer extensão para fazer isso? É um recurso muito necessário!

Aberto há mais de 3 anos ... parece que não vão funcionar ... Instalando o webstorm agora ...

isto e recuando com a colagem de algumas coisas muito básicas que você acha que seriam abordadas, talvez seja isso que você obtém para freeware e código aberto. Não é tão bom ... Já que não há skin no jogo.

Sim - resposta muito decepcionante (ou falta dela) de uma excelente equipe de desenvolvimento.

Fiz aninhamento personalizado, mas minha solicitação pull não será mesclada. Como a equipe de código do VS tem outros planos e não deseja fazer alterações nessa parte do código. Para mim, esse recurso também é importante, então fiz um build personalizado do Vs Code (o armazenamento de extensão funciona), você pode tentar https://github.com/floatas/vscode/releases/tag/1.37 Vai ver como o progresso vai nisso problema, estou pensando em fazer algo semelhante ao VsCodium (compilações automáticas com atualizador), mas com minhas alterações.

Basta adicionar esta configuração ao seu settings.json:

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

O reinício do código Vs é necessário ao habilitar o aninhamento.

@floatas Obrigado pelo seu código! O que você acha de fazer uma extensão?

@ e-belair Infelizmente não é possível criar uma extensão. API para este recurso não está disponível.

O recurso de aninhamento de arquivos seria tão legal! Espero que isso aconteça :)

@floatas Onde fica o PR?

@tariqporter # 72160

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

Como a equipe de código do VS tem outros planos e não deseja fazer alterações nessa parte do código.

Isso seria # 41627, que será trabalhado primeiro como parte da reescrita da visualização em árvore, o que provavelmente tornará isso mais fácil de implementar depois.

Eu acho que o VS Code é ótimo, mas este é um recurso tão básico que falta.

Ansioso por isso também

eu preciso disso

Apenas curioso para saber se há alguma atualização sobre isso? Seria ótimo ter que limpar a visualização em árvore!

Ainda estou usando o VS para Mac apenas por causa desse recurso com os aplicativos Blazor. Por que tanta resistência da equipe?

Há um problema para rastrear a implementação das APIs de extensão necessárias para tornar isso possível por meio delas?

4 anos depois e nenhum progresso nesta questão? oO ..
Isso é incompreensível para ser honesto ...

Não consigo pensar em nenhum IDE que usei que não suporte isso de uma forma ou de outra, nem posso pensar em nenhum projeto em qualquer plataforma em que trabalhei onde isso não seria útil ... oO .. Isso a um ponto onde eu simplesmente assumi que isso era um dado em qualquer IDE ... acho que não ...

A equipe está apenas tentando empurrar as pessoas para os concorrentes? ...
Eu adoraria substituir o WebStorm pelo VSCode, mas acho que isso não está acontecendo. E então não estamos nem perto de substituir VS ou IDEA: S ...

Ah bem...

@jeme Você acha que assediar os desenvolvedores vai surtir algum efeito? Eu sei que se eu fosse um mantenedor, eu ignoraria categoricamente qualquer comentário antagônico. Se você realmente deseja ser construtivo e não apenas uma praga, tente "Este recurso é muito importante para mim e está me impedindo de adotar esta ferramenta."

@ firelizzard18 então você estaria perdendo o fornecimento de uma base de clientes, algo é extremamente necessário. Aprender a ouvir todos os clientes é realmente uma grande característica de se ter, elevando-se acima do frey, por assim dizer. Se você ler os comentários aqui, verá que muitas pessoas estão se comportando da maneira que você diz que deveria fazer com que ouçam. No entanto, eles não estão ouvindo e após 4 anos as frustrações aumentarão, especialmente se alguém realmente quiser mudar, mas não conseguir ver uma maneira porque o projeto é muito grande para não ter os arquivos aninhados. Eu realmente acredito que o código Visual é freeware e ninguém realmente se importa em tornar isso uma prioridade. E é isso que nós, usuários, obtemos por demandar software livre. Não há pele no jogo para eles fazerem alguma coisa. Eu pago por um IDE se isso significar que coisas como essa sejam implementadas. Ainda usando o webstorm (pelo qual eu paguei). Eles realmente deveriam vir e dizer que não vamos fazer isso, portanto, fechando o tíquete e pronto.

Se você ler os comentários aqui, verá que muitas pessoas estão se comportando da maneira que você diz que deveria fazer com que ouçam.

E você acha que ser antagônico vai mudar as coisas?

O que estou dizendo é que um bom empresário não se importa como a mensagem é transmitida, eles ouvem. Portanto, você não seria um bom empresário se ignorasse esses comentários. Se você já trabalhou em uma linha de suporte ao cliente para qualquer empresa de tecnologia, você entenderia isso.

Finalmente, meu final geral, se você leu estava dizendo, de qualquer maneira, não importa (por comentários anteriores serem legais) ou não (o comentário sobre o qual você está palestrando) eles não vão fazer porque eles não tem skin no jogo, é freeware. Realmente é um ponto discutível e eles deveriam fechar o bilhete.

Podemos focar a seção de comentários em possíveis soluções e percepções, em vez de reclamar sobre por que esse problema ainda não foi resolvido? Uma forma de comunicar o impacto desse problema para você é votando na descrição do problema .

Obrigada

Há um PR aberto para isso (# 13754) ...
Se alguém declarasse oficialmente um fork e configurasse um site estático básico com binários para windows apple e linux ... talvez alguns 1000 devs angulares atacassem durante a noite, e se houver um pequeno botão de doar em algum lugar, você também pode ganhar algum dinheiro pelo esforço.
Eu pessoalmente não preciso desse recurso agora, mas o VSCode está sob a licença do MIT, a comunidade realmente quer um recurso e alguns membros da comunidade trabalharam muito para implementá-lo.
Assim...

Talvez eles possam consertar # 75181 também! A simples exibição do painel do Explorer não deve fazer com que nenhuma guia de arquivo seja aberta.

@BrunnerLivio você reclama de reclamar muito engraçado;). Isso começou porque alguém queria corrigir ou impor seu comportamento moralista a outra pessoa sobre como alguém comunicou seu descontentamento, necessidade ou voto. Você está fazendo o mesmo. Novamente, é freeware e esse problema não vai a lugar nenhum. Não o faz há 4 anos. Todo mundo está falando sobre "eles", este é um freeware. São eles que estão neste fórum, foi o que percebi, há cerca de um ano. E eu trabalho demais para ter tempo para fazer esse aprimoramento e prefiro pagar pelo IDE, que é o que faço com o webstorm.

Pessoalmente, acho que seria bom ter, mas não incomodaria ninguém por causa disso
como você sabe, é basicamente gratuito, não é como se alguém os estivesse exigindo de um acordo de nível de serviço ou pagando dinheiro pelo suporte. Uma vez que a palavra "cliente" indica um produto comprado

Então, as alternativas são

1. alguém para bifurcar a fonte, adicionar os recursos, emitir uma solicitação de pull e, em seguida, pedir a eles para incluí-la
2. Como outra opção, experimente o Visual Studio 2019 Community, que também é gratuito (mas não de código aberto), pois tem aninhamento
3. Use outra coisa até que seja adicionado

Uma outra alternativa, eu acho:

Crie uma extensão que imite a árvore do Explorer com seu próprio botão e painel da barra lateral e use-a.

E eu fiz isso.

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

Pessoalmente, acho que seria bom ter, mas não incomodaria ninguém
acima dele
já que você sabe basicamente de graça, não é como se alguém os estivesse segurando
a um acordo de nível de serviço ou pagamento de dinheiro para suporte. Desde a palavra
"cliente" implica um produto comprado

Então, as alternativas são

1. alguém para bifurcar a fonte, adicionar os recursos, emitir um pull
   pedido e, em seguida, peça-lhes que o incluam
2. Como outra opção, tente a Comunidade do Visual Studio 2019, que é
   também gratuito (mas não de código aberto), pois tem aninhamento
3. Use outra coisa até que seja adicionado

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/microsoft/vscode/issues/6328?email_source=notifications&email_token=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELBMCGQ#issuecomment-583188762 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ACJ4R3YUKMXFVOO5NSXSQ6DRBSY3TANCNFSM4CDVJHVQ
.

algum avanço disso !! Acho muito necessário no vscode !!

VS Code é um produto gratuito e a versão completa do Visual Studio é um produto pago

@GeorgeTarazi Com base em seu comentário, vou presumir que você nunca usou o VSCode ou nunca usou o Visual Studio. Porque se você tivesse usado os dois, saberia que são produtos completamente diferentes. O Visual Studio não é de forma alguma a 'versão completa' do VSCode.

Ninguém quer continuar sendo notificado sobre suas opiniões fora do assunto. Talvez os mantenedores do repositório devam considerar bloquear a discussão sobre este assunto por enquanto.

Pessoalmente, achei a edição da Comunidade do Visual Studio 2019 (gratuita) boa o suficiente para tudo o que preciso fazer
em comparação com as antigas versões Pro / Enterprise do passado.
Isso faz sentido quando você olha para isso do ponto de vista da MS tentando empurrar o dotnet como uma alternativa de código aberto ao java, por exemplo.
Embora você ainda precise de uma licença para usar o Studio 2019 de uma perspectiva de negócios.

Eu uso o Studio 2019 e o VSCode para diferentes casos de uso. VScode que eu prefiro para python, Studio 2019 eu prefiro para dotnet.
VSCode se estou trabalhando em algo de código aberto, etc.
O compilador não é provavelmente compartilhado, pelo menos não pelo dotnet, já que essa é uma ferramenta externa separada.
Além disso, ambos são escritos em linguagens diferentes, VSCode - Javascript, Studio 2019 provavelmente uma combinação de C # e CPP.

Eu acho que o motivo do recurso não ter sido transferido ainda é ether

1. Eles pretendem implementar algum outro recurso primeiro, como algo relacionado às extensões ou uma dependência necessária primeiro
2. Equipe diferente, nível diferente de recurso
3. Precisa ser escrito do zero, não pode copiar e colar entre idiomas diferentes.

@georgebatalinski Eu concordo com a maior parte do que você está dizendo. No entanto, direi que acho o código visual mais útil para o angular do que para o visual studio. Ele especificamente saiu do seu caminho para ser mais amigável ao desenvolvedor para spas de front end. Eu uso produtos VS desde os anos 90, então provavelmente sou mais velho do que você;) Eu data de vb dias até Qbasic. Pessoalmente, estou cansado desse negócio de mim eu, me dê de graça. Terei prazer em pagar pelo código visual para obter esse recurso adicional em particular. Mas, novamente, ainda não estou usando o VC porque sinto que esse recurso é apenas necessário para aplicativos em escala maior aos meus olhos.

Este recurso será implementado?
Acho que é bastante útil ao trabalhar com projetos da web, pois há muitos arquivos gerados que desorganizam o espaço de trabalho (mas às vezes você precisa olhar para eles, então esconder não é uma solução).

Por que não deixar ao usuário a escolha de desabilitar / habilitar, e escolher quais extensões o acionam ?! :-)
Parece tão simples de implementar ...

@ funder7 Não muito em breve. Os desenvolvedores expressaram que têm uma visão ideológica diferente sobre como o VS Code deve funcionar, então isso não é exatamente uma prioridade.

Obrigado @tmarkovski , estou usando isso agora para remover os arquivos gerados rm -f *.js *.map ... A propósito, descobri esse recurso no IntelliJ Idea, é muito útil ao trabalhar com projetos complexos.
Se isso não for do jeito do desenvolvedor ver o aplicativo, pelo menos eu o manteria desabilitado por padrão, mas deixando para o usuário final a opção de habilitá-lo.
Mencionei o Idea porque esse tipo de recurso para mim é o que faz a diferença entre um software secundário e o seu favorito.

Na verdade, descobri que este

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

oculta os arquivos gerados, mas eles desaparecem e você não percebe sua presença: /

Já se passaram mais de 4 anos, o que é uma eternidade na terra do software, e ainda não há planos de implementar isso? Isso é enorme para a produtividade, pois reduz a carga mental ao digitalizar uma enorme estrutura de árvore de arquivos. Permite arquivos de interface Typescript separados sem a carga de arquivos adicionais que aparecem no explorer.

Algum progresso para este recurso?

Algum progresso para este recurso?

O problema da duplicata foi fechado por um membro da equipe vscode na semana passada, então eles estão cientes disso, mas optaram por ignorá-lo.
Realmente lutando para ver o porquê.

Realmente lutando para ver o porquê.

Porque não é uma prioridade para eles. Como equipe, eles decidiram priorizar outras coisas. Você pode discordar de suas decisões, mas todas essas lamentações "OMG whhhhhy " são desagradáveis ​​e sem sentido.

Porque não é uma prioridade para eles. Como equipe, eles decidiram priorizar outras coisas. Você pode discordar de suas decisões, mas todas essas lamentações "OMG _whhhhhy_" são desagradáveis ​​e sem sentido.

Para mim, é inútil que um desenvolvedor decida como outro deve escrever seu código. É por isso que os aplicativos geralmente têm uma visualização de "preferências", onde você pode definir o ambiente como desejar. Como estamos falando de uma ferramenta usada o dia todo para fins de trabalho, não me parece estúpido pedir um recurso que torne a lista de arquivos mais legível.

Usuários solicitando recursos é como o VSCode melhora, e talvez se um número suficiente de pessoas solicitarem por esse recurso, ele realmente acontecerá. Mas reclamar é inútil.

deve ter recurso para grandes áreas de trabalho.

Eu tenho dado outra olhada nisso recentemente, pelo que posso deduzir, houve algumas solicitações de pull no passado que não foram muito longe

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

Mas estou começando a pensar que deveria ser possível implementar isso como uma extensão com base no que vi aqui

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

Pesquisei em algumas das outras extensões do vscode, mas não encontrei nada
Acho que o que precisamos é de alguém para escrever uma extensão que pode mostrar a mesma coisa que a janela do explorador de arquivos padrão, mas com aninhamento adicionado, de preferência com suporte para leitura de arquivos .filenesting.json que já está em uso no Visual Studio 2019 (não código)

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

javascript não é minha primeira língua, então não tenho certeza se algum dia serei capaz de fazer algo sozinho
embora eu ache que há API de extensão suficiente exposta para fazer isso, pelo menos em uma guia separada do explorador à esquerda

Olá @grbd , acho que o "gancho" para este desenvolvimento seria o ponto em que o explorador de arquivos está lidando com as pastas: isso mostraria como os arquivos aninhados são exibidos. Então, este comportamento deve ser estendido aos arquivos, em vez de apenas aos diretórios.
Seria bom adicionar uma configuração para informar quais extensões de arquivo devem ser incluídas no novo modo de exibição.
Nunca desenvolvi nada para vscode, então não posso lhe dar outras informações ... Porém, desenvolver extensões parece uma boa ideia, e talvez uma vez que seja bem usado e testado, talvez seja movido para o código-fonte do aplicativo principal.

Como ponto de partida, provavelmente iria olhar para vscode-solution-explorer e copiar / colar
uma vez que já está fazendo algo semelhante ao mostrar arquivos em subdiretórios semelhantes ao explorador de arquivos principal
a diferença é que sua intenção é emular a visualização do VStudio 2019 em vez de fazer o aninhamento de arquivos.

a configuração para informar quais extensões de arquivo devem ser incluídas seria algo como .filenesting.json, como mencionei acima, ou algum outro arquivo relacionado a json.

Realmente lutando para ver o porquê.

Porque não é uma prioridade para eles. Como equipe, eles decidiram priorizar outras coisas. Você pode discordar de suas decisões, mas todas essas lamentações "OMG _whhhhhy_" são desagradáveis ​​e sem sentido.

Você percebe que está no problema de _solicitação de recurso_, certo? Você estaria certo em qualquer outro lugar, mas este é o lugar _real_ correto para solicitar e falar sobre isso (não é uma lamentação inútil). Nunca será uma prioridade se eles acharem que as pessoas são felizes e não precisam disso.

Vou explicar por que preciso de "pastas virtuais": estou trabalhando com uma base de código C configurada por meio de makefile, que não posso arriscar mudar. No entanto, o código está uma bagunça e eu tenho outras bases de código para manter com o mesmo problema.

Preciso organizar virtualmente os arquivos em diretórios virtuais para manter minha sanidade e posso fazer isso em: Code :: BLocks, Programmers Notepad (sim). Mas eu não consigo no VS Code.

Esta é uma _deve_ para pessoas que não têm controle sobre como organizar seus arquivos em pastas, o que é comum em muitas organizações. Não se trata de "torná-lo mais bonito".

O resultado: sou muito menos produtivo usando o VS Code. Eu gostaria de poder usá-lo, mas é apenas um fluxo de trabalho mais lento.

Espero que a equipe mude de ideia, não acho que isso deva ser tratado por um plugin, embora tecnicamente pudesse. Não quero depender de um provedor de plug-in para essa necessidade básica, investindo tempo em algo que pode falhar.

Eu entendo que não é uma prioridade, estou apenas pedindo que, se você quiser que mais usuários possam usar o VS Code e serem produtivos, considere isso no futuro.

@grbd Eu adoraria ajudar, mas isso parece muito trabalhoso, não tenho certeza se eu tenho tanto tempo.
Eu atualizei o fork de aninhamento de arquivo personalizado para corresponder ao mestre de hoje. Se alguém precisa de um ponto de partida com o aninhamento de arquivos, também adicione binários para experimentá-lo.
https://github.com/floatas/vscode