在Visual Studio(15/17)中，我真正缺少的是一个纯TypeScript项目(没有C#或其他任何东西)。
为什么我缺少它？
带有TypeScript项目的HTML应用非常好，它允许我进行开发、调试、同步仓库、运行gulp任务，一切都很完美(除了通过Chrome调试协议进行调试，这相当复杂，可能在2015年或2017年有所改变，但我还没有尝试过),但是...
由于我只关注前端，所以不需要后台的其他东西。我没有开发IIS模块，后端被分离到不同的解决方案中，所以我完全不需要C#或ASP.Net。C#代码的编译会极大地拖慢构建过程(尤其是当我的解决方案中有多个具有一些依赖关系的项目时),对我来说完全没有用处。我想说专注于Angular应用程序开发的TypeScript开发者也会同意这一点。
因此，我基本上缺少的是一个项目扩展(.tsproj听起来不错 :)),它将允许我：
- 开发TypeScript Web应用程序，包括标准Web资源(html、第三方javascript、图像、样式表、less/sass样式表、jsons、MD's、xmls等Asp.Net应用程序所能做的一切，因此项目项应该几乎相同)
- 每个解决方案中的多个项目具有依赖关系(与C#相同),以便遵循构建顺序，并可以在一个项目中用作另一个项目的库。如果能找到一个好的机制来复制转换后的.js和.d.ts文件到消费者项目，就像C#所做的那样，那就太好了。但是清理应该是正常工作的，并且还可以删除这些文件！
- 对tsconfig的支持与已经存在的小改动相同：内部支持Debug/Release配置(我目前正在使用tsconfig.json、tsconfig.common.json、tsconfig.Debug.json和tsconfig.Release.json,其中tsconfig根据解决方案配置扩展为Debug或Release - 现在通过预构建脚本实现，Debug/Release扩展为common以避免多次编写相同的选项，所以如果可以包含它，那就太好了)
- CompileOnSave功能应该适用于TS文件，对于其他资源，应该可以执行自定义操作(例如启动批处理文件或Node.js中的.js文件以执行自定义操作)。这对于css转换、图像处理、资源捆绑等非常有用)。
- 构建 - 可以设计成在构建过程中不停止/重启调试/IIS(仅在Debug/Release更改时)。构建应允许执行上述提到的任务：按正确顺序编译解决方案中的项目，资源处理，打包 - 根据可配置的自定义操作(在构建过程中执行某些脚本 - 至少在预/后构建期间)
- 运行 - 具有修改web.config和application.host配置文件的标准的IIS Express(基本上，就像现在在Asp.Net项目中一样)。可以省略对IIS Express进程本身的调试，因为在Web服务器端没有什么可调试的
- 调试 - 对于IE11调试(如果我需要的话，我会使用VS内部的chrome/firefox调试器),但如果有可能通过Chrome远程调试协议进行调试就太好了，因为这是多个浏览器所支持的
- 也可以像现在一样配置浏览器以开始/调试
- Web发布(与现在一样工作，只是针对前端文件。可以省略用于IIS模块和Asp.Net应用程序的IIS的.dlls)
- 仓库管理(与现在使用i.e. Git扩展的VS的方式相同)
9条答案
按热度按时间2ul0zpep1#
感谢您的反馈。这确实是我们已经讨论了一段时间的事情，希望在某个时候能加上去。一个“JavaScript库”的想法很有吸引力，可以像DLL或WinRT组件一样在项目之间引用。
目前，您是否查看过可用的Node.js模板(如果Node.js工作负载已安装在VS 2017中，或者作为VS 2015的一部分安装了NTVS扩展)?如您上面提到的，在构建库的过程中(用于压缩、捆绑等),使用Node.js是很常见的，因此作为一个实际的Node.js项目是托管生成JavaScript库的项目的理想场所。它还可以启动一个简单的Node.js托管服务器(例如Express或http-server)进行托管/调试，避免了IIS Express或C#资源的需求。
项目到项目之间的引用和工具内管理构建顺序仍然缺失，但这确实让您离目标更近了一步。我们肯定会长期努力寻找更好的解决方案。
iyr7buue2#
我想要一个TypeScript库项目；乐意将其输出的js和Map文件构建到其他使用它的项目的scripts文件夹中。TypeScript Node项目差不多可以工作...
dsekswqp3#
例如，Babylon.js使用.csproj进行此操作，这并不理想。
e5nqia274#
这个问题已经被解决了。实际上，它是获得第二多票的建议。
因此，关于这个问题是否已经修复的评论需要谨慎对待。
对于TypeScript来说，与Visual Studio相关的工作通常不是优先事项。
qzlgjiam5#
旧的UserVoice问题已关闭 - 新的UserVoice issue is here。
我认为一个特定于TypeScript的项目类型是有用的(在其中一个或多个.tsconfig文件中使用TypeScript配置),但我也认为有一个强烈的需求，即需要一个Web UI项目类型，这目前在VS 2017中也不受支持。
qkf9rpyu6#
在issue on user voice上添加了一条评论，我在这里重新呈现：
理想情况下应该有两种JavaScript/TypeScript项目类型：
1. 库项目类型
当前的解决方法是使用C#或ASP.Net Web应用程序项目类型。
.tsconfig忽略此列表，因此项目xml不应列出任何文件；它应仅包含MSBuild逻辑。2. Web服务项目类型
目前由NodeJS Web应用程序(NTVS)项目类型处理
虽然上述许多问题也适用于NodeJS项目，但迄今为止最大的问题是NTVS似乎最初是一个副项目，项目的基本质量相当差。只需要查看NodeJS目标文件(C:Program Files (x86)\Microsoft Visual Studio\2017Community\MSBuild\Microsoft\VisualStudio\v15.0Node.js Tools)就可以看到那里存在的混乱和垃圾。complete lack of responses to issues raised指出该项目缺乏维护。Raising issues on user voice doesn't seem to do any good either.
这对我们来说是一个严重的问题。TypeScript编译器的性能改进被花在Visual Studio中编译“解决项目”的时间所掩盖。
我只是想“添加->新建项目->库|Web服务并继续进行，而不必忍受性能问题以及不得不携带C#和ASP.Net所需的额外负担。
elcex8rz7#
看起来这是一个重复的问题？
8ljdwjyq8#
有人能向我解释一下为什么还没有TypeScript项目类型吗？关于它的第一项问题是在2014年提出的，而现在TypeScript基本上已经成为了网络标准。忽略由微软开发的TypeScript - 这有点荒谬。Node.js项目只是一个权宜之计，没有解决方案。
ojsjcaue9#
我们现在确实有一个JavaScript项目类型。扩展名为.esproj，它可以作为ASP.Net的库使用，但目前仍处于早期阶段，对于它无法满足人们需求的场景，我们非常欢迎提供反馈。