Vscode: 파일 중첩

참고로 @bpasero

이에 대한 가장 이상적인 시나리오는 부모 파일과 동일한 텍스트로 시작하고 확장자를 뺀 모든 것이 다음과 같이 중첩되는 것입니다.

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

현재 계획이 없습니다. 이것을 재고할 때까지 닫습니다.

이것은 대규모 프로젝트에 중요한 기능입니다. Angular 프로젝트에 asp.net vNext를 사용하고 있으며 이제 다음과 같은 구조를 자동으로 지정합니다(이름 지정).

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

VS Code Explorer에서 다음을 얻었습니다.

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

각 구성 요소에 대한 폴더를 만드는 것은 각도 프로젝트에 대한 잘못된 솔루션입니다(참조를 변경해야 함).

VS Code로 이동하려면 이 기능이 필요합니다.

동의합니다. 최소한 ts + js + map 파일(예: webstorm이 하는 것처럼)

ts + js + map + style에 대한 파일 중첩이 있으면 좋을 것입니다.

현재 우리는 .js 및 .map 파일을 숨기고 있어 확인하기가 번거롭습니다. ts + css만 있어도 사이드바는 여전히 부풀려진 느낌입니다.

동의합니다. 이와 같은 파일 중첩을 원합니다(특히 ng2의 경우).

HTML
--css
--ts
-- 등 ...

이것을 다시 생각해 보십시오! 이것은 너무나 중요한 문제입니다.

생성된 파일이 작업 공간을 어지럽히는 경우가 너무 많습니다. 타이프스크립트! 당신도 사용하는 Typescript! 가 대표적이다. 또는 LESS/SASS -> CSS. 또는 옥 -> HTML

생성된 파일을 조건부로 숨기는 옵션이 있습니다. 예를 들어:

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

이 동일한 원칙을 CSS 및 맵 파일에 적용할 수 있습니다.

그리고 저는 그 옵션을 사용하고 있습니다. 내가보고 싶을 때 문제가 발생합니다
숨겨진 파일. 또한 숨김 파일이 실제로 있는지 여부가 명확하지 않습니다.
거기 (세대가 작동 중입니다 ...), 폴더를 열게 만듭니다.
파일도 그룹화되지 않은 탐색기에서 ... 또 다른 것은
내 동료 중 일부는 파일의 절반이 보이지 않는 것을 불편해합니다
프로젝트와 우리는 전체 팀에 대해 동일한 설정을 사용하고 싶습니다.

어떤 이유에서인지 대부분의 다른 편집자들은 이 기능이
왜 코드와 비교하지 않는지 구현하십시오.

이것은 실제로 복잡한 기능이 아니라는 점에 유의하고 싶습니다. 저는
하루 만에 할 수 있다고 확신합니다. (당길까 생각중이었는데
요청하지만 주변 아키텍처에 약간의 변경이 필요할 수 있습니다.
파일 통계)

2016년 9월 25일 일요일, Andrew Sheehan [email protected]
썼다:

생성된 파일을 조건부로 숨기는 옵션이 있습니다. 예를 들어:

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

이 동일한 원칙을 CSS 및 맵 파일에 적용할 수 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/vscode/issues/6328#issuecomment -249392536,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABzUP4LXESXZpGtY1iFZJmmy9J10k4-Uks5qta2DgaJpZM4IdUnr
.

+1

작업을 수행할 수 있는 확장 기능이 있습니까?

이게 왜 닫혀있나요? 구현되지 않았으며 훌륭한 기능이 될 것입니다.

@uxsoft

어떤 이유에서인지 대부분의 다른 편집자들은 이 기능이
왜 코드와 비교하지 않는지 구현하십시오.

사람들이 리얼 비주얼 스튜디오를 사용해야 할 이유가 필요해서일 수도 있어요 :-)

이것은 닫히지 않았어야 하고 다시 열었습니다. 그 사이에 중복이 존재할 수 있지만.

@stevencl @chrisdias @seanmcbreen @egamma fyi 파일 탐색기를 논리적 보기로 전환하려면 PM 조정 및 안내가 필요합니다. https://github.com/Microsoft/vscode/pull/13754 에서 @playerx 가 초기 PR을 만들었습니다.

현재 내 2센트: 우리는 사용자가 해결하고자 하는 시나리오에 대한 솔루션을 생각해야 하며 루트 파일 아래의 동일한 수준에서 유사한 파일을 표시하는 지원만으로는 충분하지 않다고 생각합니다. 사람들은 VS의 솔루션 탐색기와 같은 강력한 것을 원할 수 있습니다.

@bpasero , 죄송합니다만 질문하신 내용이 정확하지 않습니다. 두 가지 다른 종류의 기능이 있습니다.

N1. 파일 탐색기를 논리적 보기로 전환
예: fileA("directoryX/fileA")를 directoryY에 있는 fileB에 연결할 수 있습니다.

N2. 파일 탐색기가 실제 파일을 보다 우아한 방식으로 표시하도록 지원하고 개발자에게 이 기능을 활성화할 수 있는 기능을 제공합니다. 예:

기능 N1과 기능 N2는 동일하지 않습니다. 여기서 매우 중요한 부분입니다. 서로를 덮지 않습니다.

감사 해요

@playerx 이 문제에 대한 설명이 Visual Studio 2015에 대한 참조로 만들어지고 내가 아는 한 솔루션 탐색기만 있기 때문에 솔루션 탐색기를 불러왔습니다.

VS와 별개로 우리 자신의 프로젝트는 생성된 모든 MAP 및 JS 파일을 TS 파일과 같은 수준이 아닌 out 폴더에 넣고 있으며 동일한 작업을 수행하는 다른 프로젝트가 있을 것이라고 확신합니다. 내 요점은 동일한 수준에 있을 때 수행하는 것과 동일한 방식으로 해당 파일을 TS 파일 아래에 중첩할 것으로 예상한다는 것입니다.

나에게 중첩은 확장자가 같은 파일을 함께 그룹화하는 것이 아니라 논리적으로 함께 속하는 파일(일명 "파생 리소스")을 함께 표시하는 것입니다. 말이 돼?

@playerx N2가 훨씬 좋아 보입니다. Angular 2 cli 사용자의 경우 해당 명명 규칙이 필요하지 않습니다. 파일 숨기기 구성과 같이 구성 가능한 패턴이 있을 수 있습니다.

Angular2 cli는 다음과 같은 파일을 생성합니다.

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

@mbeckenbach 좋은 예, 감사합니다

@bpasero 생성된 파일 중첩, TS 파일 아래에 있는 것이 좋은 예입니다. 감사합니다.

나는 모든 사람에게 묻고 싶습니다. 우리가 일상 생활에서 사용할 수 있는 모든 가능한 실제 예(이론적인 것이 아니라)를 여기에 넣고 그 예를 기반으로 솔루션을 만들어 봅시다.

질문은 다음과 같습니다.
보다 우아한 방법으로 파일 구조의 실제 그림 을 시각화하기 위해 Explorer를 "스마트"하게 만드는 방법은 무엇입니까?

@bpasero 오케이 ? 나는 여전히 기능 N1과 기능 N2를 혼합하지 않으려고 노력하고 있습니다.

시나리오 1:
전에:

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

이후(옵션 1):

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

이후(옵션 2):

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

이후(옵션 3):

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

시나리오 2:
전에:

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

후에:

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

@playerx 추가: my.component.spec.ts 파일도 생성합니다.

나는 데모 프로젝트를 단위 테스트하지 않기 때문에 사양 파일을 숨겼습니다. :-)

감사합니다. 시나리오 1이 업데이트되었습니다. 다음 중 사용할 옵션을 선택하세요.

시나리오 1 옵션 1이 제 생각에 가장 적합할 것입니다.

1. Angular 2 구성 요소는 html 파일(인라인 템플릿) 없이 존재할 수 있습니다.
2. Angular 팀이 언젠가 더 많은 부분을 여러 파일로 추출하기로 결정한 경우 my.component.animations.ts와 같은 추가 파일 이름을 허용합니다.

시나리오 1, 옵션 1 ftw! angular2 명명 규칙으로 인해 +1

@seves 확실히 이 기능을 갖고 싶지만 Angular 2의 명명 규칙은 정말 끔찍합니다. 이 기능을 지원하는 것은 심지어 그것을 사용하는 프레임워크와 더 이상 관련이 없는 사전 ES Module 빌드 도구에서 개발자 인체 공학의 필요성에 따라 명명 규칙을 지시하는 프레임워크 특정 임의 스타일 가이드를 기반으로 해서는 안 됩니다. 다시 이 기능에 대한 지원을 보고 싶지만 그것이 잘못된 이유라고 생각합니다.

@aluanhaddad - 여기서 너무

모든 파일의 이름은 확장자(+.spec 파일) 외부에서 동일하게 지정되며, 이는 분명히 angular2와 관련이 없습니다. 제기된 질문은 유사한 이름의 파일이 있는 확장의 우선 순위가 무엇이냐는 것입니다. 이는 그룹 아래의 기본으로 간주됩니다.

이 시나리오(클라이언트 측 유형)에서 우선순위는 TS, JS, HTML, [스타일 유형]이 될 것이라고 생각합니다. 항상 TS 또는 JS 파일이 있지만 템플릿이나 스타일이 반드시 필요한 것은 아닙니다.

이거 정말 깔끔하겠네요!!

@playerx 2016년 10월 15일에 댓글 작성 • 수정됨

제안:

N1. 파일 탐색기를 논리적 보기로 전환
예: fileA("directoryX/fileA")를 디렉토리에 있는 fileB에 연결할 수 있습니다.

나는 이것이 현재의 모든 OS에서 사용 가능하다고 확신합니다. windows는 현재 몇 가지 릴리스에 대해 "Junctions"를 지원했으며 지금은 MKLINK 명령도 있습니다.

이를 감안할 때 N1 옵션이 실제로 필요하지 않으며 확장을 기반으로 하는 중첩에 대한 ciel의 의견(2016년 5월 13일에 주석 처리됨)을 권장합니다.

다음과 같이 구성 가능한 규칙 집합을 사용하는 것은 어떻습니까?

"*.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"
]

또 다른 옵션은 대신 RegEx 패턴을 사용하는 것입니다.

이렇게 하면 패턴에 지정된 순서대로 패턴과 일치하는 파일이 중첩됩니다. 이것은 Angular 2 규칙(ts/js/html에 국한되지 않음)에 국한되지 않고 예측 가능성과 일관성을 제공하는 광범위한 구성 옵션을 제공합니다.

Visual Studio에서와 같은 솔루션 보기를 도입하면 VSCode에 불필요한 복잡성이 추가되고 가벼운 편집 환경을 잃게 된다고 생각합니다.

@aluanhaddad - 여기서 너무

정말, 논리적인 관점에서 나는 별로 변하지 않을 것입니다.

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

될 것이다

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

😆
왜냐하면 그것은 구성 요소이기 때문입니다 ...

나는 John Papa의 Angular 2 명명 규칙에 반대했습니다. 나는 그가 구성 요소, 파이프, 서비스, 모듈 및 나머지 불필요한 말도 안되는 이름을 짓는 것에 반대합니다. 그는 Grunt 구성을 사용하여 수동으로 IIFE 래핑된 모듈, 컨트롤러, 서비스 및 지시문을 묶을 때 Angular 1에 대한 이러한 규칙을 생각해 냈습니다(이 모든 것이 당시에는 괜찮은 아이디어였습니다). 컨트롤러, 서비스 등을 등록한 스크립트가 로드 시 폭발하지 않도록 번들링 및 기타 Grunt 작업이 모든 .module 파일을 먼저 로드하도록 하는 것으로 충분했습니다.

즉, 그의 Angular 1 스타일 가이드는 다른 모든 면에서 거의 완벽했고 이러한 시나리오는 당시 관련성이 있었지만 그의 Angular 2 스타일 가이드(공식 가이드)는 끔찍합니다. 그렇다면 누가 본질적으로 추한 것에 대한 우아한 스타일 가이드를 작성할 수 있습니까?

File Nesting은 현대 개발, 특히 웹 개발에서 필수라고 생각합니다...

제발, 제발... 지원을 고려하십시오.

여기서 우리가 정말로 원하는 것은 물리적 탐색기 옆에 맞춤 구성된 논리적 보기 시스템인 것 같습니다.

구조가 있는 프로젝트가 있다고 가정해 보겠습니다(의도적으로 복잡함).

- 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

파일을 그룹화하고 표시하는 방법을 정의할 수 있는 논리 탐색기가 필요합니다. 그룹이 중첩되어 폴더 구조와 관련이 없는 보기가 표시될 수 있습니다. 다음과 같은 논리적 보기 구성을 상상해 보겠습니다.

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

이 보기 내에서 파일은 다음과 같이 표시되어야 합니다.

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

현재 예제에서 사양 파일은 완전히 숨겨져 있습니다. 사용자가 코드에 집중할 수 있도록 만들어졌습니다. 이러한 경우 사용자는 자신이 원하는 방식으로 단위 테스트를 제공하는 별도의 논리적 보기를 갖게 됩니다. 작업 공간, 사용자 및 확장 수준에서 구성할 수 있어야 합니다. 사용자는 인터페이스와 키보드 단축키 모두에서 보기 사이를 빠르게 전환할 수 있어야 합니다.

이것은 초안이지만 아이디어가 명확하게 제시되기를 바랍니다.

나는 이것이 제대로 작동되기를 여전히 정말로 희망하고 있습니다. 이것은 조직에 매우 중요합니다.

이것은 또한 Aurelia에도 점점 더 많이 적용되고 있습니다. Angular 2+와 매우 유사한 구조입니다. (구성 가능한) 파일 중첩을 추가하면 평균 프로젝트 중 하나에서 접힌 자식이 있는 전체 확장 src 폴더 길이가 약 2/3로 줄어듭니다.

@RichiCoder1 그렇습니다. 고맙게도 Aurelia는 논리적이고 중복되지 않는 명명 규칙을 사용합니다. :)
aurelia vscode 확장과 Open-Related-File 명령을 확인했습니까? 중첩과 관련이 없지만 매우 유용합니다.

또한 단일 이름 바꾸기 작업으로 그룹 이름을 바꾸는 것을 좋아합니다.

이것은 거대한 각도 앱 작업을 시작할 때 매우 중요해지고 있습니다. vscode를 가져오는 것을 고려하십시오. 이미 있는 경우와 그렇지 않은 경우 파일 중첩에 대한 유사한 경험을 가져오십시오.

이봐, 이것은 내가 작업하고 있는 Angular 응용 프로그램을 훨씬 덜 복잡하고 둔하게 만들 것입니다. 나는 여러분이 이것을 진지하게 고려하기를 진심으로 바랍니다.

다른 호에서 말했듯이 ..

내가 이것을 원하는 가장 큰 이유는 비슷한 이름의 파일이 많이 있는 각도 때문입니다.

/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

그것들을 중첩할 수 있다면 정말 좋을 것입니다.

나는 또한 명령/중개자 패턴을 수행하므로 다음과 같은 파일로 끝납니다.

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

그것은 꽤 장황해지며 이 기능은 내 하루를 만들 것입니다.

이것이 내가 여전히 WebStorm을 사용하는 유일한 이유입니다...

예, 우리도 마찬가지입니다.

2017년 6월 2일 오전 10시 10분에 MigFerreira [email protected]에서 다음과 같이 썼습니다.

이것이 내가 여전히 WebStorm을 사용하는 유일한 이유입니다...

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

멍청한 질문: 누군가 스크린샷이 어떻게 보이는지 제공할 수 있습니까? 그 뒤에 숨겨진 의미가 무엇인지 상상할 수 없습니다.

아, 알겠습니다. 감사합니다.

이것은 이제 우리에게 가장 큰 누락 기능이 되었습니다. 이 기능이 없어서 사용하지 않을 동료가 있습니다. 많은 파일이 비슷한 이름을 가지고 있을 때 하나의 특정 파일을 찾으려고 할 때 정말 고통스럽습니다. 각 구성 요소(Angular)에 대해 더 많은 하위 폴더를 추가하려고 시도했지만 이상적인 솔루션이 아니며 기능(및 하위 기능) 폴더 아래에 모든 구성 요소를 나열하는 것으로 되돌아갔습니다.

저는 TypeScript와 Angular를 대규모 Dojo 프로젝트에 도입하고 있으며 이 기능이 앞으로 몇 달 안에 우리 팀의 VSCode 사용자에게 매우 중요해질 것이라고 말할 수 있습니다.

저는 현재 Angular 프로젝트에서 작업 중이며 관련 파일을 그룹화할 수 있다는 것은 이미 우수한 제품에 훌륭한 추가 기능이 될 것입니다. Angular 프로젝트가 성장함에 따라 탐색이 더 어려워지고 현재 생산성이 저하됩니다.

#13754에서 반복:

IMO, 가장 우아한 솔루션은 프로젝트에 맡기는 것입니다. .vscode/settings.json 또는 project.json . 파일 제외 구문과 같은 것을 사용하십시오. 이를 통해 프로젝트별 또는 폴더별 사용자 정의가 가능합니다. 프레임워크/도구 유지 관리자, VSCode 또는 타사는 지정된 워크플로에 대한 패턴 집합을 배포할 수 있습니다.

이런 식으로 VSCode는 아무 것도 가정하지 않으며 아무에게도 문제를 일으키지 않습니다. 중첩할 수 있는 후보를 감지하고 "중첩해야 할 파일이 있는 것 같습니다. 이러한 기본 중첩 프로필 중 하나를 적용하시겠습니까?"라는 경고를 표시할 수 있습니다.

개발자가 논리적 중첩을 원한다면 그렇게 할 수 있습니다. 그들이 원하지 않으면 설정을 추가하지 않을 뿐입니다.

캡처를 들어 my-component.A.B 에서 my-component.ts (AngularJS와 2)

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

캡처를 들어 my-component.dev.ts 에서 my-component.ts :

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

또는 생성된 파일의 경우( 파일이 dist/ 로 생성되는 Aurelia 탐색 골격 사용):

// 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)"}
}

이와 같이 잘 정의된 구문을 사용하면 과도하게 복잡하지 않은 한 원하는 중첩 체계를 추가할 수 있습니다. 마지막 예제는 gulp의 경로 처리를 기반으로 합니다( $(path) = 첫 번째 glob으로 시작하는 경로).

이것이 고려되는지 여부에 대한 정보나 피드백을 원합니다. 현재로서는 포함된 기능이 될 때까지 Angular 또는 Aurelia 개발에 VS Code를 사용하지 않을 것입니다.

@threedaysmore VSCode 팀이 실제로 이를 고려하고 있다는 표시는 없습니다(백로그 끝까지 떨어졌습니다). PR #13754에서 이 문제를 해결했지만 @playerx 가 적어도 일시적으로 삭제한 것처럼 보입니다.

더 최신 PR: #32061을 만들었습니다. 일부 항목(즉, 트리 모델)을 처리하는 데 버그가 있어 도움을 찾고 있습니다.

+1

+1

+1

이 기능에 관심이 있다는 것을 어떻게 보여줄지 모르겠습니다. +1, 스레드를 스팸으로 처리하기 때문에 그다지 좋은 방법은 아닌 것 같습니다(사람들이 엄지손가락을 아래로 떨어뜨림). 단순히 내 관심을 표시하기 위해 github 문제에 +1 또는 "이 기능을 사용하고 싶습니다"를 제공하는 권장 방법은 무엇입니까?

이 기능의 중요성을 표시/증가하려면 첫 번째 작성자의 의견에 엄지손가락을 추가하세요.

@bpasero가 내 pull request #32061을 닫았습니다. "PR에 감사하지만 이 넓은 지역에 대해서는 수락하지 않습니다." (물론 내 풀 리퀘스트는 아주 초보적인 것이었다.)

유지 관리자나 다른 사람이 이에 대해 확장할 수 있습니까? 또는 이것이 pull 요청 또는 확장으로 구현될 수 있는 방법에 대한 지침을 제공하시겠습니까?

@firelizzard18 저는 이 기능을 정말 원했고, 그 작업에 시간을 투자했고 동일한 피드백을 받았습니다. 그들이 이 기능을 원하지 않는 데에는 이유가 있다고 생각하지만 그들은 우리에게 말하지 않습니다. :)

@bpasero
나는 이 기능이 당신(기고자로부터), 어떻게 할 수 있는지, 그리고 당신이 볼 수 있듯이 그것을 실현하기 위해 시간을 할애할 수 있는 사람들로부터 더 많은 지침을 받을 가치가 있다고 생각합니다.

VS Code에도 파일 중첩이 있으면 좋을 것입니다.
최근에 더 나은 Angular 지원/통합으로 인해 내 ASP.NET Core 앱에 대한 Angular/프론트엔드 프로그래밍을 위해 VS 2017에서 VS Code로 변경했습니다. 훨씬 잘 작동하지만 파일 중첩이 정말 어렵습니다. :-(

VS Code에 파일 중첩 기능을 추가하거나 다른 사람들에게 확장 기능을 개발할 수 있는 기회를 주세요!

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

@bpasero 팀에서 이에 대한 업데이트를 받을 수 있는지 궁금합니다. 몇 년 동안 여러 사람들의 많은 활동이 있었습니다. 문을 닫았다가 다시 열었고 최소한의 지시로 여러 구현이 거부되었습니다. 이것이 여전히 원하는 기능입니까?

React 및 TypeScript 커뮤니티에 대한 강력한 사용 사례가 있으며 개발자 감정은 일관되게 긍정적이었습니다(개인적으로도 긍정하고 싶습니다). 다시 한 번 감사합니다

@developer 나는 그들이 그들의 기대치를 꽤 명확하게 했다고 생각합니다. 그들은 완전히 사용자 정의가 가능하기를 원합니다. 파일 탐색기를 완전히 제어할 수 없는 모든 것을 허용하는 것은 의미가 없습니다. 까다로운 부분은 IDE의 구조가 물리적 구조와 완전히 다를 수 있는 동안 파일 생성/이동을 허용해야 한다는 것입니다. 또한 나는 그들이 여러 보기 사이를 전환할 수 있기를 기대한다고 생각합니다(예: 파일 컨텍스트와 단위 테스트 컨텍스트를 가질 수 있습니다. 하나에서 테스트를 작성한 다음 이를 만족시키기 위해 다른 것으로 전환).

나는 그들이 사용 사례를 알고 있다고 확신하지만 로드맵을 보면 그들의 계획이 이 계획보다 훨씬 야심차고 유용하다는 것을 알 수 있습니다. 그래서 그들이 커뮤니티를 위해 이것을 남겨두기로 결정한 이유입니다. .

Micro$oft의 멋진 경력 기회는 용감한 사람을 기다리고 있습니다.

"Micro$oft" LUL - 경험이 제한된 십대 초반이 이 스레드를 팔로우하고 있다는 사실에 놀랐습니다.

_Anyway_, @develleoper - 최근 Microsoft는 확장 프로그램 제작자가 측면에 자체 패널을 추가할 수 있는 기능을 추가했습니다. 따라서 곧 출시될 때 일부 확장 프로그램 제작자는 아마도 물리적 파일 대신 논리적 파일 트리를 표시하는 확장 프로그램을 만들 것입니다. .

@waynebloss IMO, 이 기능을 새 패널이 필요한 잠재적 확장으로 남겨두어서는 안 됩니다. 이 접근 방식을 사용하려면 현재 기능이 모두 포함된 파일 트리를 다시 구현해야 할 뿐만 아니라 추가되는 향후 기능으로 파일 트리를 업데이트해야 합니다. 예, 현재 파일 트리 코드를 확장자로 분기할 수 있지만 그렇다고 해서 향후 기능 업데이트를 추적하는 유지 관리 부담이 줄어들지는 않습니다.

최소한 파일 트리 자체는 이를 구현하기에 충분한 확장성 포인트를 부여할 수 있습니다. (이 기능을 추가하고 확장 기능을 구축하여 이 기능을 활용하는 것은 어쨌든 초기 작업이 덜할 것입니다.)

@RoyTinker가 동의했습니다. 파일 중첩이 공식적으로 지원될 때까지는 새 패널이 해결 방법일 뿐이라고 생각했습니다.

@Wayofsin 나는 당신이 무엇을 얻으려고하는지 전혀 확신하지 못합니다. 커뮤니티에서 이 기능을 원하는지 여부를 심각하게 의심하는 사람은 없다고 생각합니다. 그리고 역사를 실제로 읽어보면 커뮤니티가 이를 구현하려고 시도했고 개발자가 "아니오"라고 말했습니다. @playerx 는 풀 리퀘스트를 했고 "아니오"라고 대답했습니다. 나는 그의 풀 리퀘스트를 포크하고 그 시점에서 최신 마스터 브랜치에 병합하고 약간의 수정을 가하고 제출했습니다. 그리고 "아니오"라고 말했습니다.

따라서 커뮤니티가 이것을 원하고 개발자는 커뮤니티 기여를 수락하는 데 관심이 없다는 것이 분명해야 합니다.

@develleoper 및 다른 사람은 생각 @bpasero '에 대한 님의 댓글 @playerx의 PR 우리에게 VSCode 팀이 함께 가고 싶은 장소에 대한 많은 이야기 : https://github.com/Microsoft/vscode/pull/13754를

그의 의견에서 나는 @bpasero를 이해합니다.

• 일종의 논리적인 관점을 원하는 모든 그룹을 수용할 수 있는 포괄적인 접근 방식을 원함
• 파일 중첩을 논리적 보기(물리적 파일 시스템 보기와 반대)로 생각합니다.
• 논리적 보기는 물리적인 파일 시스템 보기와 분리되어야 한다고 생각합니다.

제 생각에는 파일 중첩이 논리적 보기 변경 _이기는 하지만 파일 숨기기도 마찬가지이며 현재 파일 트리에서 지원되며 설정을 통해 구성할 수 있습니다. 내 생각에 파일 중첩은 파일을 표시하는 방법을 제공한다는 점을 제외하고는 파일 숨기기의 또 다른 형태일 뿐입니다.

제쳐두고, Atom은 이제 트리 보기 패키지를 통해 파일 중첩을 지원합니다. https://github.com/atom/tree-view/issues/572 참조

@firelizzard18 귀하의 풀 리퀘스트를 보았습니다. 제 생각을 댓글로 달았습니다. #32061.

@RoyTinker 는 그들이 기대하는 @bpasero의 첫 번째 기대조차 충족되지 않았습니다.

VS와 별개로 우리 자신의 프로젝트는 생성된 모든 MAP 및 JS 파일을 TS 파일과 같은 수준이 아닌 out 폴더에 넣고 있으며 동일한 작업을 수행하는 다른 프로젝트가 있다고 확신합니다. 내 요점은 동일한 수준에 있을 때 수행하는 것과 동일한 방식으로 해당 파일을 TS 파일 아래에 중첩할 것으로 예상한다는 것입니다.

추가로 덧붙이자면 가상 탐색기를 파일 탐색기로 생각하지 마십시오. 누군가 내보낸 개체를 typescript 파일 아래에 중첩하고 싶을 수 있습니다.

나는 그들이 PR을 수락하지 않은 이유라고 생각합니다. 그들은 기존 코드에 대한 패치에 관심이 없습니다. 그들은 구성할 수 있을 뿐만 아니라 확장 가능한 유연한 솔루션을 찾고 있습니다. 그들은 스스로에 대해 아무 생각이 없는 것처럼 보이지만 그들이 원하지 않는 것이 무엇인지는 거의 알고 있습니다.

내가 보는 문제는 그들이 PR을 수락하지 않는 이유를 추측하려고 시도하고 명확한 답변과 지침이 없다는 것입니다. 여러분이 작성한 모든 의견은 @bpasero 가 그것에 대해 생각하는 귀하의 해석입니다.

너무 많은 대화와 기여자들의 침묵이 제품 자체에 좋지 않다고 생각합니다.

@Wayofthesin , @playerx 는 머리를 못 박았습니다: 우리는 @bpasero 가 우리가 제공하는 것보다 더 많은 것을 @bpasero 는 어디로 이동해야 하는지 명확히 하기에 충분한 피드백을 제공하지 못했습니다. 제 경우에는 @bpasero 가 매우 모호한 코멘트로 제 PR을 마감했습니다. @playerx 의 경우 @bpasero 는 "현재 게임 종료 단계에 있으며 다음 달에만 돌아올 수 있습니다."라고 댓글을

내 PR은 진행중인 작업이었습니다. 앞으로 나아가는 방법에 대한 개발자의 지침을 원했습니다. 대신 나는 비밀스러운 응답을 받았고 내 PR이 닫혔습니다.

내 PR 검토에서 참조한 @playerx 접근 방식의 일반성(부족)과 관련된 @bpasero 문제를 해결하기 위한 계획을 제안했습니다. 제 PR에서 저는 이 모든 것이 아니라 일부를 구현하는 작업을 시작했습니다. 저는 매우 생소한 영역에 있었고 앞으로 나아가기 전에 지침을 원했기 때문입니다.

농담이야. 분위기를 조금 높이고 싶었다. 이에 대해 조사해 주십시오. 이런 종류의 프로젝트 보기로 작업하는 것은 정말 어렵습니다. 어렵지는 않지만 비효율적입니다.

+1, 동의합니다. 이 기능은 위챗 미니 앱 개발에도 매우 유용합니다.

하기가 너무 어렵나요? 약 200만 Java 커뮤니티 회원에게 가능한 한 빨리 이 기능이 필요합니다. 제발....!!!

VS Code는 트리 보기에서 가상 파일 중첩을 지원하는 것 같습니다. 버전 1.29의 변경 로그에는 다음 사항이 포함되었습니다.

이것은 파일 그룹화의 기반이 만들어졌음을 나타내는 것 같습니다.

@MortenChristiansen 음... 같은 기능이 아닌 것 같습니다'

제안 사항으로 Visual Studio 2017에는 .filenesting.json 구성 파일을 통한 파일 중첩 기능이 있습니다. 아마도 구성 파일과 관련하여 비슷한 것이 VSCode에 대해 구현될 수 있습니다.

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

예로서:

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

범프 🏗

다트에서 자동 생성된 파일에도 좋습니다.

이는 Salesforce 확장에도 도움이 됩니다. 우리 프로젝트에는 모든 코드 파일과 연결된 *.meta.xml 파일이 있으므로 효과적으로 파일 트리 길이를 두 배로 만듭니다. 해당 메타데이터 파일을 소스 파일 아래에 넣고 싶습니다.

중첩 기능에 대한 사용자의 요구 사항/요구 사항을 수집하는 것이 문제라고 생각하지 않습니다.
나는 그것을 구현하는 것이 문제라고 생각하지 않습니다. 일부 기부가 공식 릴리스에서 더 빠르게 구현하는 데 도움이 될까요?

내 파일을 보고,
Typescript, 웹 및 스타일이 높이 쌓여 있습니다.
중첩이 좋을 것입니다.

죄송합니다. 그들은 이것에 전혀 관심이 없는 것 같습니다.

아저씨, 이것도 보고 싶어요.

기괴함 - 이 기능의 동작은 매우 잘 정의되어 있으며 분명히 많이 필요합니다.

+1 얘들아

이것은 발생하지 않으므로 문제를 닫을 것입니다.

@isidorn 은 그들이 그것에 관심이 없고 하려고 하지 않는다는 것을 분명히 했습니다. 불행한 일입니다. 이것이 내가 지금 VSC를 사용하는 것을 막는 전부입니다. Angular 응용 프로그램은 파일 중첩 없이 너무 장황하고 지저분합니다.

지금은 여전히 ​​WebStorm에 갇혀 있는 것 같습니다.

가까운 시일 내에 이 문제를 해결할 수 있도록 이 문제를 열린 상태로 유지하는 것이 좋습니다.

@isidorn , "그렇지 않은 미래"가 주어지면 이것이 어떻게 구현되어야 하는지에 대한 지침을 제공할 수 있습니까? 나는 그것을 찔러보고 싶지만 내 MR에 대한 피드백이 전혀 없습니다.

2019년, 새로운 소식이 있나요?

자바 개발자로서 이것이 내가 vscode로 완전히 마이그레이션하는 것을 막는 주요 원인입니다.

내 Java 프로젝트에서 Java 패키지 네임스페이스의 빈 디렉토리는 탐색기에서 사용 가능한 공간의 절반(또는 그 이상)을 차지합니다. 각 개발 반복에 대해 여러 번 수행해야 할 때 시간이 많이 걸리는 일종의 탐색기에서 항상 위/아래로 스크롤해야 합니다. Java 개발을 위한 많은 IDE는 이러한 빈 디렉토리를 단일 패키지 이름으로 축소하여 개발자가 전체 패키지 구조를 쉽게 볼 수 있도록 합니다.

이것은 vscode에서 구현하는 것이 가능하지만 다른 더 높은 우선순위 작업으로 인해 우선순위가 지정되지 않는 것입니까? 아니면 기본 vscode 아키텍처의 제한으로 인해 구현할 수 없습니까?

이 작업을 수행할 확장 프로그램이 있습니까? 정말 필요한 기능입니다!

오픈한지 3년이 넘었는데.. 안할듯... 지금 웹스톰 설치중...

이것이 해결될 것이라고 생각하는 아주 기본적인 사항을 붙여넣음으로써 들여쓰기를 하면 프리웨어와 오픈 소스에서 얻을 수 있는 것입니다. 별로... 게임에 스킨이 없기 때문에.

예 - 그렇지 않으면 우수한 개발 팀의 매우 실망스러운 응답(또는 부족)입니다.

사용자 지정 중첩을 만들었지만 끌어오기 요청이 병합되지 않습니다. VS 코드 팀에는 다른 계획이 있으며 코드의 해당 부분을 변경하고 싶지 않습니다. 나에게 이 기능은 중요하므로 사용자 지정 Vs Code 빌드(확장 저장소 작동)를 만들었습니다. 시도해 볼 수 있습니다. https://github.com/floatas/vscode/releases/tag/1.37 진행 상황을 볼 것입니다. 문제, VsCodium(업데이터로 자동 빌드)과 비슷한 것을 만드는 것을 고려하고 있지만 변경 사항이 있습니다.

이 구성을 settings.json에 추가하기만 하면 됩니다.

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

중첩을 활성화할 때 대 코드 다시 시작이 필요합니다.

@floatas 코드 감사합니다! 확장 프로그램을 만드는 것에 대해 어떻게 생각하세요?

@e-belair 슬프게도 확장을 만들 수 없습니다. 이 기능에 대한 API를 사용할 수 없습니다.

파일 중첩 기능은 정말 달콤할 것입니다! 이것이 일어나기를 바랍니다 :)

@floatas PR은 어디에 있습니까?

@tariqporter # 72160

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

VS 코드 팀에는 다른 계획이 있으며 코드의 해당 부분을 변경하고 싶지 않습니다.

그것은 #41627이 될 것이며, 이것은 트리뷰 재작성의 일부로 먼저 작업될 것이며, 아마도 나중에 이것을 더 쉽게 구현할 수 있을 것입니다.

VS Code는 훌륭하다고 생각하지만 이것이 부족한 기본적인 기능입니다.

그것도 기대된다

난 그게 필요해

이에 대한 업데이트가 있는지 궁금하십니까? 트리 뷰를 청소해야 하는 것이 좋을 것입니다!

Blazor 앱에서 이 기능 때문에 여전히 Mac용 VS를 사용하고 있습니다. 왜 그렇게 팀의 저항이 많습니까?

이를 통해 이를 가능하게 하는 데 필요한 확장 API의 구현을 추적하는 데 문제가 있습니까?

4년이 지난 지금 이 문제에 진전이 없습니까? 오오..
이건 솔직히 기가막힙니다...

내가 사용한 IDE 중 어떤 식으로든 이를 지원하지 않는 IDE가 생각나지 않으며, 내가 작업한 플랫폼에서 이것이 유용하지 않은 프로젝트에 대해서도 생각할 수 없습니다... oO.. 이것은 내가 어떤 IDE에서나 주어진 것이라고 가정한 시점까지입니다... 추측컨데...

팀이 사람들을 경쟁자들에게 밀어붙이려고 하는 걸까요?...
WebStorm을 VSCode로 교체하고 싶었지만 그런 일은 일어나지 않는 것 같습니다. 그리고 우리는 VS나 IDEA를 대체할 수 있는 곳이 없습니다.:S...

아 글쎄...

@jeme 개발자를 괴롭히는 것이 어떤 영향을 미칠 것이라고 상상하십니까? 내가 관리자라면 반대 의견을 절대적으로 무시할 것임을 압니다. 실제로 해충이 아니라 건설적인 것을 원하면 "이 기능은 나에게 매우 중요하며 이 도구를 채택하지 못하게 합니다."를 시도하십시오.

@firelizzard18 그러면 고객 기반을 제공하는 데 꼭 필요한 것을 놓치게 될 것입니다. 모든 고객의 말에 귀를 기울이는 법을 배우는 것은 말하자면 먹잇감 위에 올라서는 진정한 훌륭한 자질입니다. 여기 댓글을 읽어보면 당신이 말하는 방식으로 행동하는 사람들이 많이 있습니다. 그러나 그들은 듣지 않고 4년 후에 특히 누군가가 진정으로 전환하기를 원하지만 프로젝트가 너무 커서 파일을 함께 중첩할 수 없기 때문에 방법을 볼 수 없는 경우 좌절감이 극에 달하게 될 것입니다. 나는 진정으로 비주얼 코드가 프리웨어이며 아무도 이것을 진정으로 우선 순위로 삼는 데 신경 쓰지 않는다고 믿습니다. 그리고 그것이 우리 사용자들이 요구하는 무료 소프트웨어에 대해 얻는 것입니다. 게임에는 아무것도 할 수 있는 스킨이 없습니다. 이와 같은 일이 제자리에 놓일 것을 의미하는 경우 IDE에 비용을 지불합니다. 다시 웹스톰을 사용하고 있습니다(비용을 지불했습니다). 그들은 정말로 그냥 나와서 우리가 그렇게 하지 않을 것이라고 말해야 하므로 티켓을 닫고 끝내야 합니다.

여기 댓글을 읽어보면 당신이 말하는 방식으로 행동하는 사람들이 많이 있습니다.

그리고 적대적인 것이 상황을 바꿀 것이라고 생각합니까?

내가 말하고자 하는 바는 훌륭한 사업가는 메시지가 어떻게 전달되는지는 신경 쓰지 않는다는 것입니다. 따라서 이러한 의견을 무시한다면 좋은 사업가가 될 수 없습니다. 기술 회사의 고객 지원 라인에서 일한 적이 있다면 이것을 이해할 것입니다.

마지막으로, 제 전체적인 결말은, 어느 쪽이든 좋든 좋지 않든(당신이 강의하는 논평에 의해) 그것이 중요하지 않다고 말하고 있다면 그들은 그것을 하지 않을 것입니다. 프리웨어인 게임에 스킨이 없습니다. 정말 논쟁의 여지가 있으며 티켓을 닫아야합니다.

이 문제가 아직 해결되지 않은 이유에 대해 불평하기보다 가능한 솔루션과 통찰력에 대한 의견 섹션에 집중할 수 있습니까? 이 문제의 영향을 전달하는 방법 은 문제 설명에 대한 투표를 사용하는 것입니다.

감사합니다

이에 대한 공개 PR이 있습니다(#13754)...
누군가 공식적으로 포크를 선언하고 Windows Apple 및 Linux용 바이너리가 포함된 기본 정적 사이트를 설정한다면... 아마도 1000명의 앵귤러 개발자 몇 명이 밤새 그곳에 뛰어들 것이고 어딘가에 약간의 기부 버튼이 있다면 돈을 벌 수도 있을 것입니다 노력을 위해.
지금은 개인적으로 이 기능이 필요하지 않지만 VSCode는 MIT 라이선스 하에 있고 커뮤니티는 이 기능을 정말로 원하며 커뮤니티의 일부 구성원은 이 기능을 구현하기 위해 정말 열심히 일했습니다.
그래서...

아마도 그들은 #75181도 고칠 수 있을 것입니다! 단순히 탐색기 패널을 표시해도 파일 탭이 열리지 않아야 합니다.

@BrunnerLivio 당신은 너무 웃긴 불평에 대해 불평합니다 ;). 이것은 누군가가 자신의 불만, 필요 또는 투표를 전달하는 방법에 대해 다른 사람에게 자신의 도덕적 행동을 수정하거나 강요하기를 원했기 때문에 시작되었습니다. 당신도 똑같이하고 있습니다. 다시 말하지만, 이 문제는 아무데도 가지 않는 프리웨어입니다. 4년이 안되었습니다. 모두가 "그들"에 대해 이야기하고 있습니다. 이것은 프리웨어입니다. 그들은 이 포럼의 사람들입니다. 제가 약 1년 전에 깨달았던 것입니다. 그리고 저는 이 기능을 향상시킬 시간이 없을 정도로 일을 많이 했고, 웹스톰으로 하는 IDE에 비용을 지불하고 싶습니다.

개인적으로 있으면 좋을 것 같지만 귀찮게 하지는 않을 것 같아요.
기본적으로 무료라는 것을 알고 있기 때문에 누군가 서비스 수준 계약을 유지하거나 지원을 위해 돈을 지불하는 것과는 다릅니다. "고객"이라는 단어는 구매한 제품을 의미하기 때문에

그래서 대안은

1. 소스를 포크하고, 기능을 추가하고, 풀 리퀘스트를 발행한 다음, 포함하도록 요청하는 사람
2. 다른 옵션으로 중첩이 있기 때문에 무료(오픈 소스는 아님)인 Visual Studio 2019 Community를 사용해 보십시오.
3. 에 추가될 때까지 다른 것을 사용하십시오.

내가 생각하는 또 다른 대안:

자체 사이드바 버튼과 패널이 있는 Explorer 트리를 모방하는 확장 프로그램을 빌드하고 사용하세요.

그리고 나는 그렇게 했다.

pt., 7.02.2020, 02:15 użytkownik Hecatron [email protected]
나피사우:

개인적으로 있으면 좋을 것 같지만 누구에게나 방해가 되지는 않을 것 같아요
그 위에
기본적으로 무료라는 것을 알고 있기 때문에 누군가가 그것을 들고 있는 것 같지 않습니다.
서비스 수준 계약에 따르거나 지원 비용을 지불합니다. 단어부터
"고객"은 구매한 제품을 의미합니다.

그래서 대안은

1. 누군가가 소스를 포크하고, 기능을 추가하고, 풀을 발행합니다.
   요청한 다음 포함하도록 요청하십시오.
2. 다른 옵션으로 Visual Studio 2019 Community를 사용해 보십시오.
   또한 중첩이 있기 때문에 무료(오픈 소스는 아님)
3. 에 추가될 때까지 다른 것을 사용하십시오.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/vscode/issues/6328?email_source=notifications&email_token=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LDNMVX
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ACJ4R3YUKMXFVOO5NSXSQ6DRBSY3TANCNFSM4CDVJHVQ
.

이것의 약간의 진보 !! vscode에서 꼭 필요한 것 같아요!!

VS Code는 무료 제품이고 Visual Studio 정식 버전은 유료 제품입니다.

@GeorgeTarazi 귀하의 의견에 따르면 VSCode를 사용한 적이 없거나 Visual Studio를 사용한 적이 없다고 가정하겠습니다. 둘 다 사용해보시면 전혀 다른 제품이라는 것을 아실 수 있기 때문입니다. Visual Studio는 VSCode의 '정식 버전'이 아닙니다.

아무도 주제에서 벗어난 의견에 대한 알림을 받고 싶어하지 않습니다. 아마도 저장소 관리자는 지금 이 문제에 대한 논의를 잠그는 것을 고려해야 합니다.

개인적으로 Visual Studio 2019 Community(무료) 에디션이 필요한 모든 작업을 수행하기에 충분하다는 것을 알았습니다.
과거의 이전 Pro/Enterprise 버전과 비교합니다.
예를 들어 Java에 대한 오픈 소스 대안으로 dotnet을 푸시하려는 MS의 관점에서 볼 때 이것은 의미가 있습니다.
비즈니스 관점에서 Studio 2019를 사용하려면 여전히 라이선스가 필요할 것입니다.

다른 사용 사례에 대해 Studio 2019와 VSCode를 모두 사용합니다. 내가 선호하는 VScode python, Studio 2019 나는 dotnet을 선호합니다.
오픈 소스 등을 작업하는 경우 VSCode
컴파일러는 별도의 외부 도구 btw이기 때문에 적어도 dotnet에서는 공유되지 않습니다.
또한 둘 다 다른 언어로 작성되었습니다. VSCode - Javascript, Studio 2019는 아마도 C#과 CPP의 조합일 것입니다.

기능이 아직 포팅되지 않은 이유는 ether 때문인 것 같습니다.

1. 그들은 먼저 필요한 확장 또는 종속성과 관련된 것과 같은 다른 기능을 먼저 구현하는 것을 목표로 하고 있습니다.
2. 다른 팀, 다른 수준의 리소스
3. 처음부터 작성해야 하며 다른 언어 간에 붙여넣기를 복사할 수 없습니다.

@georgebatalinski 나는 당신이 말하는 대부분에 동의합니다. 그러나 Visual Studio보다 Angular에 더 유용한 시각적 코드를 발견했다고 말할 수 있습니다. 특히 프론트 엔드 스파에 대해 더 개발자 친화적인 방식으로 진행되었습니다. 저는 90년대부터 VS 제품을 사용해 왔기 때문에 아마도 당신보다 나이가 많을 것입니다.) Qbasic도 vb 시절로 거슬러 올라갑니다. 나는 개인적으로 me me me 것에 질렸어, 나에게 그것을 무료로 줘. 특히 이 추가 기능을 얻기 위해 시각적 코드 비용을 지불하게 되어 기쁩니다. 하지만 이 기능이 내 눈에 더 큰 앱에 필요하다고 생각하기 때문에 다시 VC를 사용하지 않습니다.

이 기능이 구현됩니까?
웹 프로젝트로 작업할 때 작업 공간을 어지럽히는 생성된 파일이 많기 때문에 매우 유용합니다(그러나 때때로 파일을 확인해야 하므로 숨기는 것이 해결책이 아닙니다).

비활성화/활성화 선택을 사용자에게 맡기고 어떤 확장이 이를 트리거할지 선택하지 않는 이유는 무엇입니까? :-)
구현이 너무 간단해 보이는데....

@funder7 조만간. 개발자들은 VS Code가 어떻게 작동해야 하는지에 대해 서로 다른 이데올로기적 견해를 가지고 있다고 밝혔으므로 이것이 우선순위가 아닙니다.

@tmarkovski 감사합니다. 지금 생성된 파일을 제거하는 데 사용하고 있습니다. rm -f *.js *.map ... 그런데 IntelliJ Idea에서 해당 기능을 발견했는데 복잡한 프로젝트를 작업할 때 매우 편리합니다.
그것이 개발자가 앱을 보는 방식이 아닌 경우 최소한 기본적으로 비활성화된 상태로 유지하지만 활성화 옵션은 최종 사용자에게 남겨둡니다.
내가 Idea를 언급한 이유는 이러한 종류의 기능이 보조 소프트웨어와 즐겨 사용하는 소프트웨어의 차이를 만드는 것이기 때문입니다.

사실 나는 이것이

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

생성된 파일을 숨기지만 파일이 사라지고 존재를 눈치채지 못합니다./

4년이 넘는 시간이 흘렀습니다. 소프트웨어 세계에서는 영원할 것입니다. 아직 구현할 계획이 없습니까? 이것은 거대한 파일 트리 구조를 스캔할 때 정신적 부하를 줄여 생산성에 매우 중요합니다. 탐색기에 추가 파일이 표시되는 부담 없이 별도의 Typescript 인터페이스 파일을 허용합니다.

이 기능에 대한 진행 상황이 있습니까?

이 기능에 대한 진행 상황이 있습니까?

중복 문제는 지난 주 vscode 팀원에 의해 해결되었으므로 그들은 그것을 알고 있지만 무시하기로 선택했습니다.
이유를 알아보기 위해 정말 고군분투합니다.

이유를 알아보기 위해 정말 고군분투합니다.

그들에게는 그것이 우선순위가 아니기 때문입니다. 팀으로서 그들은 다른 것들을 우선시하기로 결정했습니다. 당신은 그들의 결정에 동의하지 않을 수 있지만, 이 모든 "OMG 와우~ " 징징거리는 것은 불쾌하고 무의미합니다.

그들에게는 그것이 우선순위가 아니기 때문입니다. 팀으로서 그들은 다른 것들을 우선시하기로 결정했습니다. 당신은 그들의 결정에 동의하지 않을 수 있지만, 이 모든 "OMG _whhhhhy_" 징징거림은 불쾌하고 무의미합니다.

나에게 개발자가 다른 개발자가 자신의 코드를 작성하는 방법을 결정하는 것은 무의미합니다. 그렇기 때문에 애플리케이션에는 일반적으로 환경을 원하는 대로 설정할 수 있는 "기본 설정" 보기가 있습니다. 우리는 작업 목적으로 하루 종일 사용되는 도구에 대해 이야기하고 있기 때문에 파일 목록을 더 읽기 쉽게 만드는 기능을 요청하는 것이 어리석은 것처럼 보이지 않습니다.

기능을 요구하는 사용자는 VSCode가 개선되는 방식이며, 아마도 충분한 사람들이 이 기능을 요청하면 실제로 일어날 것입니다. 그러나 불평하는 것은 무의미합니다.

큰 작업 공간을 위한 기능이 있어야 합니다.

나는 최근에 이것을 다시 살펴보고 있는데, 내가 수집할 수 있는 것에서 과거에는 그리 멀리 가지 않은 몇 가지 pull 요청이 있었습니다.

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

하지만 여기에서 본 것을 기반으로 이것을 확장으로 구현하는 것이 가능해야 한다고 생각하기 시작했습니다.

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

vscode에서 다른 확장 기능을 살펴보았지만 아무 것도 찾지 못했습니다.
기본 파일 탐색기 창과 동일한 것을 표시할 수 있지만 중첩이 추가된 확장을 작성하는 사람이 필요하다고 생각합니다. 이상적으로는 Visual Studio 2019에서 이미 사용 중인 .filenesting.json 파일 읽기를 지원합니다 암호)

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

javascript는 제 모국어가 아니므로 스스로 무언가를 할 수 있을지 확신할 수 없습니다.
이 작업을 수행하기 위해 노출된 확장 API가 충분하다고 생각하지만 적어도 왼쪽의 별도 탐색기 탭에서는

@grbd 님 안녕하세요, 저는 이 개발을 위한 "후크"가 파일 탐색기가 폴더를 처리하는 지점이 될 것이라고 생각합니다. 이는 중첩된 파일이 표시되는 방식을 보여줍니다. 그런 다음 이 동작은 디렉터리가 아닌 파일로 확장되어야 합니다.
새 표시 모드에 포함되어야 하는 파일 확장자를 알려주는 설정을 추가하는 것이 좋습니다.
저는 vscode용으로 아무것도 개발한 적이 없기 때문에 다른 정보를 드릴 수는 없습니다... 확장 기능을 개발하는 것은 좋은 생각인 것 같습니다. 잘 사용하고 테스트한 후에는 아마도 메인 애플리케이션 소스 코드로 옮겨질 것입니다.

시작점으로 나는 아마도 vscode-solution-explorer를 보고 복사/붙여넣기 할 것입니다.
기본 파일 탐색기와 유사한 하위 디렉토리에 파일을 표시하는 것과 유사한 작업을 이미 수행하고 있기 때문입니다.
차이점은 파일 중첩을 수행하는 대신 VStudio 2019의 보기를 에뮬레이트하는 것입니다.

어떤 파일 확장자를 포함해야 하는지 알려주는 설정은 위에서 언급한 .filenesting.json 또는 기타 json 관련 파일과 같습니다.

이유를 알아보기 위해 정말 고군분투합니다.

그들에게는 그것이 우선순위가 아니기 때문입니다. 팀으로서 그들은 다른 것들을 우선시하기로 결정했습니다. 당신은 그들의 결정에 동의하지 않을 수 있지만, 이 모든 "OMG _whhhhhy_" 징징거림은 불쾌하고 무의미합니다.

당신은 _기능 요청_ 문제에 있다는 것을 알고 있습니까? 당신은 다른 어느 곳에서나 옳았을 것이지만 이것은 요청하고 이야기하기에 _실제_올바른 장소입니다(무의미한 징징거림이 아닙니다). 사람들이 행복하고 그것을 필요로 하지 않는다고 생각한다면 결코 우선 순위가 아닙니다.

왜 "가상 폴더"가 필요한지 설명하겠습니다. 저는 makefile을 통해 구성된 C 코드베이스로 작업하고 있는데, 변경할 위험이 없습니다. 그러나 코드는 엉망이고 동일한 문제로 유지해야 할 다른 코드베이스가 있습니다.

제 정신을 유지하기 위해 가상 디렉터리에 파일을 가상으로 정렬해야 하며 코드::BLocks, Programmers Notepad(예)에서 할 수 있습니다. 하지만 VS 코드에서는 할 수 없습니다.

이것은 많은 조직에서 흔히 볼 수 있는 폴더에서 파일을 구성하는 방법을 제어할 수 없는 사람들을 위한 _반드시_입니다. 이것은 "더 이쁘게 하기"에 관한 것이 아닙니다.

결과: VS Code를 사용하면 생산성이 훨씬 떨어집니다. 사용할 수 있으면 좋겠지만 작업 흐름이 더 느릴 뿐입니다.

팀이 마음을 바꾸기를 바랍니다. 기술적으로 가능하더라도 플러그인으로 처리해야 한다고 생각하지 않습니다. 저는 이러한 핵심 요구 사항에 대해 플러그인 제공업체에 의존하고 고장날 수 있는 것에 시간을 투자하고 싶지 않습니다.

우선순위가 아니라는 점을 이해합니다. 더 많은 사용자가 VS Code를 사용하고 생산성을 높일 수 있기를 원하신다면 향후 고려하시기 바랍니다.

@grbd 도움이 되고 싶지만 시간이 많이 남아 있는지 잘 모르겠습니다.
오늘의 마스터와 일치하도록 사용자 지정 파일 중첩 포크를 업데이트했습니다. 누군가 파일 중첩으로 시작점이 필요한 경우 바이너리도 추가하여 시도해 보세요.
https://github.com/floatas/vscode