CitizenMatt.ReSharper.LiveTemplateCompiler 3.6.0
dotnet add package CitizenMatt.ReSharper.LiveTemplateCompiler --version 3.6.0
NuGet\Install-Package CitizenMatt.ReSharper.LiveTemplateCompiler -Version 3.6.0
<PackageReference Include="CitizenMatt.ReSharper.LiveTemplateCompiler" Version="3.6.0"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> </PackageReference>
paket add CitizenMatt.ReSharper.LiveTemplateCompiler --version 3.6.0
#r "nuget: CitizenMatt.ReSharper.LiveTemplateCompiler, 3.6.0"
// Install CitizenMatt.ReSharper.LiveTemplateCompiler as a Cake Addin #addin nuget:?package=CitizenMatt.ReSharper.LiveTemplateCompiler&version=3.6.0 // Install CitizenMatt.ReSharper.LiveTemplateCompiler as a Cake Tool #tool nuget:?package=CitizenMatt.ReSharper.LiveTemplateCompiler&version=3.6.0
ReSharper 模板编译器
一个简单的实用程序,可用于生成存储为结构化 markdown 的 Live Template 的 ReSharper .dotSettings
文件。它可作为命令行工具或作为 NuGet 包运行,并集成到您的构建中。下面是使用说明。
ReSharper 的模板非常强大,可以从简单的文本快捷键生成复杂的代码片段,字段与代码完成和建议的宏相关联,GUID 创建,文件名等。甚至可以将它们作为扩展打包并在 扩展管理器 中分发。
但您是否曾尝试处理存储它们的 .dotSettings
文件格式呢?
它绝对是一种机器可读的文件格式,并不适合人类消费(尽管一旦您了解了它,就会意识到它只是一个包含名称/值对的 xml 文件,其中每个名称都是一个层次化的键路径,但它并不像,你知道,舒适的毛茸茸的东西)。
维护模板文件需要在 ReSharper 中挂载文件→管理选项并使用模板资源管理器,但如果您在一个源代码控制仓库中遇到文件,那您就自谋生路了。
此实用程序将将 .dotSettings
文件反编译成多个结构化 markdown 文件,这些文件更具可读性,尤其是在 GitHub 上,然后可以将这些 markdown 文件编译成新的 .dotSettings
文件,以便进行分发。在编译时,它还会创建一个简单的 README.md,列出了所有模板快捷键和描述,按类别分组。
是的,我知道这实际上不是一个编译器,但它将许多纯文本、人类可读的文件整合成一个单一的不可读、机器友好的文件。对我来说,这听起来就像是一个编译器。
示例
您可以在以下链接中查看一些示例 这里。GitHub将显示每个模板的快捷方式和描述的README.md文件列表,快捷方式将是链接到单独文件的链接。例如,theory.md 显示了一个具有快捷方式 theory
、描述“创建理论方法”以及以代码块形式显示的模板文本的模板。GitHub非常巧妙地以简单的表格形式显示元数据。
文件格式
Markdown文件看起来像这样
---
guid: 58defe14-2132-4e4e-8126-5fa7e9a8f472
type: Live
reformat: True
shortenReferences: True
categories: xunit
scopes: InCSharpTypeMember(minimumLanguageVersion=2.0)
parameterOrder: TheoryMethodName, DataAttribute, parameters
DataAttribute-expression: completeSmart()
---
# theory
Create theory method
```
[Xunit.Extensions.TheoryAttribute]
[$DataAttribute$]
public void $TheoryMethodName$($parameters$)
{
$END$
}
```
模板的元数据存储在文件顶部的类似YAML的前置内容中,由两条水平线分隔。标题用作快捷方式(在这个例子中,快捷方式是'理论'),第一段是描述。遇到的第一个代码块是模板文本。在生成《.dotSettings》文件时,任何其他内容(后续段落或代码块或列表等其他格式)都被简单地忽略。
元数据存储为一系列名称/值对,其中名称与值之间用冒号 :
分隔
名称 | 值 |
---|---|
guid | 每个模板都需要一个GUID键。必须指定此键,以便在生成多个.dotSettings 文件时,模板始终具有相同的GUID。这允许用户软删除或禁用模板,而无需在重新生成《.dotSettings》文件时重置。 |
type | 这是一个什么样的模板。必须是Live 、Surround 或 File |
reformat | 是否应在插入后重新格式化生成的代码。默认为True 。 |
shortenReferences | 是否通过添加using 语句来缩短完全限定的类型引用。默认为True ,并是在创建模板时的最佳实践。如果您不使用完全限定的类型,则用户必须已经放置了适当的using 语句,否则生成的代码将无效。 |
categories | 分类列表,如模板资源管理器UI中所显示。 |
scopes | 范围列表,指明模板可用之处。下面有更多细节。 |
parameterOrder | 参数列表,以逗号分隔,以及用户按制表符时它们被访问的顺序。如果用户无意编辑某个特定参数(例如,它可能指的是另一个参数),则该参数的名称应放在方括号中,例如,给定methodName, (varName), args 。在这个例子中,参数的顺序是最先methodName ,然后当用户按下制表符时,是args 。varName 参数不编辑。然而,其顺序仍然很重要,因为它将在methodName 参数评估之后评估。如果在文本中有多个参数的实例,将只考虑一个可编辑。这将在参数的名称中表示为文本中出现的顺序的1基于索引。例如,methodName#2, (varName), args 将编辑文本中methodName 参数的第二次出现。请注意,参数的数量和顺序以及模板文本中的占位符之间没有任何验证。 |
parameter-expression | 与参数关联的宏所使用的表达式。名称应该是参数名称后跟-expression 。因此,对于名为varName 的参数,表达式将是varName-expression: completeSmart() 。下面有更多细节。 |
image | 指定要使用的图标。在UI中未使用,并在插件中需要自定义代码以注册模板图像。插件必须创建一个模板图像名称与IconId 实例之间的映射。这可以通过调用例如new TemplateImage("MyTemplateImageName", MyIcons.MyTemplate.Id) 来完成,这将在静态字典中注册映射。这些调用可以作为在[ShellComponent] 中进行静态字段初始化的一部分创建。这些调用可以通过在静态字段初始化中调用来实现。 |
Scopes
模板的一个不那么明显但更强大的方面是可以指定它们在哪些地方有效。而不是模板在可以输入文本的任何位置都可用,您可以将其限制为特定文件类型,或该文件类型内的特定位置。例如,您可以创建一个只适用于C#文件的模板,或者只适用于C# 3.0及以上版本的文件,或者在期望有一个语句的地方。
这些作用域在模板资源管理器UI中可编辑,可以在Markdown文件中的scopes
元数据中指定。范围参数的格式是由分号
分隔的作用域名称列表。每个作用域名称可以包含一个参数列表,给出一个用圆括号括起来的逗号分隔的名称/值对列表。这听起来比实际情况要复杂
scopes: Scope1(arg1=val1, arg2=val2); Scope2(param1=val1); Scope3
例如:
scopes: InCSharpFile(minimumLanguageVersion=2.0)
作用域的值是用于.dotSettings
文件的值。找出作用域值应该是什么的最简单方法是反编译现有的.dotSettings
文件到Markdown文件。
待办事项:在这里列出一个已知的范围列表可能会很有用。
参数表达式
每个参数都可以包含一个在参数字段按Tab键时执行的关于宏及其参数的表达式。元数据项的名称基于参数名加上-expression
。所以对于一个名为suffix
的参数,表达式会是
suffix-expression: constant(".min")
这个表达式来自ReSharper中的宏定义。每个宏有一个名称,在这个例子中是"constant"
,所有参数都作为逗号分隔的列表添加到圆括号中。同样,这些值最好通过反编译现有的.dotSettings
文件来检索。
待办事项:在这里列出一个已知的表达式列表可能会很有用。
用法
该实用工具可用于编译和反编译.dotSettings
文件。通过反编译现有的.dotSettings
文件来设置模板可能更容易,特别是当模板包含作用域或参数表达式时。
下载
要获取可执行文件的副本,要么获取源代码并构建,要么查找最新发布版本。
反编译
要反编译,只需
rstc decompile -i foo.dotSettings -o outDir
-i
指向要反编译的.dotSettings
文件,如果没有指定,则默认为templates.dotSettings
。-o
指定输出Markdown文件的目录。如果没有指定,Markdown文件将生成在当前目录中。
编译
要编译一系列Markdown文件为一个可分发的.dotSettings
文件
rstc compile -i *.md -o templates.dotSettings
-i
是输入文件,必须提供。-o
是输出文件,如果没有指定,则默认为当前目录中的templates.dotSettings
。
NuGet包
此实用工具还可用作NuGet包,它会自动在构建过程中将一组Markdown文件编译成一个.dotSettings文件。它支持增量构建,并且只有在输入文件有更改时才会更新输出文件。
首先,添加对CitizenMatt.ReSharper.LiveTemplateCompiler
包的引用。然后向您的.csproj文件添加以下内容
<ItemGroup>
<LiveTemplate Include="templates\**\*.md">
<OutputFile>templates\templates.dotSettings</OutputFile>
</LiveTemplate>
</ItemGroup>
可以通过为项目赋予不同的OutputFile
元数据来创建多个.dotSettings
文件
<ItemGroup>
<LiveTemplate Include="templates\one\**\*.md">
<OutputFile>templates\one.dotSettings</OutputFile>
</LiveTemplate>
<LiveTemplate Include="templates\two\**\*.md">
<OutputFile>templates\two.dotSettings</OutputFile>
</LiveTemplate>
</ItemGroup>
生成的文件可以像正常情况一样作为嵌入式资源包含
<ItemGroup>
<LiveTemplate Include="templates\**\*.md">
<OutputFile>templates\templates.dotSettings</OutputFile>
<ReadmeFile>templates\README.md</ReadmeFile>
</LiveTemplate>
<EmbeddedResource Include="templates\templates.dotSettings" />
</ItemGroup>
如果未定义ReadmeFile
元数据,则说明文件简单地作为README.md
生成,并将出现在当前工作目录中(最可能在.csproj文件旁边)。
已知限制
有一些已知的限制
- 每次生成时,
.dotSettings
文件都会略有不同。一个模板的作用域(在何处可用)存储为索引值,以GUID作为键。然而,GUID实际上在任何地方都没有使用,因此值是任意的,而且不是将其存储在Markdown文件中,而是在每次创建.dotSettings
文件时都生成一个新的GUID。除此之外,.dotSettings
文件应该是一致的。 - 目前不支持具有多个部分(多个文件)的文件模板。我想支持它,但它还没有实现。我认为每个部分将以水平线划分,标题提供文件名,第一个代码块用于代码片段。
此包没有依赖项。
NuGet包
此包不被任何NuGet包使用。
GitHub存储库 (2)
显示依赖于CitizenMatt.ReSharper.LiveTemplateCompiler的顶级2个受欢迎的GitHub存储库
存储库 | 星标 |
---|---|
JetBrains/resharper-unity
Unity支持ReSharper和Rider
|
|
JetBrains/godot-support
|
版本 | 下载 | 最后更新 |
---|---|---|
3.6.0 | 912 | 7/16/2024 |
3.5.0 | 10,987 | 12/27/2023 |
3.4.0 | 4,301 | 11/2/2023 |
3.3.0 | 17,787 | 1/16/2023 |
3.2.0 | 20,193 | 1/19/2022 |
3.1.0 | 4,331 | 8/22/2021 |
3.0.0 | 2,775 | 4/17/2021 |
2.8.0 | 4,921 | 12/28/2020 |
2.7.0 | 473 | 12/22/2020 |
2.6.0 | 3,945 | 9/14/2020 |
2.5.1 | 2,400 | 7/9/2020 |
2.5.0 | 470 | 7/9/2020 |
2.4.2 | 14,331 | 5/16/2018 |
2.4.1 | 973 | 5/16/2018 |
2.4.0 | 1,082 | 5/16/2018 |
2.3.0 | 6,090 | 9/26/2017 |
2.2.0 | 916 | 9/26/2017 |
2.1.1 | 888 | 9/25/2017 |
2.1.0 | 891 | 9/25/2017 |
2.0.0 | 985 | 9/25/2017 |
– 修复README中的另一个排序问题,这次是关于模板类型
从3.5开始
– 再次使用稳定的序数排序排序README中的模板
从3.4开始
– 使用稳定的序数排序排序README中的模板
– 添加选项以允许修改写入输出文件时使用的换行符
从3.3开始
– 改善README中表格的格式
从3.2开始
– 包含.NET 4.8构建的依赖项
从3.1开始
– 升级到.NET 5
从3.0开始
– 升级到MarkDig
– YAML前边距不再解析为Markdown,因此可以包含Markdown中使用的字符
从2.8.0开始
– 维护在生成的设置文件中模板作用域的顺序
从2.7.0开始
– 添加对文件模板中UITag分组的支持
从2.6.0开始
– 修复目标顺序。编译现在发生在其他PrepareResources目标依赖项之前
从2.5.1开始
– 修复由.NET核心Uri处理差异引起的readme生成问题
从2.5.0开始
– 添加.NET Core可执行文件(感谢@epeshk)
从2.4.2开始
– 添加支持可编辑实例索引
– 改进了无效YAML前边距的错误信息
– 在2.4.0中打包了无效版本
从2.3.0开始
– 添加对图像元数据的支持
从2.2.0开始
– 修复生成的README.md中的相对路径
从2.1.1开始
– 修复targets文件中的路径
从2.1.0开始
– 改进readme生成位置的处理