Typescript: Вариант Visual Studio «Без компиляции»

Привет, всего несколько дней назад я отправил выпуск № 2252, который в некоторой степени связан с этим. Мне нужен способ запускать события до и после сборки при использовании компиляции при сохранении для проекта TS с одним выходным файлом (при сохранении обычных команд VS «Сборка» и «Перестройка», языковой службы, отладки и т. Д. .). В качестве обходного пути в настоящее время я использую Task Runner Explorer с grunt-contrib-watch (запускается с использованием привязки «Solution Open»), чтобы отслеживать изменения в скомпилированном файле и выполнять дополнительные действия каждый раз, когда он изменяется.

Однако я не нахожу это действительно удовлетворительным (мне также нужно выполнить некоторые действия перед компиляцией и, как правило, я предпочитаю, чтобы шаги сборки выполнялись либо полностью, либо с использованием Grunt, либо все с VS), и подумайте о том, чтобы сделать именно то, что описано: полностью отключить компиляцию VS и реализовать настраиваемую компиляцию при сохранении, полные сборки (которые включают запуск модульных тестов и т. д.), события до и после сборки с комбинацией grunt-contrib-watch, grunt-ts, дополнительных подключаемых модулей grunt и Task Runner Explorer .

(обновление: это уже реализовано, и оно отлично работает - он запускает собственный скрипт сборки grunt каждый раз, когда файл .ts изменяется, хотя в настоящее время он не поддерживает привязки TRE "Before Build" и "After Build" - для вышеупомянутого причины).

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

Не знаю, есть ли у вас сейчас отличный вариант. Если вы установите в свойствах каждого файла .ts в проекте Build Action: None , это, вероятно, будет делать то, что вы хотите, но это довольно обременительно делать вручную даже в проектах среднего размера.

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

Это заставит вашу языковую службу не собирать все файлы проекта в одном контексте. Я бы сказал, что это нормально, и к следующему выпуску у нас должна быть поддержка tsconfig, и тогда это станет вашим новым проектом. Если вы все же хотите, чтобы он работал без использования tsconfig и / или ожидая следующего выпуска, определите свойство <TypeScriptEnabled>true</TypeScriptEnabled> в файле проекта.

@mhegazy ты имел ввиду <TypeScriptEnabled>false</TypeScriptEnabled> ?

ну смотря чего хочешь :)

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

Хорошо, я возьмусь с этим. Благодаря!

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

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
...
    <TypeScriptEnabled>false</TypeScriptEnabled>
...
</PropertyGroup>

Я не совсем уверен, что означает «отключение загрузки содержимого проекта языковой службы»? (Я не очень знаком с концепциями VS, такими как цели, контексты и т. Д.). Насколько я тестировал, с этой опцией все работает нормально (за исключением ожидаемого поведения отсутствия компиляции при сборке)? И похоже, что он все равно будет добавлять записи <TypeScriptCompile Include=".."/> для вновь добавленных / созданных файлов .ts в конфигурацию проекта.

Кстати, теперь, когда все делается через Grunt, мне как-то нужно найти способ справиться с конфликтами между сборками, запускаемыми grunt-watch, и связанными событиями «Before Build» / «After Build» при вызове VS Build (F6) и Rebuild , поскольку VS автоматически сохраняет перед запуском сборки, что приводит к ненужной параллельной работе двух разных экземпляров Grunt.

Мне не удалось заставить <TypeScriptEnabled>false</TypeScriptEnabled> работать (VS 2013 Update 4 с TypeScript 1.4), но удаление целевого файла TypeScript из проекта отключило компиляцию в проекте Build.

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

• Удалите ссылку на файл TypeScript «.targets» из файла проекта.
• Отключите «Автоматически компилировать файлы TypeScript, которые не являются частью проекта» в параметрах Visual Studio TypeScript.

Второй шаг - это своего рода ошибка (или, по крайней мере, диалог не помечен строго точно); Даже если ваши файлы TypeScript являются «частью» проекта, если вы отключите целевой файл, Visual Studio 2013 будет рассматривать их, как если бы они _не_ часть проекта, и компилировать при сохранении (если глобальный параметр не установлен). Я не мог заставить <TypeScriptEnabled/> что-либо делать.

Спасибо @mhegazy - было бы здорово, если бы это могло быть частью диалогового окна параметров TypeScript, но, по крайней мере, его довольно легко поддерживать с помощью редактирования проекта.

одна сложная вещь: <TypeScriptEnabled>false</TypeScriptEnabled> должен быть в конце вашего файла, особенно после импорта в целевые объекты. поскольку цели все равно определяют его, и вы хотите его переопределить.

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

Вы совершенно правы! Это была уловка.

Думаю, это решает проблему. Спасибо, @mhegazy .

Привет @mhegazy - извините за беспокойство. Вы уверены, что <TypeScriptEnabled>false</TypeScriptEnabled> работает в VS 2013 с установленным TypeScript 1.4? Я только что обновил свой текущий компьютер с VS 2013 с TS 1.3 (прямо VS 2013 с обновлением 4) до VS 2013 с TS 1.4, и теперь Visual Studio пытается снова создать TypeScript «при сборке» (что означает, что появившиеся ошибки имеют «Build : "перед ними), хотя последние пять строк моих проектов выглядят так:

  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
  <PropertyGroup>
    <TypeScriptEnabled>false</TypeScriptEnabled>
  </PropertyGroup>
</Project>

Раньше сегодня он работал правильно на этой машине (когда я закрыл этот тикет), но теперь, когда я поставил здесь 1.4, сборка из VS выдает мне ошибки. Комментирование ссылки на целевой файл (и отключение «компилировать при сохранении» для TypeScript не в проекте) по-прежнему отключает его.

У меня дома 1.4, и я не мог заставить <TypeScriptEnabled>false</TypeScriptEnabled> работать там вообще - мне интересно, была ли регрессия в этом варианте сборки?

<TypeScriptEnabled>false</TypeScriptEnabled> имеет ничего общего со сборкой. все дело в том, что Language Service обрабатывает ваши файлы как часть проекта или нет.

если вы не хотите использовать F5, удалите ссылку на цели.

Это был краткий ответ, вот длинная версия:

Файл проекта используется для двух целей:

1. build, это обычная поддержка MSBuild, где цели вызывают задачи, а система находит входные данные, соответствующие цели и выполняет их по порядку. поэтому все, что это делает, - это объединение всех элементов TypeScriptCompile в проекте, передача их в tsc.exe вместе с некоторыми параметрами.
   Кроме того, страницы свойств проекта являются производными от файла проекта и представляют собой просто пользовательский интерфейс поверх свойств MSBuild.
2. языковой сервис, это ваше завершение, справка по подписи, ошибки в VS, компиляция при сохранении и т. д. мы хотим, чтобы они работали так же, как и ваша обычная сборка, поэтому мы ищем те же свойства, которые вы определяете для сборки, и управляем LS поведение. например, если ваша цель установлена ​​на ES3 в вашем файле проекта ( <TypeScriptTarget>ES3</TypeScriptTarget> ), ваша языковая служба выдаст вам красную волнистую линию, если вы определите get / set в классе.
   Это позволяет использовать один набор параметров как для поведения сборки, так и для времени разработки.
   Чтобы это сработало, цели сообщают языковой службе, что она знает о машинописном тексте, определяя свойство <TypeScriptEnabled>true</TypeScriptEnabled> .

Если вы не хотите, чтобы сборка VS работала, просто удалите цели. это отключит сборку, но также сообщит LS, что этот проект не является проектом TypeScript. и тогда он будет рассматривать все файлы как «свободные файлы». если вас это устраивает, то больше работы не нужно. если вы хотите изменить это и заставить его по-прежнему использовать свойства из вашего файла проекта, а не включать другие файлы, открытые в вашем проекте, и т.д .. тогда добавьте <TypeScriptEnabled>true</TypeScriptEnabled> в свой файл, и LS обработает его соответствующим образом .

Если вы хотите, чтобы сборка работала в VS, но LS не рассматривал ее как проект, установите флаг в false.

Благодарю. Это отличная информация, и, похоже, все работает в соответствии с тем, что вы описали. Если я удалил файл .targets, но установил для TypeScriptEnabled значение true, ожидается ли, что вкладка TypeScript Build исчезнет из свойств проекта?

  <!--
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
  -->
  <PropertyGroup>
    <TypeScriptEnabled>true</TypeScriptEnabled>
  </PropertyGroup>
</Project>

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

Причина, по которой я все это спрашиваю, заключается в том, что несколько недель назад я написал библиотеку npm для чтения свойств сборки TypeScript из файлов .csproj и .vbproj (https://www.npmjs.com/package/csproj2ts), которые я В данный момент интегрирую в grunt-ts. Когда он будет готов, появится простой способ эффективно «запустить tsc для файла .csproj» (как указано здесь: https://github.com/Microsoft/TypeScript/issues/1702). Я хочу иметь возможность рассказать людям, как лучше всего настроить свой проект на использование языковой службы VS TypeScript для программирования, но при этом полностью использовать grunt-ts для сборки. Я надеялся, что можно будет позволить людям использовать пользовательский интерфейс для настройки свойств TypeScript в этом сценарии, но, возможно, этого не произойдет.

Известно ли вам о способе отображения вкладки TypeScript Build с отключенным файлом TypeScript .targets?

Кроме того, кажется, что даже если я сделаю что-то вроде этого: <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition=" '$(Configuration)' == 'Debug' " /> , я должен установить конфигурацию проекта на Debug, а затем перезагрузить, чтобы появилась вкладка TypeScript Build.

Извини, @mhegazy - обещаю, я тебя не троллю !!

Ожидается ли, что вкладка TypeScript Build исчезнет из свойств проекта?

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

Причина, по которой я все это спрашиваю, заключается в том, что несколько недель назад я написал библиотеку npm для чтения свойств сборки TypeScript из файлов .csproj и .vbproj (https://www.npmjs.com/package/csproj2ts), которые я В данный момент интегрирую в grunt-ts.

Сценарий, которого вы пытаетесь достичь, выполним, но он будет иметь некоторые неровности, и вам нужно будет взломать несколько мест, чтобы заставить его работать. @paulvanbrenk в настоящее время добавляет поддержку tsconfig в VS, это позволяет страницам свойств проекта использовать файл tsconfig, если он там был. Мы также работаем над лучшей интеграцией в проекты ASP.net 5 , которые, я верю, будут делать все, что вы хотите, а именно: 1. поддержка grubt / bower, 2. представление на основе файловой системы, 3. использование tsconfig для управления свойствами проекта и 4. простое взаимодействие с другими редакторами / IDE. Я верю, что это будет хорошо работать с описываемым вами сценарием, и вам не придется его обходить. это будет в следующем выпуске, так что придется немного подождать :)

Кроме того, кажется, даже если я сделаю что-то вроде этого: , Я должен установить конфигурацию проекта на Debug, а затем перезагрузить, чтобы появилась вкладка TypeScript Build.

Импорты загружаются при загрузке проекта. поэтому в этом импорте вы говорите, что загружается только в «Конфигурация» «Отладка», изменение конфигурации не приводит к перезагрузке.

Извини, @mhegazy - обещаю, я тебя не троллю !!
: D не волнуйтесь. всегда люблю получать отзывы и надеюсь, что это помогло.

ХОРОШО. Искренне благодарю вас за такую ​​отличную информацию и обстоятельное обсуждение.

Просто чтобы передать это tsconfig чтобы иметь возможность отключить сборку VisualStudio TypeScript (что означает CTRL + SHIFT + B создает ваш C # и т. д., но не TypeScript) и использовать внешний компилятор TypeScript, оставляя возможность устанавливать параметры TypeScript через графический интерфейс. Существует множество причин, по которым использование внешнего инструмента компиляции может быть очень полезным, и сейчас кажется, что это действительно поддерживается только случайно и с некоторыми шероховатостями.

Идея tsconfig прекрасна, но на самом деле она не помогает:

• Использование старой версии TypeScript
• Использование разных версий TypeScript в разных проектах на одном компьютере
• Использование экспериментальной версии TypeScript (например, версии @fdecampredon , поддерживающей JSX)
• Использование инструмента сборки, такого как grunt-ts, который автоматизирует управление ссылками и выполняет другие обязанности, которые TypeScript не поддерживает
• И т.п.

Было бы замечательно разрешить пользователям Visual Studio выбрать разработанную сообществом систему компилятора TypeScript, сохраняя при этом красивый пользовательский интерфейс внутри Visual Studio (особенно с красивой надстройкой Task Runner Explorer). Я надеюсь, что вы взвесите значительные преимущества для сообщества, которые это даст, с тем временем, которое вам понадобится, чтобы написать флажок, который говорит «Отключить сборку TypeScript».

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

Это та часть, где я запутался. для меня это удаление ссылки на цели машинописного текста, а затем замена ее на ваши ворчливые цели, которые будут строить вещи по-другому. мне кажется странным включать файл .targets с условием, запрещающим ничего делать; зачем включать его в первую очередь? Я был бы рад помочь составить файл .targets, который заменяет стандартные цели машинописного текста, этот будет включать тег <TypeScriptEnabled>true</TypeScriptEnabled> и будет выглядеть в VS, как если бы он использовался по умолчанию, но он будет обрабатывать сборку по-другому.

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

простой способ начать - скопировать целевой файл Microsoft.TypeScript.Target, удалить вещи, которые вам не нужны, например, вызов tsc, и добавить задачи для вызова grunt, а также подключить конфигурацию и т. д., а затем включить его в ваш проект.

Потрясающе! Я добился того, чтобы все работало с минималистской точки зрения, установив в моем файле .csproj следующие 4 строки.

  <Import Project="$(ProjectDir)\custom.TypeScript.targets" />
  <PropertyGroup>
    <TypeScriptEnabled>true</TypeScriptEnabled>
  </PropertyGroup>

А вот минималистичный файл custom.TypeScript.targets:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <VsToolsPath Condition="'$(VsToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VsToolsPath>
  </PropertyGroup>
  <UsingTask TaskName="TypeScript.Tasks.VsTsc" AssemblyFile="$(VSToolsPath)\TypeScript\TypeScript.tasks.dll" />
  <PropertyGroup>
    <CfgPropertyPagesGuidsAddCSharp>{d4683cae-88c4-4b85-863d-ac8014f3ba36}</CfgPropertyPagesGuidsAddCSharp>
    <CfgPropertyPagesGuidsAddVB>{d4683cae-88c4-4b85-863d-ac8014f3ba36}</CfgPropertyPagesGuidsAddVB>
    <CfgPropertyPagesGuidsAddTypeScript>{d4683cae-88c4-4b85-863d-ac8014f3ba36}</CfgPropertyPagesGuidsAddTypeScript>
  </PropertyGroup>
  <ItemGroup>
    <ProjectCapability Include="TypeScript" />
  </ItemGroup>
</Project>

Я попытался поместить тег <TypeScriptEnabled /> в целевой файл, но он не работал (VS рассматривал файлы .ts как свободные). Есть идеи, почему это так? (Я уверен, что для тех, кто знает MSBuild, это очевидно - может быть, проблема в области видимости?).

Думаю, на данный момент это решает мою проблему. Я могу запустить свою задачу Grunt с помощью расширения Task Runner Explorer, которое может запускать задачи Grunt или Gulp при запуске VS Build. Теперь сборка всегда отображается как успешная, независимо от результата компиляции TypeScript, но это нормально, поскольку пользователь может видеть вывод grunt-ts в окне TRX. Панель «TypeScript Build» появится в окне свойств проекта. Компиляция при сохранении работает, если выбран этот параметр. Сборка по-прежнему отображается как сбойная, если код C # или VB не компилируется успешно (хорошо). Настройка, позволяющая попасть сюда из стандартного HTML-приложения Visual Studio с TypeScript или веб-проекта ASP.NET, довольно проста.

Видите ли вы какие-нибудь проблемы с тем, что мы распространяем указанный выше минималистичный файл .targets с помощью grunt-ts? Это будет означать, что нам нужно будет только сказать людям обновить строку .targets своего проекта до <Import Project="$(ProjectDir)\node_modules\grunt-ts\custom.TypeScript.targets" /> и установить <TypeScriptEnabled> .

Еще раз спасибо!!

Я попробовал поставить в целевом файле, но он не работал (VS рассматривал файлы .ts как свободные). Есть идеи, почему это так? (Я уверен, что для тех, кто знает MSBuild, это очевидно - может быть, проблема в области видимости?).

это странно. вот как мы его включили в наши цели, и он отлично работает. включаете ли вы другие цели, у которых есть собственность? какие условия? Я попробовал это в новом проекте ts, удалил Microsoft.TypeScript.targets, поместил ваш и добавилправда и это сработало.

Видите ли вы какие-нибудь проблемы с тем, что мы распространяем указанный выше минималистичный файл .targets с помощью grunt-ts? Это будет означать, что нам нужно будет только сказать людям, чтобы они обновили строку своего проекта .targets до и установить.

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

Несколько примечаний, вам не нужны ни справочник tasks.dll, ни определение VsToolsPath, если оно вам не понадобится для чего-то еще.

Я наблюдаю предсказанное вами поведение на моем домашнем компьютере. Он также работал без ссылки на DLL. Должно быть, раньше я совершал какую-то ошибку, так что завтра попробую снова. Я считаю, что это действительно здорово! Спасибо, Мохамед. Это должно быть выпущено как часть grunt-ts в ближайшие несколько дней.

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

Это могло быть так; Я просто выгружал / перезагружал проект. Возможно, я перезапустил VS дома. Я отмечу это в документации.

@mhegazy Спасибо за вашу помощь. Мы выпустили grunt-ts 4.0.0, который содержит функцию «компиляция из проекта Visual Studio»:

https://github.com/TypeStrong/grunt-ts#vs

Инструкции по отключению сборки VS:

https://github.com/TypeStrong/grunt-ts/blob/master/docs/DisableVisualStudioBuild.md

Очень круто! Мне нравятся такие сценарии.

Спасибо, Райан. Я довольно доволен тем, как это получилось. Когда появится tsconfig, он может оказаться менее необходимым, но до этого момента он восполнит пробел и, конечно же, совместим с версиями компилятора TypeScript до 1.5.

PS: Сегодня было два отчета об ошибках, поэтому сегодня вечером мы должны выпустить 4.0.1, если я смогу их исправить.

К вашему сведению, в VS2015 RTM есть более простой способ отключить TypeScriptCompile:
Просто добавьте <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> к .csproj , например, в первый <PropertyGroup> .

Благодарю.