Add TypeScript code generator

[ThomasBarnekow]

This PR adds a TypeScript code generator to the DocumentFormat.OpenXml.Generator.Linq project. This lets us generate namespace-related classes for the "LINQ to XML way" for both C# and TypeScript.

The TypeScript classes can be used with the @openxmldev/linq-to-xml NPM package, which also provides the XNamespace, XName, and XAttribute classes required for the generated code.

In PowerShell, for example, the generator is invoked as follows to generate C# code (which is the default) in the output directory specified using the required --outDir option:

.\DocumentFormat.OpenXml.Generator.Linq.exe --outDir .\path\to\output\directory

To generate TypeScript code instead, the --ts option is used:

.\DocumentFormat.OpenXml.Generator.Linq.exe --outDir .\path\to\output\directory --ts

In case no options are specified, you'll see an error message with the description of the options:

ERROR(S):
  Required option 'outDir' is missing.

  --outDir     Required. Specifies the output directory.

  --ts         (Default: false) Selects TypeScript instead of C# as the output language.

  --help       Display this help screen.

  --version    Display version information.

At the moment, the TypeScript generator does not generate code for all classes but selects the more frequently used namespaces (from my point of view). If there is better data available to make a more informed selection, I'd be open to using that instead. The idea is to limit the size of the NPM package by not including namespace-related classes that are not used in practice.

The TypeScript generator emits static attributes because a benchmark performed with @mikeebowen demonstrated that this leads to the best run-time performance (see benchmark results).

[twsouthwick]

Thanks @ThomasBarnekow! I'm in the process this week (hopefully) of merging in the backend code generator with its data source. Can we hold off on this so this can be built on top of that? It will have information that will be the "source of truth" for the schema info for the project.

[ThomasBarnekow]

Hi @twsouthwick! Yes, we can certainly hold off on this.

Just to understand this a bit better, what would "building on top of the backend code generator" entail?

[twsouthwick]

I'm setting it up as two projects:

• One project is a way to access the data and exposing a consistent object model for types on top of it
• The other project would be a C# specific code generator

Any C# generation, I'd like to go in the source code generator there. Other language generators could build off of the shared library that is just the data and object model.

[ThomasBarnekow]

@twsouthwick, is there any update on those two projects you mentioned in your last post?

[twsouthwick]

@ThomasBarnekow sorry for the slow response, I've been busy on a separate project and now I've got a bit of breathing room :)

There is now a gen directory with a models class that should be able to provide the information you're looking at. It was definitely written with C# code generation in mind, but should expose the data needed. We can definitely update that to support what you need from it.

[ThomasBarnekow]

@twsouthwick, I rebased onto main and made sure that all changes you had made to Program.cs were replicated to CSharpGenerator.cs and TypeScriptGenerator.cs. Except for index.ts (see the separate commit), the output produced by those generators has not changed.

You only made very few changes to the code that now sits in CSharpGenerator.cs. Therefore, can I assume the generation mechanism used for the "Linq-to-XML way" is still okay? The TypeScriptGenerator essentially replicates what CSharpGenerator does and outputs TypeScript instead of C#.

[ThomasBarnekow]

@twsouthwick, do you have any comments?

[twsouthwick]

Overall, this looks fine. I'm a little hesitant to bring in anything that will imply additional language support. Can you add some sort of description that the repo only supports c# SDK, but this provides the ability to use its metadata in other languages?

As a side note, the current LINQ generated code is probably out of date. Would you be able to switch it to be generated in the source generators so things stay in sync? Not a blocker for this PR by any means, but just FYI. The source for both can be in some sort of shared place so you can access it in both tools. At the least, the dependency on the CodeDom needs to be removed and then I could maybe move it over (time permitting)

[twsouthwick]

/azp run

[azure-pipelines[bot]]

Pull request contains merge conflicts.

[twsouthwick]

Closing for now for no movement. Still not sure we want to enable this in the repo