VS 2015 ASP.NET 4 MVC 5中的打字稿-设置和选择的有效组合是什么? [英] Typescript in VS 2015 ASP.NET 4 MVC 5 - what are the working combinations of settings and choices?

问题描述

我正在将打字稿项目添加到VS2015 MVC 5项目中(这使其成为ASP.NET 4，不是asp.net 5或asp.net 6代码:只有MVC是版本5 ).这是我问题的所有方面的唯一目标，我不能在打字稿，node.js，模块加载器等上使用一般性或理论性的指导.

I am adding a typescript project to a VS2015 MVC 5 project (that makes it ASP.NET 4, not asp.net 5 or asp.net 6 code: only the MVC is version 5). This is the sole target for all aspects of my question, I cannot use generalized or theoretical guidance on typescript, node.js, module loaders, etc.

ASP.NET Core的问题更简单.但这不是我要面对的.关于ASP.NET 4 MVC 5，所有示例和指南的常用资源都避免或报废，因为它很难.没有人会确切说明障碍有多困难或有多严重.

The problem is simpler with ASP.NET Core. But that's not what I'm facing. All the usual sources of examples and guidance avoid or provide scraps when it comes to ASP.NET 4 MVC 5 because it is hard. And no one will state exactly how hard or what precisely are the obstacles.

最糟糕的是，Typescript文档就像开放源代码文档一样:您只会遇到一个问题，只有一步之遥.这就产生了一个由无尽问题树递归组成的研究工作流.

Worst, Typescript documentation is like Open Source Documentation: you can only get one issue, one step deep. This produces a research workflow consisting of endless-issue-tree-recursion.

我了解观点，我什至也有一个.但是我在寻找经验性的答案，什么是证明对生产团队有效的组合?

I understand opinions, I even have one. But I'm looking for the experiential answer, what is the one combination that has proven to work for a production team.

因此，这是在中等大小的ASP.NET 4 MVC 5 LOB应用程序的工作范围内需要解决的特定项目:

So here are the specific items that need to be addressed and made to work within the confines of a working, medium-sized ASP.NET 4 MVC 5 LOB app:

1. Visual Studio的打字稿版本.这是一个安装问题(最简单地使用节点)，并且工具/选项-打字稿设置必须匹配.

1. Visual Studio's version of typescript. This is an installation issue (using node most simply) and the Tools/options - typescript settings have to match.

浏览器风格的测试(通常是手动的TDD工作流程)或node.js测试(自动).必须预先选择此项，以防止出现更多的问题树递归.我们将使用基于WallabyJs的基于浏览器的phantomjs.

Browser-style testing (typically manual TDD workflow) or node.js testing (automated). This has to be chosen up-frontly to prevent more issue-tree-recursion. We are going with browser-based... phantomjs using WallabyJs.

NPM @ types/library-name:应该仅基于具有@Types引用的package.json来用库名和库名.d.ts填充node_modules文件夹.但是实际上需要package.json保留@ types/library-name和library-name的引用才能在我的VS 2015 ENT v3和asp.net 4 mvc 5项目中工作.然后，所有指定的版本都需要手动更正"，即使这样，版本查找过程还是有点可疑.使用@ .types进程可能不是ASP.NET 4 MVC 5的处理方式，但是我无法确定更正的替代方法是什么.目前，@ Types是打字稿的唯一推荐选项.

NPM @types/library-name: supposed to fill a node_modules folder with both library-name and library-name.d.ts based only on a package.json with @Types references. But actually requires the package.json to hold a reference for both the @types/library-name and the library-name to work in my VS 2015 ENT v3 and asp.net 4 mvc 5 project. And all the versions specified then require manual correction' and even then the version look-up process is a little suspicious. This @types process may not be the way to go with ASP.NET 4 MVC 5, but I can't tell what the correction alternative might be. @Types is currently the only recommended option for typescript.

ECMAScript的哪个版本:es6显然太过领先了.es2015可能会出现，但这(也许)似乎与其他一些问题有关.假设这些名称相同，但是可以在两个位置进行设置.我在工具/选项/打字稿中选择了es2015.但是弄错所有这些设置(现在是3个)可能是一个问题.

Which version of ECMAScript: es6 is apparently too far ahead. es2015 is likely, but this (maybe) appears to have relationships to several of the other issues. Supposedly, these designations are the same, but there are two places they can be set. I've chosen es2015 in tools/options/typescript. But getting any of these (now 3) settings wrong could be a problem.

模块系统:CommonJs用于节点和自动化测试，VS开发测试仅用于服务器端自动化，而VS UI测试是手动过程.因此，AMD要求JS可能是VS的一种选择，但是它增加了自己的工作流和维护以及注意事项，而这些问题在ASP.NET中确实很难解决.使用ASP.NET捆绑和三斜杠引用(可靠)可能有效，但是在将库放入节点模块后，您可能想在import语句中使用完整路径进入节点名中文件名slug中的节点模块.这一切都非常笨拙，涉及最多的猜测.但是解决整个问题可能是整个问题的关键".

Module system: CommonJs is for node and automated testing, and VS development testing is automated only for server-side, and VS UI tests are a manual process. So AMD, require JS is probably an option for VS, but it adds its own workflow and maintenance and considerations that are really hard to get right in ASP.NET. Using ASP.NET bundling and triple-slash references (dependable) might work, but after you have put the libraries in node-modules, you would want to use the full path into node-modules in the file name slug in an import statement. This is all very clumsy and involves the most guesswork. But solving this whole item might be the 'key' for the overall question.

可能还有很多其他较小的问题.但是这样做的人将解决所有上述问题，其他问题也将解决.

There are probably a lot of other, smaller issues. But someone who has done this will have solved all the mentioned items and the others as well.

我要寻找的是所有这些问题的详细设置，这些设置基于ASP.NET 4 MVC 5实施中可运行的Typescript应用程序，用于VS 2015中基于浏览器的单元/行为测试.会明白的.

What I'm looking for is all the settings across all these issues in detail based on a working Typescript app in ASP.NET 4 MVC 5 implementation for browser-based unit/behavior tests in VS 2015. Those who have done it will understand.

非常感谢您的考虑.

推荐答案

您缺少的是关注点分离，尽管此类入门模板具有最初的好处，但它们开始引起偶然的依赖性并使心理模型复杂化.将前端放在一个单独的项目中要容易得多.

What you're missing is separation of concerns, in spite of the initial benefit of such starter templates, they start to cause incidental dependencies and complicate the mental model. It's much easier to have your front end in a separate project.

不管:

Visual Studio的打字稿版本.

Visual Studio's version of typescript.

始终使用最新的可用信息.这可以控制为IDE供电的TypeScript版本.在开发过程中，您可能最终会在单独的进程中或在浏览器中进行编译.同样，您将要使用最新版本，但可能会使用其他软件包管理器进行安装.

Always use the very latest available. This controls the version of TypeScript which powers the IDE. You will probably end up compiling in a separate process or in the browser during development. Again you will want to use the latest but it will likely be installed with a different package manager.

浏览器样式的测试(通常是手动TDD工作流程)或node.js测试(自动).必须预先选择此项，以防止出现更多情况问题树递归.

Browser-style testing (typically manual TDD workflow) or node.js testing (automated). This has to be chosen up-frontly to prevent more issue-tree-recursion.

首先，我绝对同意预先选择的重要性，但是，如果仍然有可能，只是不愉快地向现有项目中添加测试.

Firstly, I definitely agree with the importance of choosing up front but, if it is still possible, just unpleasant, to add tests to an existing project.

TDD工作流程依赖于快速反馈，因此涉及自动化测试.这与您是在浏览器中运行测试还是使用NodeJS正交.

TDD workflows involve automated testing as they rely on rapid feedback. This is orthogonal to whether you run your tests in the browser or using NodeJS.

您应该使用对您的应用程序最有意义的方法，这可能是两者的结合.

You should use whichever approach makes the most sense for your application and that may be a mix of both.

由于您正在编写前端JavaScript应用程序，因此您可能希望在浏览器中运行一些测试.但是，正如鲍伯叔叔(罗伯特·C·马丁)所说，观点应该是愚蠢的，几乎不需要测试.我对此的解释是，我们不应花太多时间测试诸如Angular或React components 之类的东西，以确保它们正确呈现，而应专注于测试系统的行为元素，例如服务和纯旧的功能.

Since you are writing a frontend JavaScript application you will likely want to run some tests in the browser. However, as Uncle Bob (Robert C. Martin) has stated, views should be dumb and require little testing. My interpretation of this is that we should not spend too much time testing things like Angular or React components to ensure that they render correctly, and instead focus on testing behavioral elements of the system such as services and plain old functions.

也就是说，您可能希望针对实际的浏览器运行时而不是Node.js运行客户端服务的测试，这是合理的.

That said, you may well want to run tests of your client side services against an actual browser runtime, as opposed to just Node.js, and that is reasonable.

有许多测试库可以帮助您.除了要说您应该找到可靠的测试运行程序和简单断言库之外，我没有其他具体建议.可靠的测试示例包括QUnit和Tape等经过验证的测试库.

There are a number of testing libraries to help you with this. I do not have a specific recommendation besides to say that you should find a reliable test runner, and a simple assertion library. Tried and true testing libraries like QUnit and Tape are examples of solid options.

最后一点，重要的是不要将集成测试的概念与在Web浏览器中运行的测试相混淆，在其中运行TDD样式测试(这意味着单元测试)是完全有效的.网络浏览器.

One last note, it is important that one not confuse the concept of integration testing with running tests in a web browser, it's perfectly valid to run TDD style tests, which implies unit tests, in a web browser.

NPM @ types/library-name:应该用以下命令填充node_modules文件夹库名称和库名称.d.ts都需要，但需要package.json保留@ types/library-name和库名称可在我的VS 2015 ENT v3和asp.net 4 mvc 5项目中使用.

NPM @types/library-name: supposed to fill a node_modules folder with both library-name and library-name.d.ts, but requires the package.json to hold a reference for both the @types/library-name and the library-name to work in my VS 2015 ENT v3 and asp.net 4 mvc 5 project.

简单地讲，这可以使前端与后端解耦.Visual Studio以及ASP.NET肯定与对类型包进行版本控制无关.

Simply put this goes to back to decoupling your front end from your back end. Visual Studio and certainly ASP.NET have nothing to do with versioning your types packages.

1. 如果一个程序包带有自己的类型声明，则不需要安装辅助类型程序包.

1. If a package comes with its own type declarations then you don't need to install an auxiliary types package otherwise you do.

这两种方法都可以使用面向JavaScript的程序包管理器(例如NPM，JSPM或Yarn)安装JavaScript和TypeScript依赖项.

Either way install JavaScript and TypeScript dependencies using a JavaScript oriented package manager (such as NPM, JSPM, or Yarn).

请勿使用NuGet！

正如您所建议的那样，存在版本控制问题，这在TypeScript中目前是一个难题.但是，它又一次与ASP.NET或Visual Studio无关.

As you suggest there are versioning issues, it's currently a difficult problem in TypeScript. However once again it has nothing to do with ASP.NET or Visual Studio.

哪个版本的ECMAScript:es6显然太过领先了.es2015可能，但这似乎与几个其他问题.

Which version of ECMAScript: es6 is apparently too far ahead. es2015 is likely, but this appears to have (maybe) relationships to several of the other issues.

ES6与ES2015相同，后者是前者最终发布时的名称.现在，ECMAScript大致遵循年度节奏，ES2017指日可待.

ES6 is the same as ES2015, the latter being the name under which the former was ultimately released. ECMAScript now follows a yearly cadence, roughly, with ES2017 just around the corner.

拥有诸如TypeScript之类的编译器的好处是，您可以使用es2017的最新功能，并且仍然以es5为目标，这样就可以了.

The nice thing about having a transpiler, such as TypeScript, is that you can use the latest features from es2017 and still target es5 for emit and you'll be fine.

模块系统:CommonJS用于NodeJS和自动测试，以及VS开发测试仅针对服务器端和VS UI测试是自动化的是手动过程.因此AMD/UMD需要JS可能是VS，但它添加了自己的工作流程，维护和注意事项.使用三斜杠引用(可靠)可能有效，但是在您完成之后已将您/他们的库放在要使用的节点模块中导入中文件名slug中节点模块的完整路径陈述.(解决整个项目可能是整个项目的关键"问题).

Module system: CommonJS is for NodeJS and automated testing, and VS development testing is automated only for server-side, and VS UI tests are a manual process. So AMD/UMD require JS is probably the option for VS, but it adds its own workflow and maintenance and considerations. Using triple-slash references (dependable) might work, but after you have put your/their libraries in node-modules you would want to use the full path into node-modules in the file name slug in an import statement. (solving this whole item might be the 'key' for the overall question).

这是一个非常复杂的主题，可能是您真正需要花费大量时间考虑的唯一问题.如前所述，是否使用NodeJS与自动化测试是正交的.但是，如果您要使用测试代码将NodeJS本地定位为目标，则需要使用CommonJS输出.

This is a very complex subject and probably the only one of your questions that you really need to spend a lot of time considering. As I said earlier using NodeJS or not is orthogonal to automated testing. But if you're targeting NodeJS natively with your test code then you will need to use CommonJS output.

对于实际的应用程序代码，选择与您是否使用Visual Studio根本没有任何关系，对此我深感抱歉，但是将这些想法分开确实很重要.

For the actual application code, the choice has nothing at all remotely to do with whether or not you are using Visual Studio, I'm sorry for reiterating this but it really is important that you separate these ideas.

对于您的前端应用程序代码使用哪种模块格式，这是一个非常重要且有争议的问题.

The question of which module format to use for your front end application code is a very important and contentious one.

1. 三元组///引用不是模块格式，而是声明跨多个文件声明和引用的全局变量之间的依赖关系的一种方式.

1. Triple /// references are not a module format but rather a way of declaring the dependencies between global variables that are declared and referenced across multiple files.

它们的伸缩性不好，只有少量文件时才能正常工作.

They do not scale well, working acceptably when you have only a handful of files.

三元组///不应使用.它们不是模块化机制，它们的使用与使用您提到的任何模块系统/模块格式(包括CommonJS)完全不同.

Triple /// references should not be used. They are not a modularity mechanism and their use is completely different from using any of the module systems/module formats you mention, including CommonJS.

请不要将它们与模块系统结合使用，这是在NodeJS下运行测试或使用RequireJS或其他任何东西加载应用程序所必须要做的.

Never combine them with a module system, which is what you would have to do in order to run your tests under NodeJS or load your app with RequireJS or anything else.

RequireJS是一个很好的选择，它暗示了您所说的AMD模块.RequireJS不需要使用任何三斜杠引用.实际上，在使用这种格式或任何其他模块格式时，应该避免它们引起麻烦！

RequireJS is an excellent option which would imply AMD modules as you say. RequireJS does not require any use of triple slash references. In fact they should be avoided as the plague when using this format or any other module format!

我强烈建议您不要使用UMD模块.同构JavaScript是一个有问题的想法，由于您正在创建带有.NET后端的浏览器应用程序，因此它没有任何好处.

I recommend strongly against using UMD modules. Isomorphic JavaScript is a problematic idea, and it offers you no benefits since you are creating a browser application with a .NET backend.

许多开发人员实际上确实在浏览器中使用CommonJS模块.这要求使用Webpack等工具将它们连续捆绑在一起.这种方法具有优点和缺点.主要优点是能够通过Webpack或Browserify依靠现有的NodeJS JavaScript服务器端工具(例如npm).这听起来似乎不是一个很大的优势，但是可为CommonJS模块提供的丰富工具数量实在不容小,，这使其成为一个不错的选择.

Many developers actually do use CommonJS modules in a browser. This requires bundling them continuously, using tools such as Webpack. This approach has advantages and disadvantages. The primary advantages are the ability to lean on existing NodeJS JavaScript server-side tools, such as npm, by way of Webpack or Browserify. This may not sound like a big advantage but the amount of rich tooling available for CommonJS modules is nothing to scoff at, making it a strong option.

考虑使用系统模块格式和通过 jspm 的SystemJS加载器来管理您的软件包和加载代码.使用这种方法，您可以获得RequireJS的优势，能够在NodeJS下运行测试，并且可以使用jspm run在浏览器中运行，而无需切换目标格式或捆绑代码以进行测试.尽管支持，但在开发过程中也无需捆绑代码.更重要的是，您将获得编写未来兼容代码的优势，因为它提供了唯一的模块格式和加载器，可以正确建模ES模块在浏览器中本机实现时最终将具有的语义.JSPM对TypeScript，Babel和Traceur具有一流的支持.为了方便起见，以下是从上面的链接中获取的系统模块格式的说明:

Consider using the System module format and the SystemJS loader via jspm to both manage your packages and to load your code. With this approach, you gain the advantages of RequireJS, are able to run your tests under NodeJS and the browser using jspm run without needing to switch targets formats or bundle your code just to test it. There's also no need to bundle your code during development, although this is supported. More importantly, you gain the advantage of writing future compatible code, as it offers the only module format and loader which correctly models the semantics that ES Modules will eventually have when implemented natively in browsers. JSPM has first class support for TypeScript, Babel, and Traceur. For posterity here is the description of the System module format taken from the link above:

System.register可以被认为是一种新的模块格式，旨在支持ES5中ES6模块的确切语义.它是一种非协作开发的格式，在Traceur(实例化)，Babel和TypeScript(作为系统)中作为模块输出得到支持.此格式支持ES6模块支持的所有动态绑定和循环引用行为.这样，它可以作为进入ES6模块的polyfill路径的安全且全面的目标格式.

System.register can be considered as a new module format designed to support the exact semantics of ES6 modules within ES5. It is a format that was developed out of collaboration and is supported as a module output in Traceur (as instantiate), Babel and TypeScript (as system). All dynamic binding and circular reference behaviors supported by ES6 modules are supported by this format. In this way it acts as a safe and comprehensive target format for the polyfill path into ES6 modules.

免责声明:我是JSPM GitHub组织的成员，在维护注册表方面发挥了作用，并对jspm cli做出了很小的贡献.

Disclaimer: I am a member of the JSPM GitHub organization, playing a role in maintaining the registry and have made very minor contributions to the jspm cli.

这篇关于VS 2015 ASP.NET 4 MVC 5中的打字稿-设置和选择的有效组合是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！