Vscode: Вложение файлов

fyi @bpasero

Самый идеальный сценарий для этого состоит в том, что все, что начинается с того же текста, что и родительский файл, за вычетом расширения, становится вложенным, как это;

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

На данный момент планов нет. Закрытие, пока мы это не рассмотрим.

Это важная особенность для больших проектов. Я использую asp.net vNext для проекта Angular, и теперь я автоматически следую структуре (по имени):

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

Создание папок для каждого компонента - плохое решение для проекта angular (вам нужно будет изменить ссылки).

Нам нужна эта функция для перехода на VS Code.

Согласитесь, хотя бы файлы ts + js + map (например, как это делает webstorm)

Было бы здорово иметь вложение файлов для стиля ts + js + map +.

В настоящее время мы скрываем файлы .js и .map, поэтому проверка их раздражает. Даже с ts + css боковая панель все еще кажется раздутой.

Согласен, я хочу, чтобы такое вложение файлов было таким (особенно для ng2)

HTML
--css
--ts
-- и т.д ...

Пожалуйста, подумайте еще раз! Это такой важный вопрос.

Существует так много случаев, когда сгенерированные файлы просто загромождают рабочее пространство. Машинопись! Машинопись, которую вы тоже используете! является ярким примером. Или LESS / SASS -> css. Или Джейд -> HTML

Есть возможность условно скрыть сгенерированные файлы. Например:

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

Тот же принцип может быть применен к вашим файлам css и map.

И я использую этот вариант. Проблема возникает, когда я хочу увидеть
скрытые файлы. Также неясно, действительно ли скрытые файлы
там (что генерация работает ...), что заставляет открыть папку
в проводнике где файлы тоже не сгруппированы ... другое дело, что
некоторым моим коллегам не нравится то, что они не видят половину файлов в
проект, и мы хотели бы использовать одни и те же настройки для всей команды.

По некоторым причинам большинство других редакторов сочли эту функцию достаточно полезной, чтобы
реализовать это, так почему бы не против кода.

Хочу отметить, что это действительно несложная функция. Я
почти уверен, что это можно сделать за день. (Я думал о том, чтобы потянуть
запрос, но это может потребовать небольших изменений в архитектуре вокруг
FileStat)

В воскресенье, 25 сентября 2016 г., Эндрю Шиэн [email protected]
написал:

Есть возможность условно скрыть сгенерированные файлы. Например:

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

Тот же принцип может быть применен к вашим файлам css и map.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на 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, если мы хотим превратить файловый проводник в логическое представление. Первоначальный PR был создан @playerx в https://github.com/Microsoft/vscode/pull/13754

Мои 2 цента на данный момент: мы должны подумать о решении для сценариев, которые хотят решить наши пользователи, и я считаю, что только поддержки отображения похожих файлов на том же уровне ниже корневого файла недостаточно. Людям может понадобиться что-то мощное в качестве обозревателя решений в VS.

@bpasero , неверен . есть два разных типа функций:

N1. Превратите файловый менеджер в логическое представление
Пример: вы можете связать файл A ("каталог X / файл A") с файлом B, который находится в каталоге Y

N2. Предоставьте поддержку файлового проводника для более элегантного отображения реальных файлов и дайте разработчикам возможность включить эту функцию, например:

Feature N1 и Feature N2 - это не одно и то же, это очень важная часть здесь, они не перекрывают друг друга.

Спасибо

@playerx Я вызвал обозреватель решений.

Независимо от VS, наш собственный проект помещает все сгенерированные файлы MAP и JS в папку out , а не на том же уровне, что и файлы TS, и я уверен, что есть другие проекты, которые делают то же самое. Я хочу сказать, что я ожидал бы вложить эти файлы в файлы TS так же, как вы это делаете, когда они находятся на одном уровне.

Для меня вложение - это не группирование файлов с одинаковым расширением вместе, а отображение файлов вместе, которые логически принадлежат друг другу (также известные как «производные ресурсы»). Имеет ли это смысл?

@playerx N2 выглядит намного лучше. Для пользователей angular 2 cli это не должно требовать этого соглашения об именах. Может быть, может быть какой-то настраиваемый шаблон, например, в конфигурации скрытых файлов.

Angular2 cli создает такие файлы:

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

@mbeckenbach хороший пример, спасибо

@bpasero вложение сгенерированных файлов под файлы TS - отличный пример, спасибо

Я хочу попросить всех, давайте приведем здесь все возможные практические примеры (пожалуйста, не теоретические), которые мы будем использовать в повседневной жизни, и давайте примем решение на основе этих примеров.

Давайте вопрос:
Как сделать проводник «умнее», чтобы визуализировать реальную картину структуры файлов более элегантно?

@bpasero в порядке? Я все еще стараюсь не смешивать Feature N1 и Feature 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. Допускает дополнительные имена файлов, например my.component.animations.ts, если команда angular когда-нибудь решит извлечь больше частей в несколько файлов.

Сценарий 1, вариант 1 ftw! +1 из-за соглашения об именах angular2

@seveves Я определенно хочу иметь эту функцию, но должен сказать, что соглашения об именах в Angular 2 просто ужасны. Поддержка этой функции не должна основываться на руководстве по произвольному стилю для конкретной платформы, которое диктует соглашения об именах, основанные на необходимости эргономики разработчика в инструментах сборки до ES Module, которые больше не имеют отношения к структуре, которая даже их использует. Я снова хочу увидеть поддержку этой функции, но я думаю, что это неправильная причина.

@aluanhaddad - чтобы не уйти слишком далеко от темы, но есть ли у вас пример лучшего соглашения об именах для 4 файлов, указанных в сценариях?

Все файлы названы одинаково вне расширения (файл + .spec), что, очевидно, не зависит от angular2. Возникает вопрос, каков приоритетный порядок расширений с одинаковыми именами файлов: которые будут считаться основными для группировки.

Я думаю, что в этом сценарии (типы на стороне клиента) приоритетом будет: TS, JS, HTML, [типы стилей]. У вас всегда будет файл TS или JS, но не обязательно шаблон или стиль.

Это было бы действительно здорово !!

@playerx прокомментировал 15

Для предложения:

N1. Превратите файловый менеджер в логическое представление
Пример: вы можете связать файл A ("directoryX / fileA") с файлом B, который находится в каталоге

Я почти уверен, что это доступно в любой текущей ОС; Windows уже поддерживает "Соединения" для нескольких выпусков, и даже теперь имеет команду MKLINK.

Учитывая это, я не вижу реальной необходимости в опции N1 и рекомендую комментарий ciel (комментарий от 13 мая 2016 г.) о вложенности на основе расширения.

Как насчет использования настраиваемого набора правил, более или менее похожего на:

"*.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 - чтобы не уйти слишком далеко от темы, но есть ли у вас пример лучшего соглашения об именах для 4 файлов, указанных в сценариях?

На самом деле, с логической точки зрения я бы особо не изменил

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

станет

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

😆
потому что чертовски очевидно, что это компонент ...

Я возражал против соглашений об именах Джона Папы в Angular 2. Я возражаю против того, чтобы он называл компоненты, каналы, службы, модули и прочую лишнюю ерунду. Он придумал эти соглашения для Angular 1, когда использовал конфигурации Grunt для объединения вручную обернутых модулей, контроллеров, служб и директив IIFE (все это было хорошей идеей в то время). Достаточно было разрешить объединение и другие задачи Grunt, чтобы сначала загрузить все файлы .module чтобы сценарии, регистрирующие контроллеры, службы и т. Д., Не взрывались при загрузке.

При этом его руководство по стилю Angular 1 было почти безупречным во всех остальных отношениях, и эти сценарии были актуальны в то время, но его руководство по стилю Angular 2 (официальное) ужасно. Опять же, кто мог написать элегантное руководство по стилю для чего-то, что изначально уродливо?

Я считаю, что вложение файлов необходимо в современной разработке, особенно в веб-разработке ...

Пожалуйста, пожалуйста ... подумайте о поддержке.

Похоже, что нам действительно нужна настраиваемая система логического представления рядом с физическим обозревателем.

Представим, что у нас есть проект со структурой (она усложнена намеренно):

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

Обратите внимание, что в текущем примере файлы спецификаций полностью скрыты. Это сделано для того, чтобы пользователь мог сосредоточиться на коде. В таком случае у пользователя будет отдельное логическое представление, которое представит ему модульные тесты так, как он хочет. Его следует настраивать на уровне рабочей области, пользователя и расширения. Пользователь должен иметь возможность быстро переключаться между представлениями как из интерфейса, так и с помощью сочетаний клавиш.

Это всего лишь черновик, но я надеюсь, что он ясно представляет идею.

Я все еще очень надеюсь, что над этим поработают. Это очень важно для организации.

Это также все чаще относится и к Аурелии. Структура очень похожа на Angular 2+. Добавление (настраиваемое) вложение файлов приведет к сокращению полностью развернутой папки src со свернутыми дочерними элементами в одном из наших средних проектов примерно на 2/3 длины.

@ RichiCoder1, да, и, к счастью, Аурелия использует логические, неизбыточные соглашения об именах :)
Вы проверили расширение aurelia vscode и его команду Open-Related-File . Не совсем связано с вложением, но очень полезно.

Я также хотел бы переименовать группу за одну операцию переименования.

Это становится очень важным, поскольку вы начинаете работать над огромным приложением angular, пожалуйста, подумайте об этом, чтобы ввести vscode, а не уже иметь его, если нет, пожалуйста, принесите аналогичный опыт для вложения файлов, который у нас есть в vs

Чувак, это действительно сделало бы приложение Angular, над которым я работаю, гораздо менее загроможденным и тупым. Я искренне надеюсь, что вы, ребята, серьезно об этом думаете.

Как я уже сказал в другом номере ..

Самая большая причина, по которой я хочу это, - это 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

Если бы он мог их вложить, было бы просто здорово.

Я также использую шаблон Command / Mediator, и поэтому получаю файлы, которые выглядят как ...

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

Он становится довольно многословным, и эта функция просто сделает мой день лучше.

Это единственная причина, по которой я все еще использую WebStorm ...

Да, и нам тоже.

2 июня 2017 г. в 10:10 MigFerreira [email protected] написал:

Это единственная причина, по которой я все еще использую WebStorm ...

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

Тупой вопрос: может кто-нибудь предоставить скриншот, как это выглядит? Я не могу представить, в чем смысл этого.

А, ладно, спасибо.

Теперь это стало для нас самой большой недостающей функцией. У меня есть коллеги, которые не будут использовать его из-за отсутствия этой функции. Это настоящая боль, когда вы пытаетесь найти один конкретный файл, когда у многих есть похожие имена. Мы попытались добавить больше подпапок для каждого компонента (Angular), но это не идеальное решение, и мы вернулись к простому перечислению всех компонентов в папках функций (и вспомогательных функций).

Я представляю TypeScript и Angular в большом проекте Dojo, и я могу сказать, что эта функция станет очень важной для пользователей VSCode в нашей команде в ближайшие несколько месяцев.

В настоящее время я работаю над проектом Angular, и возможность группировать связанные файлы будет отличным дополнением к уже отличному продукту. По мере роста проекта Angular становится все труднее ориентироваться в нем, что в настоящее время снижает производительность.

Повторяется с №13754:

ИМО, самым элегантным решением было бы оставить это на усмотрение проекта. Например, .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"}
}

Или для сгенерированных файлов (с использованием скелета навигации Aurelia, где файлы генерируются в 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)"}
}

С таким четко определенным синтаксисом я мог бы добавить любую схему вложения, которую я хотел, при условии, что она не будет чрезмерно сложной. Последний пример основан на обработке путей в gulp ( $(path) = путь, начинающийся с первого глобуса).

Я хотел бы получить некоторую информацию или отзывы о том, рассматривается ли это или нет. В нынешнем виде я не буду использовать VS Code для каких-либо разработчиков Angular или Aurelia, пока он не станет включенной функцией.

@threedaysmore Нет никаких указаний на то, что команда VSCode действительно рассматривает это (например, оно упало до конца невыполненной работы). PR # 13754 решает эту проблему, но похоже, что @playerx отказался от нее, по крайней мере, временно.

Я создал более актуальный PR: # 32061. Я ищу помощь, так как я не могу работать с некоторыми вещами (а именно с древовидной моделью).

+1

+1

+1

Я не знаю, как показать, что меня интересует эта функция. +1, похоже, не очень хороший способ, так как он будет спамить ветку (и люди ставят ей палец вниз). Какие рекомендуемые способы поставить +1 или «мне бы понравилась эта функция» проблеме github, просто чтобы показать свой интерес?

Просто добавьте большой палец вверх для первого комментария автора, чтобы указать / увеличить важность этой функции.

@bpasero закрыл мой запрос на

Может ли сопровождающий или кто-либо еще что-нибудь расширить? Или предоставить какие-либо рекомендации о том, как это можно реализовать в виде запроса на вытягивание или расширения?

@ firelizzard18 Я очень сильно хотел эту функцию, потратил некоторое время на работу и получил те же отзывы. Я думаю, что есть причина, по которой им не нужна эта функция, но они нам не говорят :)

@bpasero
Я думаю, что эта функция заслуживает дополнительных указаний от вас (от участников), о том, как это можно сделать, и, как вы видите, есть люди, которые могут потратить свое время на то, чтобы это произошло.

Было бы здорово иметь вложение файлов и в VS Code.
Недавно я перешел с VS 2017 на VS Code для Angular / интерфейсного программирования для моего приложения ASP.NET Core из-за лучшей поддержки / интеграции Angular. Это работает намного лучше, но мне очень не хватает вложенности файлов. :-(

Пожалуйста, добавьте функцию вложения файлов в 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 имеют сильные варианты использования, и настроения разработчиков неизменно положительные (что я хотел бы подтвердить и лично). Еще раз спасибо

@develleoper Я думаю, они довольно четко

Я совершенно уверен, что они знают о вариантах использования, но если вы посмотрите на дорожную карту, вы можете увидеть, что их планы намного более амбициозны и полезны, чем этот, поэтому (я думаю), почему они решили оставить этот для сообщества. .

Я думаю, вы более чем можете попробовать - отличная возможность карьерного роста в Micro $ oft ждет смельчака;)

LUL "Micro $ oft" - я удивлен, что подростки с ограниченным опытом вообще следят за этой веткой.

_Anyway_, @develleoper - они (Microsoft) недавно добавили возможность позволять производителям расширений добавлять свои собственные панели сбоку, поэтому, когда это скоро будет выпущено, некоторые разработчики расширений, вероятно, сделают расширение, чтобы отображать логическое дерево файлов вместо физического. .

@waynebloss IMO, эту функцию не следует оставлять как потенциальное расширение, требующее новой панели. Такой подход потребует не только повторной реализации дерева файлов со всеми его текущими функциями, но и обновления его любыми будущими добавленными функциями. Да, текущий код дерева файлов может быть преобразован в расширение, но это не уменьшает бремени обслуживания, связанного с отслеживанием будущих обновлений функциональности.

По крайней мере, само дерево файлов могло предоставить достаточно точек расширяемости для реализации этого. (Добавление этого и создание расширения для его использования для этой функции, вероятно, в любом случае потребует меньше усилий.)

@RoyTinker согласился - я думал, что новая панель будет просто обходным путем, пока вложение файлов не будет официально поддержано.

@Wayofthesin Я совершенно не понимаю, о чем вы пытаетесь добраться. Я не думаю, что кто-то серьезно сомневается, хочет ли сообщество этой функции, поскольку мы совершенно ясно дали понять, что хотим. И что не менее ясно, если вы действительно читаете историю, так это то, что сообщество пыталось реализовать это, и разработчики сказали «Нет». @playerx сделал запрос на

Таким образом, должно быть совершенно очевидно, что сообщество хочет этого, а разработчики не заинтересованы в том, чтобы принимать за это вклад сообщества.

@develleoper и другие, я думаю, что комментарии @bpasero к PR https://github.com/Microsoft/vscode/pull/13754

Из его комментариев я понимаю, что @bpasero :

• хочет комплексного подхода, который удовлетворял бы потребности всех групп, которым требуется какое-то логическое представление
• рассматривает вложение файлов как логическое представление (в отличие от физического представления файловой системы)
• считает, что логическое представление должно быть отделено от физического представления файловой системы

На мой взгляд, хотя вложение файлов _является_ логическим изменением представления, то же самое и с скрытием файлов, что в настоящее время поддерживается в дереве файлов и настраивается с помощью настроек. Мне кажется, что вложение файлов - это просто еще одна форма сокрытия файлов, за исключением того, что она предоставляет способ раскрыть эти файлы.

Кроме того, Atom теперь поддерживает вложение файлов через свой пакет просмотра в виде дерева - см. Https://github.com/atom/tree-view/issues/572

@ firelizzard18 Я видел ваш запрос на

@RoyTinker довольно хорошо прокомментировал, чего они ожидают. Можно было бы говорить о создании PR, но, насколько я понимаю, даже самые первые ожидания от @bpasero не

Независимо от VS, наш собственный проект помещает все сгенерированные файлы MAP и JS в папку out, а не на том же уровне, что и файлы TS, и я уверен, что есть другие проекты, которые делают то же самое. Я хочу сказать, что я ожидал бы вложить эти файлы в файлы TS так же, как вы это делаете, когда они находятся на одном уровне.

В качестве дополнения я бы добавил: не думайте о виртуальном проводнике как о проводнике файлов. Кто-то может захотеть вложить экспортированные объекты в файл машинописного текста.

Думаю, поэтому они не приняли PR. Они не заинтересованы в исправлении существующего кода. Они ищут гибкое решение, которое можно не только настраивать, но и расширять. Похоже, они сами не имеют об этом представления, но в значительной степени знают, чего не хотят.

Проблема, я вижу, в том, что мы пытаемся угадать, почему они не принимают пиар, а четкого ответа и указаний нет. Все комментарии, которые вы сделали, - это ваша интерпретация того, что думает по этому поводу @bpasero .

Так много разговоров и молчание со стороны участников, я думаю, что это плохо для самого продукта.

@Wayofthesin , @playerx попали в @bpasero хочет чего-то большего, чем то, что мы предоставляем, но @bpasero не смог предоставить достаточно отзывов, чтобы прояснить, куда двигаться. В моем случае @bpasero закрыл мой пиар крайне расплывчатым комментарием. В случае с @playerx @bpasero прокомментировал: «Мы находимся в финале игры, я смогу вернуться только в следующем месяце», и не делал никаких дальнейших комментариев за последние полтора года.

Мой пиар был в стадии разработки. Я хотел получить советы от разработчиков о том, как двигаться дальше. Вместо этого я получил загадочный ответ, и мой PR закрылся.

В моем комментарии , на который вы ссылались в своем обзоре моего PR, я предложил план решения проблем @bpasero с (отсутствием) универсальности подхода @playerx . В своем PR я начал работать над реализацией некоторых, но не всего, из этого, так как я был на очень незнакомой территории и хотел получить руководство, прежде чем двигаться дальше.

Просто шучу. Захотелось немного поднять настроение. Пожалуйста, исследуйте это. Очень сложно работать с таким взглядом на проект. Это несложно, но неэффективно.

+1, согласен, эта функция будет очень полезна и для разработки мини-приложений WeChat

Это слишком сложно? Около 2 миллионов участников сообщества Java нуждаются в этой функции как можно скорее. ПОЖАЛУЙСТА....!!!

Кажется, что VS Code имеет некоторую поддержку для вложения виртуальных файлов в древовидное представление. Журнал изменений для версии 1.29 включал этот пункт:

Похоже, это указывает на то, что была создана основа для группировки файлов.

@MortenChristiansen ммм ... Кажется, это не одно и то же '

В качестве предложения Visual Studio 2017 имеет функцию вложения файлов через файл конфигурации

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

шишка 🏗

также подойдет для автоматически сгенерированных файлов в dart.

Это также будет полезно для расширений Salesforce. В наших проектах есть файл *.meta.xml связанный с каждым файлом кода, так что это эффективно увеличивает длину нашего файлового дерева вдвое. Мы хотели бы поместить этот файл метаданных в исходный файл.

Я не считаю, что проблема заключается в том, чтобы собрать требования / потребности пользователей в отношении функции вложения.
Я не думаю, что это проблема для его реализации. Может быть, пожертвование поможет быстрее реализовать в официальных релизах?

Глядя на мои файлы,
Машинописный текст, веб и стили расположены высоко.
Вложение было бы неплохо.

Извините ребята. Похоже, им это совсем не интересно.

Чувак, я бы тоже хотел это увидеть.

Странно - поведение этой функции очень хорошо определено и явно очень необходимо.

+1 Давай, ребята

Этого не происходит, ребята, поэтому я, наверное, закрою проблему.

@isidorn дал понять, что они не заинтересованы в этом и не пытаются это делать. Что прискорбно. Это все, что мне мешает сейчас использовать VSC. Приложение Angular без вложенности файлов настолько многословно и беспорядочно.

Думаю, я все еще придерживаюсь WebStorm.

Я предлагаю оставить этот вопрос открытым, мы можем решить его в не столь ближайшем будущем.

@isidorn , учитывая «не столь близкое будущее», можете ли вы дать рекомендации о том, как это должно быть реализовано? Я хотел бы нанести удар, но у меня нет отзывов о моем MR.

2019, что-нибудь новенькое, ребята?

Как разработчику java, это главное, что мешает мне полностью перейти на vscode.

В моих java-проектах пустые каталоги для пространств имен java-пакетов занимают половину (или больше) доступных пространств в проводнике. Мне всегда приходится прокручивать вверх / вниз в проводнике, что отнимает много времени, когда вам приходится делать так много раз для каждой итерации разработки. Многие IDE для разработки java сворачивают эти пустые каталоги в одно имя пакета, что упрощает разработчикам просмотр всей структуры пакета.

Возможно ли это реализовать в vscode, но не имеет приоритета из-за других задач с более высоким приоритетом? или это просто невозможно реализовать из-за ограничений в базовой архитектуре vscode?

Любое расширение для выполнения этого? Это очень нужная функция!

Открыто более 3 лет ... не похоже, что они собираются это делать ... Сейчас устанавливаем webstorm ...

это и вставка некоторых очень простых вещей, которые, по вашему мнению, будут решены, возможно, это то, что вы получаете для бесплатного программного обеспечения и с открытым исходным кодом. Не так хорошо ... Так как скина в игре нет.

Да, очень разочаровывающий ответ (или его отсутствие) от отличной команды разработчиков.

Я сделал нестандартное вложение, но мой запрос на перенос не будет объединен. Поскольку у команды VS code другие планы, они не хотят вносить изменения в эту часть кода. Для меня эта функция также важна, поэтому я сделал собственную сборку 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$"
        ]
    },

При включении вложенности требуется перезапуск кода VS.

@floatas Спасибо за ваш код! Что вы думаете о продлении?

@ e-belair К сожалению, создать расширение невозможно. API для этой функции недоступен.

Функция вложения файлов была бы такой приятной! Надеюсь, это произойдет :)

@floatas Где пиар?

@tariqporter # 72160

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

Поскольку у команды VS code другие планы, они не хотят вносить изменения в эту часть кода.

Это будет # 41627, который будет обрабатываться сначала как часть перезаписи древовидной структуры, что, вероятно, должно упростить реализацию впоследствии.

Я думаю, что VS Code просто великолепен, но это настолько основная функция, что ее не хватает.

С нетерпением жду этого

мне это нужно

Просто любопытно, есть ли какие-нибудь обновления по этому поводу? Было бы здорово очистить представление в виде дерева!

VS для Mac все еще используется только из-за этой функции с приложениями Blazor. Почему команда так сопротивляется?

Есть ли проблема с отслеживанием реализации API-интерфейсов расширений, необходимых для того, чтобы сделать это возможным с их помощью?

Спустя 4 года и никакого прогресса в этом вопросе? oO ..
Честно говоря, это ошеломляет ...

Я не могу вспомнить какие-либо IDE, которые я использовал, которые не поддерживают это тем или иным образом, и я не могу думать ни о каких проектах на какой-либо платформе, над которой я работал, где это было бы бесполезно ... oO .. Дошло до того, что я просто предположил, что это задано в любой IDE ... думаю, нет ...

Команда просто пытается подтолкнуть людей к конкурентам? ...
Я бы с удовольствием заменил WebStorm на VSCode, но, думаю, этого не происходит. И тогда мы и близко не подошли к замене VS или IDEA: S ...

Ну что ж...

@jeme Вы думаете, что издевательства над разработчиками будут иметь какой-то эффект? Я знаю, что если бы я был сопровождающим, я бы категорически игнорировал любые антагонистические комментарии. Если вы действительно хотите быть конструктивным, а не просто вредителем, попробуйте: «Эта функция очень важна для меня и мешает мне принять этот инструмент».

@ firelizzard18, то вы

Если вы прочитаете здесь комментарии, вы увидите, что многие люди ведут себя так, как вы говорите, они должны их слушать.

И вы думаете, что антагонизм изменит ситуацию?

Я говорю о том, что хорошего делового человека не волнует, как донести сообщение до слушателя. Так что вы не станете хорошим деловым человеком, если проигнорируете эти комментарии. Если бы вы когда-либо работали на линии поддержки клиентов в какой-либо технологической компании, вы бы это поняли.

Наконец, мой общий финал: если вы читаете, в нем говорилось, в любом случае, неважно, приятно (предыдущие комментарии хороши) или неприятно (комментарий, который вы читаете), они не собираются этого делать, потому что они не имеют скина в игре, это бесплатно. На самом деле это спорный вопрос, и они должны закрыть билет.

Можем ли мы сосредоточить раздел комментариев на возможных решениях и выводах, а не жаловаться на то, почему эта проблема еще не решена? Способ сообщить вам о влиянии этой проблемы - проголосовать за ее описание .

Спасибо

Для этого есть открытый пиар (# 13754) ...
Если кто-то официально объявит форк и настроит базовый статический сайт с двоичными файлами для windows, apple и linux ... возможно, пара 1000 разработчиков angular набросятся на него в одночасье, и если где-то есть небольшая кнопка для пожертвований, вы также можете заработать немного денег за усилие.
Мне лично эта функция сейчас не нужна, но VSCode находится под лицензией MIT, сообществу действительно нужна функция, и некоторые члены сообщества очень усердно работали над реализацией этой функции.
Так...

Может быть, они тоже могут исправить # 75181! Простое отображение панели проводника не должно приводить к открытию вкладок с файлами.

@BrunnerLivio, ты слишком смешно

Лично я думаю, что это было бы неплохо, но я бы никого не стал приставать к этому
поскольку я знаю, что в основном это бесплатно, это не значит, что кто-то держит их в соглашении об уровне обслуживания или платит деньги за поддержку. Поскольку под словом «покупатель» подразумевается купленный товар.

Итак, альтернативы

1. кто-то, чтобы разветвить источник, добавить функции, отправить запрос на перенос, а затем попросить его включить его
2. В качестве другого варианта, возможно, попробуйте Visual Studio 2019 Community, которое также является бесплатным (но не с открытым исходным кодом), поскольку оно имеет вложенность
3. Используйте что-нибудь еще, пока это не будет добавлено в

Еще одна альтернатива, я думаю:

Создайте расширение, которое имитирует дерево проводника с его собственной кнопкой и панелью на боковой панели, и используйте его.

Я так и сделал.

пт., 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=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG63LVMVMVK3TUL52HS4DFVREXG63LVMVMVMVMQWMCWMC08C02GWMVMVB
или отказаться от подписки
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 прошлого.
Это имеет смысл, если посмотреть на это с точки зрения MS, пытающегося продвинуть dotnet как, например, альтернативу java с открытым исходным кодом.
Хотя вам все равно понадобится лицензия для использования Studio 2019 с точки зрения бизнеса.

Я использую как Studio 2019, так и VSCode для разных случаев использования. VScode я предпочитаю для python, Studio 2019 - для dotnet.
VSCode, если я работаю над чем-то с открытым исходным кодом и т. Д.
Компилятор не является общим, по крайней мере, для dotnet, поскольку это отдельный внешний инструмент, кстати.
Также оба написаны на разных языках, VSCode - Javascript, Studio 2019, вероятно, комбинация C # и CPP.

Я предполагаю, что причина, по которой эта функция еще не была перенесена, - это эфир

1. Они стремятся сначала реализовать какую-то другую функцию, например, что-то, связанное с расширениями или зависимостью, которая необходима в первую очередь.
2. Другая команда, другой уровень ресурса
3. Должен быть написан с нуля, не может копировать пасту между разными языками.

@georgebatalinski Я согласен с большей частью того, что вы говорите. Тем не менее, я считаю, что визуальный код полезен для angular больше, чем для визуальной студии. Он специально старался изо всех сил, чтобы быть более удобным для разработчиков для интерфейсных спа-центров. Я использую продукты VS с 90-х годов, так что я, наверное, старше вас;) Я вернулся к дням vb, даже Qbasic. Лично мне надоела вещь "я, я, я", дайте мне ее бесплатно. Я буду счастлив заплатить за визуальный код, в частности, чтобы получить эту дополнительную функцию. Но опять же, я все еще не использую VC, потому что считаю, что эта функция просто необходима для более масштабных приложений, на мой взгляд.

Будет ли эта функция реализована?
Я считаю это весьма полезным при работе с веб-проектами, поскольку существует множество сгенерированных файлов, которые загромождают рабочую область (но иногда вам нужно посмотреть на них, поэтому скрытие - не решение).

Почему бы не предоставить пользователю возможность отключить / включить его и выбрать, какие расширения запускают его ?! :-)
Кажется, это так просто реализовать ....

@ funder7 Не очень скоро. Разработчики заявили, что у них другой идеологический взгляд на то, как должен работать VS Code, так что это не совсем приоритет.

Спасибо @tmarkovski , сейчас я использую это для удаления сгенерированных файлов rm -f *.js *.map ... Кстати, я обнаружил эту функцию в IntelliJ Idea, она очень удобна при работе со сложными проектами.
Если разработчик не видит этого приложения, по крайней мере, я бы оставил его отключенным по умолчанию, но предоставил конечному пользователю возможность включить его.
Я упомянул Idea, потому что именно такие функции для меня - вот что отличает второстепенное программное обеспечение от вашего любимого.

На самом деле я обнаружил, что это

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

скрывает сгенерированные файлы, но затем они исчезают, и вы не замечаете их присутствия: /

Прошло более 4 лет, что для страны программного обеспечения - вечность, а по-прежнему нет планов реализовать это? Это очень важно для производительности за счет снижения умственной нагрузки при сканировании через огромную древовидную структуру файлов. Позволяет отдельные файлы интерфейса Typescript без нагрузки дополнительных файлов, появляющихся в проводнике.

Есть ли прогресс в использовании этой функции?

Есть ли прогресс в использовании этой функции?

Повторяющаяся проблема была закрыта членом команды vscode на прошлой неделе, поэтому они знают о ней, но предпочитают игнорировать ее.
На самом деле пытаюсь понять, почему.

На самом деле пытаюсь понять, почему.

Потому что для них это не приоритет. Как команда, они решили сделать другие вещи приоритетными. Вы можете не согласиться с их решениями, но все это нытье " Противно и бессмысленно.

Потому что для них это не приоритет. Как команда, они решили сделать другие вещи приоритетными. Вы можете не согласиться с их решениями, но все это нытье "OMG _whhhhy_" противно и бессмысленно.

Для меня бессмысленно, что разработчик решает, как другой должен писать свой код. Вот почему у приложений обычно есть представление «предпочтений», где вы можете настроить среду по своему усмотрению. Поскольку мы говорим об инструменте, который используется в течение всего дня для рабочих целей, мне не кажется глупым просить о функции, которая делает список файлов более читаемым.

Пользователи, запрашивающие функции, улучшают VSCode, и, возможно, если достаточное количество людей попросят эту функцию, это действительно произойдет. Но жаловаться бессмысленно.

должен иметь функцию для больших рабочих пространств.

Я недавно еще раз взглянул на это, из того, что я могу понять, в прошлом было несколько запросов на вытягивание, которые не зашли очень далеко.

• 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, но ничего не нашел
Я думаю, что нам нужно, чтобы кто-то написал расширение, которое может показывать то же, что и окно проводника по умолчанию, но с добавленной вложенностью, в идеале с поддержкой чтения файлов .filenesting.json, которые уже используются в Visual Studio 2019 (не код)

• 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 _whhhhy_" противно и бессмысленно.

Вы ведь понимаете, что столкнулись с проблемой _feature request_, верно? Вы были бы правы в любом другом месте, но это _Aactual_ правильное место, чтобы просить и говорить об этом (это не бессмысленное нытье). Если они думают, что люди счастливы и не нуждаются в этом, это никогда не будет приоритетом.

Я объясню, зачем мне «виртуальные папки»: я работаю с базой кода C, настроенной через make-файл, и я не могу рисковать изменить его. Однако код выглядит беспорядочно, и у меня есть другие кодовые базы, которые нужно поддерживать с той же проблемой.

Мне нужно виртуально расположить файлы в виртуальных каталогах, чтобы сохранить рассудок, и я могу сделать это в: Code :: BLocks, Programmers Notepad (да). Но я не могу в VS Code.

Это _обязательно_ для людей, которые не контролируют то, как они организуют свои файлы в папках, что является обычным явлением во многих организациях. Дело не в том, чтобы «сделать красивее».

Результат: я менее продуктивен при использовании VS Code. Хотел бы я использовать его, но это просто более медленный рабочий процесс.

Я надеюсь, что команда передумала, я не думаю, что с этим нужно справляться с помощью плагина, хотя технически это возможно. Я не хочу зависеть от поставщика плагинов для такой основной потребности, тратя время на то, что может сломаться.

Я понимаю, что это не приоритет, я просто прошу, если вы хотите, чтобы больше пользователей могли использовать VS Code и быть продуктивными, подумайте об этом в будущем.

@grbd Я бы с удовольствием помог, но это, кажется, много работы, не уверен, есть ли у меня столько времени.
Я обновил вилку нестандартного размещения файлов, чтобы она соответствовала сегодняшнему мастеру. Если кому-то нужна отправная точка с вложением файлов, также добавлены двоичные файлы, чтобы опробовать его.
https://github.com/floatas/vscode